Hey guys!

I've always thought JazzBusters was such a cool idea. It is unfortunate that many in the community did not agree with their ideas though. As such, I have brought it upon myself to bring back the good name of the JazzBusters.

Today's Myth
In the style of the old JazzBusters, our main investigator Neobeo decides to take a look.

Equipment needed:
Jazz Creation Station (JCS)
One Jazz2 running as server (v1.23)
One Jazz2 running as client (v1.23)

Test level used:


How the test proceeded:
The server was started using the test level shown above. The client then joined the server. The initial level was actually made without the ham. However, the first thing that Neobeo noticed was that the Full NRG carrot would be missing. So a piece of ham was added to the level, then server and client restarted. This time, the ham disappeared. What was going on?

Finding #1:
The last event in the level does not get initialized for the client. By not initialized, this means that the ham would be shown if it was not run by a generator. This effect holds the same for trigger or destruct sceneries. As shown by the ham, "last event" is searched top to bottom first, then left to right. While this was just a side effect of the experiment, it shows that events can disappear without it having to be lag.

Proceeding with the test:
Even though the client could not see any ham, all the other events seem to be loaded ok. Being a greedy player, the client sidekicked through the entire horde of goodies. (Of course he got himself injured first so that he could take Full Energy Carrot.) It turns out, the seeker crate and Full NRG respawned, but not the RF crate or the Invincibility. What was going on?

Finding #2:
Not all events will regenerate after they are consumed. This time, lag was not a factor since the parameters tested were very small. Upon some investigation, the aforementioned items actually respawned on the server's Jazz2. The fact that it generates properly on the server but not on the client shows that there is miscommunication. It is tempting to think it is lag, but the same experiment done with buttstomping the RF crate produced the same outcome. This shows that events might not respawn, simply because Jazz2 is bugged.

Proceeding with the test:

When the client shot however, the RF crate regenerated. However this time, the seeker crate did not, since the server did not even see it disappear. Some investigation was done, and because of the RF crate being present in the server, it turns out the server saw "the client shooting an RF crate", which means the seeker crate was not smashed in the server.

Finding #3:
Shooting an RF crate can get it to respawn. At the same time, shooting a crate while having the server think you shot something else will cause a respawn failure. Again, this is not lag.

Proceeding with the test:
Just for completeness, the server and client restarted, with the server taking the horde this time. However, this time, the client did not even see the RF crate disappear. A re-test with the server buttstomping on the create confirmed the results. Also, the invincibility carrot scored a 50-50. Sometimes the client would see the server taking it, and other times he wouldn't. But once it disappeared, it disappeared forever.

Finding #4:
Remember how the server did not send a respawn instruction to the client for RF crates and Invincibility? Maybe it is the same reason why the server did not inform the client that either event was being smashed/consumed. As a side note, shooting the RF crate is unseen to the client as well. Once again, this definitely cannot be lag.

Proceeding with the test:
Well, it seems that there is nothing else to show in such a tiny level. So some tests were done on the ham instead. Apparently, if the client jumps on it (empty air), nothing happens. But if the server takes it, it will respawn for the client, and then function normally from there.

Finding #5:
Probably not so much related to lag, but still good to know that this minor bug has nothing to do with not being able to respawn, and thus, is not really relevant to this myth.

Possible improvements:
Could have tested with more clients than one. Unfortunately, resources were unavailable. (see post-experiment notes below)

Conclusion:
Well, well, haven't we answered the big question? "My RF crate never seems to respawn properly. Is it because of lag?" It turns out, the RF crate event itself is buggy. If the client smashes it, it does not respawn. And if the server smashed it, the client never knows it happened. The invincibility carrot is also buggy, but that probably isn't as important. Anyway, since it happened even without lag as a factor, there can be no doubt to the conclusion.
MYTH BUSTED

Post-experiment notes:
In order to minimise lag, both network-wise and cpu-wise, it was decided that a network was to be used. One computer would be the server, and the other the client. Of course, it is also possible to have both the server and client on the same computer. Also, the test was done with v1.23. Due to the lack of resources, it cannot be said whether the same effect will show in a TSF server.