tain.totalcodex.net

The Trow were indeed a lot stronger in Myth TFL, but that was a "side effect" of anti-clumping (I think). In Myth 2 you can get a bunch of meele units clump together and attack a trow, which ensures that most of them will be able to do some damage before dying. In Myth 1 that was not possible, and a Trow could essentially do 1vs1 each unit a time, killing tons of enemies.

Also, Trow bleed in Myth 1. In myth 2 they don't. Don't know if that was intentional or what.

Avatara wrote:Trow were indeed a lot stronger in Myth TFL, but that was a "side effect" of anti-clumping (I think). In Myth 2 you can get a bunch of meele units clump together and attack a trow, which ensures that most of them will be able to do some damage before dying. In Myth 1 that was not possible, and a Trow could essentially do 1vs1 each unit a time

I thought anti-clump was desirable because it made your melee units more effective? Or is it just in the case of "versus Trow" that anti-clump is bad?

The Seeker wrote:

Avatara wrote:Trow were indeed a lot stronger in Myth TFL, but that was a "side effect" of anti-clumping (I think). In Myth 2 you can get a bunch of meele units clump together and attack a trow, which ensures that most of them will be able to do some damage before dying. In Myth 1 that was not possible, and a Trow could essentially do 1vs1 each unit a time

I thought anti-clump was desirable because it made your melee units more effective? Or is it just in the case of the Trow that anti-clump is bad?

I don't think anti-clump is bad. I'm not using this, but I believe it would also make thrall not clumping together, which makes them harder to kill by dwarf. Well, it's harder, but is it bad?

I wrote most of the vTFL code, but its years ago now & I couldn't hope to remember most of it What Myrd said was correct - when we started writing it, the TFL source code was believed lost. As many of us were TFLers in Magma, we couldn't bear seeing the old game die due to an increasing inability to run on modern operating systems.

Anyway, two major coding changes were:-
a) Physics. Objects (projectiles etc) are destroyed not by taking damage as they are in Myth II, but by the degree to which they were accelerated. This made possible all the fascinating TFL stuff like carpet bombing and especially underwater chain reactions (pool party!).

b) Pathfinding. Anticlumping alone is easy - its just a larger radius around each unit to stop them getting close. Making a bunch of units flow past & around each other naturally is a different matter. With Myth II's pathfinding method they'd not do this at all well - they'd get stuck walking back & forth behind an obstacle. In TFL (and vTFL) they'd keep going in one direction until they'd found a way around. Another thing thats different is that TFL units turn by walking in a curve rather than rotating on the spot like Myth II's units do.

Thrall seem better in (v)TFL purely because of the absence of clumping. They aren't nearly as easy to blow up in a bunch or arc to death, and in melee they can take a lot of punishment.

TFL was actually more about micro-management than Myth II in some ways. For instance, instead of getting a tight-packed group of melee close to the enemy's and letting them auto, you'd have broader formations and click to attack ... and then madly micro the individual units to set up 2v1s etc before the opposing lines met. Being able to see what went on in melee made it far more enjoyable imho, even though I usually had the rough end of the pineapple

I generally found TFL's gameplay to have greater depth, more possibilities for fine-tuned tactics on many levels, more unpredictability and, well, it just felt better. Though vTFL isn't perfect, it does capture a huge amount of what made TFL what it was, and most of its imperfections are minor - of an aesthetic rather than functional nature.

Just my 2 cents worth - hope it helps

iron wrote: TFL was actually more about micro-management than Myth II in some ways. For instance, instead of getting a tight-packed group of melee close to the enemy's and letting them auto, you'd have broader formations and click to attack ... and then madly micro the individual units to set up 2v1s etc before the opposing lines met. Being able to see what went on in melee made it far more enjoyable imho, even though I usually had the rough end of the pineapple

I generally found TFL's gameplay to have greater depth, more possibilities for fine-tuned tactics on many levels, more unpredictability and, well, it just felt better. Though vTFL isn't perfect, it does capture a huge amount of what made TFL what it was, and most of its imperfections are minor - of an aesthetic rather than functional nature.

Just my 2 cents worth - hope it helps

Now that you've said it, I agree complately. Meele in TFL required more micro indeed. It's just that things in Myth 2 are so predictable (dorfs do perfect throws, archers are super accurate, you have to keep units tight in meele to abuse clumping, lots of artillery units, formation, unit placement and movement management are somewhat useless) to the point where I frequently feel that having quick reflexes and good clicking skill are more important than making good strategic decisions (when, where to attack, flanking, retreat, etc...).

The only thing, in my opinion, that M2 did right in terms of gameplay was ( oh oh, picks up flame shield) removing CB. Yeah, it's cool and can lead to some funny moments, but when you have 2 teams CBing at each other and doing nothing else... well, things start to get somewhat boring and the strategic purpose of the game just vanish.

Hehe ... but nothing beat the feeling of seeing a CBer intently watching the fall of his missiles somewhere across the map, oblivious to you walking up and whacking his fetch & duffs with a tr0

iron wrote:Hehe ... but nothing beat the feeling of seeing a CBer intently watching the fall of his missiles somewhere across the map, oblivious to you walking up and whacking his fetch & duffs with a tr0

