Page 2 of 2

Posted: Thu Dec 30, 2004 6:00 am
by Nagelfar
....Speaking of limits. One thing that I'm sure wouldn't cause any problems is the unit renaming character limit. I mean, I can't even rename my jmen/herons with names like they already have! The renaming letter limit needs to be doubled or maybe even tripled. It's a small thing, but things like that just get to me.

Posted: Wed Jan 05, 2005 1:22 pm
by The Elfoid
The particle/projectile limits need increasing.

6 mim lmoth float/chest/vivid frenzy dm with a full set of players (i.e. all start points used) uses up most of the particles VERY quickly. About 2/3 of the way thru a game, dwarves start throwing duds that never light (normally they start on fire and go out if they dud) and flame arrows don't work. Sometimes these 'duds' do work, you just can't see them. Dead bodies stop appearing as well.

That said, it doesn't make it less fun, just makes it more random.

Posted: Wed Jan 05, 2005 2:54 pm
by ChrisP
Ah, yes, more projectiles would be great as the current limit is only 1024 active projectiles and 8192 objects (including things like scenery).

Projectile increases were tried in a 1.4 beta long ago. I believe the result was rampant OOS issues. Pity. However, the object limit was doubled from 4096 and some tweaks were made to make the projectile limitations slightly less severe.

In your Death Match game, you may have also ran out of local projectile groups, or "particles". The limit for them is only 96, I believe.

Death Matches just don't work really well and never have. You need specially designed maps with bio-degrading projectiles and carefully tuned local projectile groups for that sort of thing to run without problems.




Edited By ChrisP on 1104955052

Posted: Wed Jan 05, 2005 4:21 pm
by Myrd
Problem with projectile limits and maps like Chest or Frenzy that have a lot of water is that water ripples that you get from people walking in water also count as projectiles toward the total limit of 1024. This makes the limit much easier to reach, unfortunately.

Posted: Thu Jan 06, 2005 6:57 am
by Phex
What about an optional Bio-Degrader? A little checkbox in the Game Options Menu: when you select it, all projectiles dissapear after a certain amount of time, lets say 1 minute (or even a variable amount of time that can be set up by the user).
It would not be more difficult to implement than vtfl and you could surround projectile limits of mass fights without changing the engine itself.

Posted: Mon Apr 04, 2005 1:01 am
by WaaMatt
I'm all for a Bio-Degradable Projectiles option when setting up a game or in the overall Myth II prefs. Maybe it's a game-wide pref that can be disabled temp. in a multi game? So, maybe you have a multi map with few guys and, for visual effects/aesthetics, you don't want projectiles to go away.

You can also just make a projectile eater. Some sort of indestructable, invisible creature that marches around eating up projectiles it walks over...

Posted: Tue Apr 05, 2005 4:58 pm
by Lothar
We gotta do somethin' about them thar' projectiles, 1024 is a very small, and is easily and often reached.
WaaMatt wrote:…You can also just make a projectile eater. Some sort of indestructable, invisible creature that marches around eating up projectiles it walks over...


It doesn't have to be invisible, :O , that would be an awesome addition to Myth!!!


<span style='font-size:8pt;line-height:100%'>P.S. I know it isn't possible :roll:</span>

Posted: Tue Apr 05, 2005 6:07 pm
by iron
The only projectiles that count towards the 1024 limit are those that are "active", usually flying through the air. The vast majority of projectiles become dormant when they come to rest, and are no longer included in the limit.

The problem comes when there's so many that it becomes a strain on the renderer & fps start to drop, and also when the 8192 object limit starts to approach. Levels likely to suffer from this are ones where the fighting takes place in a constricted area with successive waves of enemies.

The problem with biodegraders (a fancy name for projectiles that disappear after a time delay) is that the lifespan promotion only works if the projectile does not have the "Becomes Dormant at Rest" flag ticked - in other words it stays active & part of the 1024 count.

So ... you can either keep the projectiles around & run into rendering problems later on, or you can use a biodegrader & have to remove them quite quickly to prevent the 1024 limit being hit.

The 3rd option, having a unit "eat" the projectiles, can be done using GEOM script & a unit somewhere the player can't see to which the projectiles are given then destroyed using the "Remove Artifact" parameter. Problem with this is that to be effective the GEOM has to run constantly, potentially causing a lot of script/cpu lag. Its also a ton of work to set up, getting it to find and eat each projectile. And you have no choice over the order in which it removes things - it could choose to take a projectile that's just been created instead of one that's been lying around for 10 minutes.

The ideal solution would be something that removes them after a delay, but that doesn't require them to still be active for it to work. Unfortunately that's not going to happen anytime soon (if at all) as guess what - it'd change gameplay yet again.

Posted: Wed Apr 06, 2005 10:13 am
by Phex
The ideal solution would be something that removes them after a delay, but that doesn't require them to still be active for it to work. Unfortunately that's not going to happen anytime soon (if at all) as guess what - it'd change gameplay yet again.


Good point. But an optional feature wont hurt anybody - like vtfl didnt do it. I can imagine that this system would require a lot of work and bugfinding, but it would be cool to have an option that would allow deathmatch games with a guaranty of no reached limits. :roll:

Posted: Wed Apr 06, 2005 10:21 am
by WaaMatt
Deathmatch does have a limit, doesn't it? Well, projectiles aside. Isn't that what the % is for?

If the delayed projectile removal wasn't part of the game itself, people could always script it in (but, again, potentially causing script/cpu lag like the "eater").