Another Update Underway For The Mapping Guidelines
Cagey
Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Members, Retired Developer, NS1 Playtester, Constellation
Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Members, Retired Developer, NS1 Playtester, Constellation
<div class="IPBDescription">good news and bad news for mappers</div> I just received an email from Flayra with updated information about enities in Natural Selection, and I'm going to be making some changes to the Mapping Guidelines--there's both good and bad news; I'll give you the good news first.
----------------------------
Flayra confirmed that entities that are removed on spawn by the server don't count toward the entity limit -- this means that info_null, <i>unnamed</i> light, and <i>unnamed</i> light_spot entities join info_player_start, info_team_start, and info_location as ignorable for the purposes of the cap.
----------------------------
More good news for mappers -- there are two new developer commands that you can use to find out how NS is counting the entities in your level -- they return the official number of entities; this is the number you should compare to the Mapping Guidelines. To use them, type "sv_cheats 1" and "developer 1" on separate lines in the console.
The first new command is "entityinfo". This will list a count of each entity type in your map--it will tell you where your entity count is being spent and is useful for optimizing your map. Counting up the total of the printed entities when there isn't an active game running should tell you the official total for your map. The second new command (which doesn't appear to be fully functional yet in the 2.0 client release from what I can tell) is "numents" -- this should tally up the total entity count for you and print it out once it's working.
----------------------------
Now the bad news: 400 entities still puts a major strain on servers running NS, so Flayra has stated that the required limit for official map inclusion should be 300 entities -- with a recommended target of 200 entities. You can use the new commands above to see how your map currently compares to this number--it's not the same as the number of entities that your editor will report in its map information dialog. I'll be updating the Guidelines to reflect the new limits tonight.
----------------------------
Flayra confirmed that entities that are removed on spawn by the server don't count toward the entity limit -- this means that info_null, <i>unnamed</i> light, and <i>unnamed</i> light_spot entities join info_player_start, info_team_start, and info_location as ignorable for the purposes of the cap.
----------------------------
More good news for mappers -- there are two new developer commands that you can use to find out how NS is counting the entities in your level -- they return the official number of entities; this is the number you should compare to the Mapping Guidelines. To use them, type "sv_cheats 1" and "developer 1" on separate lines in the console.
The first new command is "entityinfo". This will list a count of each entity type in your map--it will tell you where your entity count is being spent and is useful for optimizing your map. Counting up the total of the printed entities when there isn't an active game running should tell you the official total for your map. The second new command (which doesn't appear to be fully functional yet in the 2.0 client release from what I can tell) is "numents" -- this should tally up the total entity count for you and print it out once it's working.
----------------------------
Now the bad news: 400 entities still puts a major strain on servers running NS, so Flayra has stated that the required limit for official map inclusion should be 300 entities -- with a recommended target of 200 entities. You can use the new commands above to see how your map currently compares to this number--it's not the same as the number of entities that your editor will report in its map information dialog. I'll be updating the Guidelines to reflect the new limits tonight.
Comments
And, well, my map is pretty huge and the current version I'm working on has 297 entities (without optimising (sp?)), so it's not impossible...
I REALLY wan't an ambient map, and that is what I am going to make <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
If not could you put a summary into the mapping guidelines?
And that incluse func_illusionary and func_walls too?
If not could you put a summary into the mapping guidelines?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Flayra confirmed that entities that are removed on spawn by the server don't count toward the entity limit -- this means that info_null, unnamed light, and unnamed light_spot entities join info_player_start, info_team_start, and info_location as ignorable for the purposes of the cap.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
The last three items above are listed in the current (v2.1.0) Guidelines in the Required Limits section, and I'll add the others when I update. I'm going to be turning the information about the new commands in my post above into a second Guidelines appendix.
<!--QuoteBegin--lillbrorsan+Sep 9 2004, 2:31 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (lillbrorsan @ Sep 9 2004, 2:31 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->200 ?! You gotta be kidding me. If the NS servers lagg, why not fix it in another way, like a patch for all ns servers out there.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin--Fortuna Wolf+Sep 9 2003, 4:16 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Fortuna Wolf @ Sep 9 2003, 4:16 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->200? that's freaking crazy.
And that incluse func_illusionary and func_walls too? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
300 entities is the new official limit -- 200 is just the recommended target. As noted above, there are entities that don't count towards the limit, so the total number is going to be higher. Flayra has already done some heavy optimization work to lower the CPU hit on servers due to entities (v1.01, v1.02, and v2.0 all saw improvement IIRC), but even with the improvements NS is CPU intensive.
func_illusionary and func_walls do count, since they are part of the runtime load on the servers.
<!--QuoteBegin--oOTOo+Sep 9 2003, 2:07 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (oOTOo @ Sep 9 2003, 2:07 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Will the current official maps have to change their entities count so ? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The existing offical maps were changed to fit new limits for v2.0, so I'd expect any of them over this limit (I'm not sure what their current entity counts are, they might already comply) to be revamped for a future client release--I'm not on the dev team, though, so that's not a definitive answer.
Also, why should a func_illusionary count? it doesn't (afaik) have any bearing on what happens in the game server side as it can't do anything or be used in collision detection etc. Can flayra code it out so its not part of the entity count and we can make pretty maps?
And is a trigger_relay as CPU intensive as a func_door_rotating?
Also, why should a func_illusionary count? it doesn't (afaik) have any bearing on what happens in the game server side as it can't do anything or be used in collision detection etc. Can flayra code it out so its not part of the entity count and we can make pretty maps?
And is a trigger_relay as CPU intensive as a func_door_rotating?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Regarding the entities killtargeted on map start, that's a question I'll have to ask Flayra--I can see the logic behind not counting them, but it's not my call. For now I'd have to say count them unless and until I hear otherwise. I'll ask when I send the updated Guidelines to Flayra tonight.
Func_illusionary counts because it has the potential to interact with other entities, making it effectively dynamic -- it can have its render properties changed with env_render, can be killtargeted, and can also be used to define the shape of a particle system. If there was a way to garuntee that a func_illusionary wouldn't interact with other entities (no targetname?) then you're right in saying that it doesn't have its own thought or collision functionality--telling the client to treat the illusionary as static and then dropping it from the server might be possible under those circumstances.
Unfortunately, I don't have the ability to answer questsions about what Flay can and can't do since I (1) haven't seen the NS source and (2) am not his project manager <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
I'm also not sure how CPU intensive entities are in relation to each other (and I'd make the same guess I suspect you have). For the forseeable future items are going to remain either equally wieghted or entirely off the list. It would be more difficult on mappers to express the entity limit in terms of CPU cycles or weighted counts; the baseline e_poly limit has demonstrated that things can't get too complex before some designers have problems understanding them.
((12*WPoly)+EPoly) less than 14000 for Commander Mode at peak, less than 10000 for average Commander Mode or peak Ground Walking, and less than 7000 for average Ground Walking.
If a mapper can't handle basic algebra and plug known EPoly values in for things like RTs and CCs and Hives... um... they need someone to show them how to use a modern calculator? *sweatdrops*
And as for the new (and lowered yet again) entity limits... ouch. =O.o= We REALLY need some way to get skulk-working 'clip' textures back in, Cagey, and Flayra REALLY needs to make a func_seethrough that supports the rendermode attribute for gratings, then the entity-limit won't be anywhere NEAR as bad. =^.^=
And by skulk-friendly clipping, I just want some way to have 'null-textured' brushes, or something similair (skulk-textured?) be merged into the clipping of a func_wall, but not visually affect it in any way. If possible, have it not affect opaque lighting, but I could live with it affecting it. I couldn't care less if it blocks bullets or not, and if the brushes covered in such a texture were transparent to lighting, but solid and wall-climbable, I could remove many entities altogether. Would let me cut the entity-count in Nancy down by 25-40% I think, though I doubt the rebuilt Nancy will hit the limit regardless.
They can understand e_polys if they're smart enough to make a map with a double siege position!
I'll keep chugging along on my maps and release them as 3rd party until I hear otherwise, I'll do as much as I can to personally optimize but I'm not going to castrate my maps ...
...
new thought, I can release castrated maps with the official release, and offer the fuller more entity intensive versions elsewhere, with the same map name, so those who can run them can and those who can't won't bother!
Ahhhh!
They can understand e_polys if they're smart enough to make a map with a double siege position!
I'll keep chugging along on my maps and release them as 3rd party until I hear otherwise, I'll do as much as I can to personally optimize but I'm not going to castrate my maps ...
...
new thought, I can release castrated maps with the official release, and offer the fuller more entity intensive versions elsewhere, with the same map name, so those who can run them can and those who can't won't bother!
Ahhhh! <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I really dislike your condescending, pushy attitude of your posts, Fortuna. To be precise, the formula I posted would actually be considered a second-order polynomial equation, the same type learned in 7th grade by most students in the US, and this is hardly 4D topology, either.
If you want to make a convincing argument that doesn't sound like flame-bait, at least get your terminology correct, okay? =^.^=
Using "entityinfo" I get a total of 398 (so when it was rebuilt for 2.0, it was changed to match the old 400 entity limit). The largest contributors:
74 func_illusionary
48 env_sprite
46 ambient_generic
34 env_particles_custom
damn, im on 396 and im really pushing D:
gah
Frankly, I agree that 300 is going to be restrictive on map content and I'd like it higher, too--but I'm just the messenger <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Personally I think the 73 medpacks and 27 packs of ammo that a comm might drop during an average game would be more of a problem if the server isn't deleting them...
If the server can't delete the created entities, it could atleast move them into a holding area and would reuse old entities whenever it could (only creating new entities when there were none left in the holding area).
That way you would only need a maximum of around 10 medpack entities for a really spammy comm would ever be needed as, seeing as soon as it's picked up or expires, it goes into the holding area ready to teleport to where I drop the next one. That could even be hard coded so that the 10 medpacks are spawned at the start of the game, and no new ones are ever created, the old ones are just moved about and toggled from invisible/visible at the appropriate times...
I hear ya man :-\ I would rather lag then not take advantage of how nice the NS graphics can look.