You never fail to put these Myth vignettes in their appropriate nutshells, Iron Always entertaining.

So...no one knows what "Reduce renderer load" does?

Anyone know why you would want to "Hide underwater objects"? Save on graphics load?

The Seeker wrote:So...no one knows what "Reduce renderer load" does?

Anyone know why you would want to "Hide underwater objects"? Save on graphics load?

A discussion about "reduce renderer load" can be found at http://www.playmyth.net/index.php?name= ... 09e318f184
(found by googling +myth +"reduce renderer load")

Why you want to hide underwater objects? Dunno unless you are an old school purist or just don't want to see things you wouldn't see if you weren't an omniscient entity.

vinylrake wrote:A discussion about "reduce renderer load" can be found at

Yeah, I'd read that, and another thread that came up, but they told me essentially nothing (just "I checked it, it worked faster"). What is this option doing? Is it a magic "make the game work faster" mode? If so, why wouldn't everyone check it? There must be some trade-off for checking it, I wanna' know more. If there were no trade-off, why would there even be an option? The game would always just run in "faster" mode.

>...if you weren't an omniscient entity.

You mean not everyone is?

The Seeker wrote:

vinylrake wrote:A discussion about "reduce renderer load" can be found at

Yeah, I'd read that, and another thread that came up, but they told me essentially nothing (just "I checked it, it worked faster"). What is this option doing? Is it a magic "make the game work faster" mode? If so, why wouldn't everyone check it? There must be some trade-off for checking it, I wanna' know more. If there were no trade-off, why would there even be an option? The game would always just run in "faster" mode.

My completely uneducated guess is that 'reduce renderer load' is from the old days of Myth II when not all or even most computers could handle the graphics of Myth II in all their fast FPS glory and now that everyone and their grandmother has a machine with better graphics, faster CPU more memory it's a moot point.

Back in the day, the options for presenting a visually rich/cpu intensive game experience were either just chug through the slow CPU/graphics and show everything no matter how long it takes (thereby reducing the framerate sometimes to unplayable levels since the game gets so choppy/laggy) or to reduce the amount of stuff the cpu/graphics card has to show on the screen (aka the "renderer load") So, reducing the renderer load _usually_ means things like - reducing the resolution of background images/textures, reducing the resolution of sprites or models, and when doing 3D not drawing surfaces you can't see at the moment.

So, if you had a machine that played choppy you would run with 'reduce renderer load' checked, but if your CPU is fast enough to display everything with no lag there's really no reason to run with 'reduce renderer load' checked, and doing so will probably in some shape or form (depending on how the code is written) reduce the quality of your visual in-game display.

Again, this is just off-the-top-of-my-head, I really don't know anything about how the option really effects Myth game play.

vinylrake wrote:My completely undeducated guess is that 'reduce renderer load' is...

Good guess. Maybe right. You'd think then that once you check it, you'd see a difference in the graphics (if there is no difference, and no trade-off, it wouldn't be an option, it would just be the permanent behavior). No one using it mentioned graphical degradation. I guess next time I get a chance to mess around I'll try to remember to check off the option and see if I see any difference in the game.

The Seeker wrote:Good guess. Maybe right. You'd think then that once you check it, you'd see a difference in the graphics (if there is no difference, and no trade-off, it wouldn't be an option, it would just be the permanent behavior). No one using it mentioned graphical degradation. I guess next time I get a chance to mess around I'll try to remember to check off the option and see if I see any difference in the game.

While I am guessing madly, it's possible that the game engine had logic builtin to it so that IF the frame rate / refresh rate / time-span-between-calls-to-the-display-routine got below a certain rate AND the 'reduce renderer load' switch were turned ON then it would start cutting visual corners, but if the switch were ON and the framerate never dropped below the minimum bungie approved threshold it would never even bother checking the reduce renderer load switch. Might explain why no one's noticed graphical degradation on newer machines when the switchis turned on.

Of course this is just speculation. I am sure one of the Magma programmers knows the Truth(tm).

vinylrake wrote:...if the switch were ON and the framerate never dropped below the minimum bungie approved threshold it would never even bother checking the reduce renderer load switch.

Interesting theory. But people have reported increased frame rates when this is checked, and your theory doesn't explain that. And we already know when given the chance Myth will jack the framerate at the expense of yielding the cpu to other tasks (hence the "cap FPS" option). So...checking it suddenly lets the frame rate go up for some reason?

The option makes Myth do fewer redundant calculations when going over 30FPS. Since the game updates 30 times a second, if you're rendering things faster than that, you're doing things that do not need to be done (since they've been done already for this tick). So that option eliminates some of that redundant processing.

What does this mean? Well, if you don't have your FPS capped using the other option, then more of your CPU time is allocated to Myth's other processing, like input, so in theory it can be more responsive. (It will still take 100% CPU in this case). If you do have an FPS cap set and it's above 30FPS, then you may probably see Myth take a bit less CPU when rendering the same scene with this option checked.

I think one disadvantage is some people complained of slightly choppier camera movements, since the camera is not limited to 30FPS normally, but becomes limited to 30FPS with that option.

Honestly, if you find that Myth already works great for you, who cares if there's some option somewhere? It's already running fine!