How can mappers help to prevent the infamous Particle Crash?

Posted: March 4, 2015 by Kaemon in Kaemon's Rants, Mapping Tricks, Special

So, I briefly mentioned this on the previous post, but since it was getting quite long and I didn’t want it to become a (bigger) wall of text, I decided to keep this information for a new post, while also help myself with the current plan of updating the blog more frequently (once a week is the idea).
Special thanks to both Detonator and Enviolinador for discovering how and why the particles were crashing, allowing for a “fix” to be found.

One last thing before I proceed to explain the “fix“: This is a guideline that mappers need to follow in order to prevent (or at least reduce) the chances of the Particle Crash from happening. Is NOT a quick fix, solution nor plugin that the servers can add to prevent the particles from crashing, but something that ALL mappers should follow from now on when working with particles.

So… Why do particles crash after playing certain amount of maps? Well… Like with all the other limitations that mappers face when doing a map, it turns out there is also a limit for how many particles can be handled, but instead of being a limit map-wise, is a limit server-wise. After that limit is reached, the server can’t process any new particles and starts to replace them with red crosses (as seen in the screenshot bellow).
This limit is on 2048 particles (default ones like fire or the C4 explosion also count towards reaching it), and after 2048 particles have been loaded in total, the server won’t add new ones to the list and the red crosses start appearing. This is what people refer to when they talk about “crashed particles“.
Now… If you had already one particle loaded (like let’s say “Ultima” from playing Mako Reactor), this one will be already on the list, and if the server goes back to Mako Reactor (or another map that uses the same Ultima particle), this particle will still work, even if others particles (that weren’t on the list) don’t, and this is one of the reasons why sometimes only some particles seem to be broken, and not all of them.
Also worth mentioning that this list of 2048 particles (minus default ones, not sure how many there are) fills up really fast. Not only are there some maps that use a huge amount of custom particles (like Harry Potter), but there are some (most notably Michelle‘s Exorath and Hannibal‘s Paranoid, Mako Reactor and Minas Tirith) that even if they don’t use that many particles, they fill the server with literally HUNDREDS of unused particles present in their respective particle manifests (yeah, those also count! Remove them!).

When particles crash, you see red crosses instead of the desired particle.

When particles crash, you see red crosses instead of the desired particle.

The thing is (and here is where the “fix” resides) is that if a map contains a particle named exactly the same as one already in the “Server’s Particle List“, it doesn’t add a new line, but instead replaces the existing one with the new one.
So what the guys a Rules of p_ started to do in all their ports after this discovery, as part of fixing the maps and doing the best ports possible, was removing all the un-used particles from the manifests and renaming the remaining particles with the following nomenclature:


What then happens, is that all the maps ported by them, even if each has 1000 particles on their own, the new particles will just replace the previous map particles with a new set named exactly the same, without increasing the “Server Particle List” and completely avoiding the particle crash.

The problem with this so-called-fix? ALL the mappers should do the same for their own maps. Since the guys at Rules of _p were the first ones to start doing this (for CS:GO), and they already settled for the “custom_particle_xxx” nomenclature (no caps, three digits, even child particles being named with just the following number) I decided it would be best if we used the exact same nomenclature in CS:S to keep things simpler and help with later ports.

So that’s it… There are some CS:S maps already following this rule of naming their particles in this manner. Most notably the newest versions of both Slayerdragon‘s Westersand and Skullz‘s Harry Potter, which also happened to be some of the biggest particle-consumers.
I assume Slayerdragon will eventually do this fix on Paranima (when a new version is needed) and his upcoming maps, and I can assure you that both Mako Reactor V6 and the Paranoid Rezurrection fix being done by Zuff will use this nomenclature as well when they are out.

Now we can just wait for some mappers to follow our example on their future maps to help alleviate the particle crash problem; and even if not all of them follow this path and particles still crash, at least those that do use the “custom_particle_xxx” nomenclature will have bigger probability of their map’s particles properly working, since chances will be that those names are already in the “Server Particle List” by the time the crash occurs.

