KZ Mapping basic rules

Hey guys, i haven't searched through the whole forum but so far i haven't found any threads about basic rules\requirements\prohibitions\recommendations for kz_ maps.
For example, it would be useful for new mappers to find some exact numbers. I guess in early 2000ths kz_synergy_x would be pretty laggy map, but time moves forward and nowadays newest pc specs smiles upon these 2000 wpoly. Ofcourse i'm not talking about optimisation in this case, just pointing at performance level.
Also i have few questions:
1) Is there any prohibitions for gravity manipulations or any other entities? I'm curious about it because mine kz experience isn't that great and i can't be sure how most of entities might interact with kz plugins on public servers or how entities might act in multiplayer in general.
2) Is it necessary to place timer's displays on map? I mean, does anyone looks at them anyways? I have no clue if they are really needed for recording demos on lan server when you have no kz plugins on.
So, if i'm using spr1n's time counter should i feel free to delete these displays without any consequences?
[IMG]http://i.imgur.com/SGLZ1yk.png?1[/IMG]
I mean, will it still properly work if i leave untouched the core of time counter(a group of entities in center and buttons)?
[IMG]http://i.imgur.com/ptBRMim.png?1[/IMG]
I suspect that it is possible to optimise time counter even more if i delete entities connected to those displays but i would not dare to go that far for now.
I hope some experienced mappers can overcome this wall of text and answer me.

Well from what I know you can place only the start and end buttons and it will work with the amx plugin and the program used to check demos.

Originally posted by 470

I guess in early 2000ths kz_synergy_x would be pretty laggy map, but time moves forward and nowadays newest pc specs smiles upon these 2000 wpoly. Ofcourse i'm not talking about optimisation in this case, just pointing at performance level.

Hello!

People have different computers so its very hard to provide exact numbers. In the beginning of last decade all multiplayer maps considered to be good and playable it they had around 500-700 wPoly and 1000-2000 ePoly. Nowadays it seems most people on XJ can handle 2000-3000 wPoly and 10000-15000 ePoly without any noticeable fps drops, people with older computers may experience fps drops depending on the hardware and map polygon count.

1. There are no restrictions how you manipulate gravity as long as its playable. Just use it properly, cover the whole are where it should be used, make sure you reset it leaving the area if you want to change it, so players cant exploit it outside etc.

2. Im pretty sure XJ still requires you to include ingame time for visual time representation. With timer plugins and decimal system - XJ moved away from counting time by ingame map timers, it became more distinctive attribute on climbing maps rather than technical feature.
To be clear you only have to include one timer display from that screenshot, not all 9 (many people dont know how to rotate sprite digits, so I made them facing different directions for easy choice). You can also customize it looks however you like.

Speaking of "budget" timers, I made my timer exactly with such intention in mind. As far as I know it is most optimized timer currently existing while being also most precise. It uses just 13 precache slots while engine limit is 512 with almost 200 slots reserved for game base files. Having 300 for solid entities/sprites/models not always enough and my timer helps to ease this consumption. Spr1n's timer with sprites is the easiest to use. I also have nosprites vesion, it requires some more configuration, but its easier to customize and rotate.
SadPuppy's timer is also good having just slightly more entities and unique layout. However it has some precision issues, along the fact all maps having this timer require demochecking tools, demo recording and server plugins separate custom configuration (for every map, on all tools, on all plugins) which is not practical for mainstream maps unfortunately.
Kreedz timer is the oldest one thus most used, it uses almost 50 precache slots if i recall correctly. Having it built with quite unreliable entities it also very incorrect occasionally having huge mistakes, which was one of the reasons why XJ stopped considering map timers for records.
All these timers also use point entities of course, but most mappers dont have to worry about it as limits are quite generous and even can be changed to be higher. Precache limit on the other hand is hardcoded and cant be changed.

Compiling maps with -chart option will give you overview of what limits you maybe nearing and to be aware of. Engine is old with a lot of those limits, and often timer is not the main thing you worry about when building huge maps to be honest.

Precache consists of unique models and sprites files + all solid entities that have shape (even if nulled/transparent/noclipped). its within "Models" row using -chart.
Your old timer using 10 sprites and 4 more solid entities. Unfortunately first time I hear about the one with 5 sprites and a conveyor =) Tempted to see it.

Thanks for so detailed answers guys, i appreciate this. Though, new questions came up.
Since precache limit is quite low it forces me to think how to save entities in case if i'm going to make bhop map.
I see the solution in grouping up bhop blocks. For example, i create 5 blocks and turn all of them in one func_door.
[IMG]http://i.imgur.com/fRDEjnx.png[/IMG]
Height of highest block here is 80 units, so i set Lip=78, so all 5 blocks go two units down after they touched. Then i create exact copy of those 5 blocks and make trigger_teleport of them. I move teleport one unit down etc.
[IMG]http://i.imgur.com/kToxMVW.png[/IMG]
So, there goes questions :
1) How much precache slots it will actually take?
2) Are such tricks allowed at all? I have no idea if it can cause any problems on public servers or if it can be abused somehow.

P.s.: i apologise for my lazyness, i realize that i can make some tests and find this out on my own, though i'm lazyass.
P.s.s.: i double-apologise if all information about my questions were mentioned somewhere in tutorials but i'm double-lazyass and haven't readed most of them yet.

@SadPuppy, thats right, as long as those 100 are within other limits as well. And yea such timer makes sense in a way, thought about it as well, though it just one unique animated sprite for 5 digit spots, so its just 1 precache slot there. If there was an entity for key changing value like in svencoop such timer could be stopper by dropping sprite's framerate value.

@470, it looks like you overthinking it, most mappers never even encounter precache limit building maps over the years. Anyway good techniques to reduce precache consumption:
- grouping many brushes into one entity, instead of making them separate entities. People often group their func_wall's. It doesnt matter how many brushes and how far apart they are - those can be part of one single entity.
- using func_detail instead of func_wall. As far as I know func_detail is turned into worldbrush by the end of compilation, thus doesnt need precache slot.
- you can group some bhops blocks into one entity like you suggested, just make sure further block gets back up (coz they both go down if part of the same entity) when player reaches it so its playable and everything works without issues.
- using custom key in entities "zhlt_usemodel " (target entity must have origin brush within). This feature is available in vluzacn compiler and copies "brush-model" of another entity brush, so they both use same precache slot for this "brush-model". It is useful if you use same exact prefabs a lot that are entities. For example exact same bhop blocks, exact same torches etc. Same principle as you use one tree model and put it 10 times in your map - it is still 1 precache slot.

Originally posted by SadPuppy

The only thing is that the animation either keeps going or you turn it off, but that is visually and it doesn't matter (ie after hitting stop button the timer still shows time).

Finally i figured out how to use zhlt_usemodel properly, it took a while just because i had no idea how to add keys in general lol. Also it forced me to switch to VHLT3.3 from SHLT3.9, that's a shame but i was quite sure that SHLT3.9 is latest and best version of compilers, probably i thought so because of version numbers. I think zhlt_usemodel trick is most useful as improvement for my skills, other techniques were quite familiar for me for long time, still i thank you guys for sharing experience and opening my eyes about VHLT compilers :D.