Please stop fighting, or I'll have to close this thread.

8.If you do the "make Jazz a spaceship" thing and go near a "Fat Chick" enemie, she'll SLAP the spaceship about 100 metres, (if this were real life,) across the room!
End result: Myth BUSTED

Not true, did you actually do it? I made a level where you can't see Jazz (he is covered by a car on a layer with X Speed=0 And Y Speed=0) and just sat there as a "fat chick" came over and slapped Jazz. He flies back about 30 tiles (I estimated) but the car stays with him.
End Result: Myth UN-BUSTED

Originally Posted by ZAPPER

Not true, did you actually do it? I made a level where you can't see Jazz (he is covered by a car on a layer with X Speed=0 And Y Speed=0) and just sat there as a "fat chick" came over and slapped Jazz. He flies back about 30 tiles (I estimated) but the car stays with him.
End Result: Myth UN-BUSTED

ZAPPER McHalibut saves the day!!

... sorry, couldn't resist.

Originally Posted by ZAPPER

Not true, did you actually do it? I made a level where you can't see Jazz (he is covered by a car on a layer with X Speed=0 And Y Speed=0) and just sat there as a "fat chick" came over and slapped Jazz. He flies back about 30 tiles (I estimated) but the car stays with him.

Aside from the 100 metres/30 tiles issue, that's exactly what Ischa said .

Originally Posted by ZAPPER

End Result: Myth UN-BUSTED

WTB, that was the dumbest thing I've ever read. By the by, you were supposed to return yesterday.

Originally Posted by Cooba

Aside from the 100 metres/30 tiles issue, that's exactly what Ischa said .

He said "Myth BUSTED," meaning he claimed it didn't work.

From N00b:
Originally Posted by ZAPPER
End Result: Myth UN-BUSTED

If there is a myth UnBusted, we always call it Plausible or Confirmed.

When is a myth:
Busted: It is not true. It is impossible that it will happen.
Plausible: It can happen, but it is extremely improbable or not practical
Confirmed: It is true. Everything is possible.

Nice job reviving a topic to state something which is known to mankind and dictionaries alike for years...

Originally Posted by JazzBusters

From N00b:
Originally Posted by ZAPPER
End Result: Myth UN-BUSTED

If there is a myth UnBusted, we always call it Plausible or Confirmed.

When is a myth:
Busted: It is not true. It is impossible that it will happen.
Plausible: It can happen, but it is extremely improbable or not practical
Confirmed: It is true. Everything is possible.

(-) we don't care,please let the thread die.

...let this accursed thread die. Please.

Kids kids kids, the best way to let a thread die is to stop posting in it, so how about doing that?

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

My RF crate never seems to respawn properly. Is it because of lag?

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.

good findings man

i like this show

Yeah, it's awesome.

I've got a myth:
When your score is full, (as in all the zeros are nines,) and I get one more point, Jazz 2 will crash.

That myth is completely false, it will go into negatives once another point is gained and then all the way back to positives.

Why don't we test both myths? Mine and yours.

Because awhile ago I already did somthing like this, It was in one of those high score threads and I claimed to have a high score of 4294967295. (That number is the exact maximum of four bytes, the amount of bytes that stores the score variable) of course usually that number would be negative (with a signed byte) so as the score went up that value would have the gained points added to it, and because of the way four signed bytes work it would eventually become negative (about at halfway.). JJ2 would still just add more to it, and after it became negative it would get closer to zero as points got added (but the actual four bytes would keep increasing) and at 4294967295 it would be -1 where if another point was added it would go back to zero. Just so you know, the way I got that screenshot of me with 4294967295 points was by using the value in the highscore menu instead as it was unsigned.

MYTH BUSTED.

Pretty much what birdie said. There is no reason why it should crash, as that would show an utter disregard for sprintf().

This is a great thread.

Now, I have a Myth. The Secret Level events don't always work. I was playing fearofdark's "War of the Rabbits" pack about 2 weeks ago. I went to the secret level event to go to the 2 Industrius levels.
After completing them though, I was not warped back to where I found the Secret.
Instead, it went to the Turtemple intro. After trying to go to the next level I was sent back to where the secret was.
Why did this happen? Is it just buggy?