Until next time!

  1. Luffaren says:

    Good post dude, spread the word.
    Also, go back to mako v6.

  2. Kaemon says:

    And you go make a new Predator version with the particle “fix”, and while you are on it nerf the Minigun, the Pushgun, and freaking fix the elevator in the exact way I told you so many years ago!

  3. Kaemon, don’t forget the ammo glitch (Hydreigon told on pF forum to Moltard, but was on a dead end). 😐

  4. Hydreigon says:

    It was because predator almost reaches the limits in brushes and edicts. For predator v4 to ever see the light of day, the following needs to be fixed.

    -Hyper nuke bug (Moltard although fixed with entspy).
    -A teleport bug on ultimate where some afks can delay the round.
    -The ammo glitch I already mentioned
    -The stage 1 predator’s hp is messed up. For some reason, having 20 ppl makes the pred fight impossible.
    -The target system kind of needs to be redone or edited (mainly so that items can be filtered without the use of entspy).
    -Fix some “glitchy” items and make them sort of useful (ammo, alien sample, claymore and flamethrower to be exact). Make it so that zombies have to be affected by the trigger ignite. A good example of a bomb placer and flamethrower are from envio’s maps.

    Although some people are thinking of an ideal new Pred version, v3 is fine the way it is (besides the particle “fix” absent. It’s still enjoyed by most of the community and still enjoyable despite the glitches.

  5. Anonymous says:

    Puklica just made a v3.6 of Pirate Port Royal fixing a glitch and doing the particle trick.

  6. Kaemon says:

    To Hydreigon and H.Troll, Luffaren isn’t working on a new Predator version as for now. Was just joking with him 😛
    And last Anonymous, glad to heard Puklicax did that 🙂

  7. Oh and btw Kaemon, since your Junon is comming forward (I think?), do you have any beta to test only for fun? (Same thing to Luff) 😐

  8. Anonymous says:

    @Hallucinogenic Troll
    Junon has no progress 😉
    Mako v6 has

    Anyway, wait for his weekly post.

  9. Hi!
    I recently got props bug (elevatot, helicopter, moving grounds ) that will drop players through of it.
    It is so annoying, I tried to figure it out but no help.
    It happen in all maps with elevator, helicopter, boat , moving clips like brigdes …
    What can cause it ? and how to fix ?

  10. Kaemon says:

    Hallucinogenic Troll, as the commenter after you correctly pointed out, Junon is not currently progressing. I have some ideas about how to solve that, but they will have to wait for Mako V6 to be released. More news on that on tomorrow’s post.

    nguyenbaodanh (I can’t believe I type this kind of nicknames instead of copy-pasting them), what you talk about is a quite common issue when playing multiplayer and may also be affected by the server settings (like having sv_turbophysics 0/1).

    The best solution is NOT to use props for those purposes. Real vehicles that players have control over will always be susceptible to this kind of problems or things like not working at all (not enough “strength” to move) if too many people are on them, but you should use func_vehicle as the “solid” part (and not a prop or anything attached to it) and keep it as simple as possible (1 brush better than 2, etc). Also make the “details” (if the vehicle has any) as non-solid entities or props to reduce the collision mesh to a minimum.
    Another way of reducing the times the problem occurs is giving players more vehicles, so they are more spread out, as the engine can handle better 5 guys per helicopter one 4 helicopters than 20 guys on a single one (but not 100% sure, don’t quote me on this).

    For elevators, moving grounds or anything that just goes in a straight line, the best entity possible is func_movelinear, which is cheaper and more responsible than tracktrains or doors (or parented props, of course). Also, keep them as simple as possible (an elevator can be just 1 brush (the floor) or 2 (if it needs a ceiling), most of the time you don’t even need the walls, as those can be static invisible brushes surrounding the shaft. And as with vehicles, make the details into a non-solid entity or prop (Mako Reactor’s props in the elevator are all non-solid).
    If you want the “moving ground” (or whatever) to be something quite big or complex, sometimes it can be a nice idea to cut it into multiple func_movelinears, I used this on the “Spike-Wall-Trap” in Serpentis Temple, were two walls full of spikes try to crush the players while they have to climb them to safety. Each of the two walls is made out of 5 func_movelinears, one being the big flat wall itself, and the other 4 being 4 different rows of spikes, to reduce the “lag” and “stickiness” problems for having them being too complex (too many brushes) or having too many people on the same one at once.

    Also, next time you want to ask something like this, please use the mapping forums. Even if they don’t look that active I check them almost every day and answer everything at the best of my possibilities (even if that sometimes means linking you to the answer of someone that already asked the same, telling someone that knows more about the subject to answer you if he can (really noticeable in particle-related questions) or even if my answer is going to be “sorry, I have no idea” :-P)

    Link to my crappy Mapping Forums: