He meant moving the bullet packets to TCP

I doubt airs could completely be prevented, because of internet latency.

I have taken some measures to try to reduce the amount of discrepancy between clients, and we'll find out how well they work come release time, but as Trey says, it's not an issue that can be eliminated completely. If a packet, TCP or UDP, takes longer to arrive than it should, JJ2 can't go back in time and retroactively add the bullet.

Okay, but, any lag lowering would be crucial.

Originally Posted by Just a Random User

Okay, but, any lag lowering would be crucial.

I suggest getting a better Internet connection

Yet moving bullets to TCP would still improve lag issues. UDP being "here! Catch the packet and I don't care if you receive it!" just doesn't do it. A better connection won't help with that either. I am not sure what the effect of using TCP would be either actually. TCP is slower but above all UDP is a lot better for sending multicast/broadcast packets. Are the bullet packets sent to everyone individually (unicast) or using multicasts? If they are unicasts changing to TCP might be worth a try.

Originally Posted by cooba

I suggest getting a better Internet connection

Thanks for suggestion, but it's not me. I have a fine connection (6Mbit/s), it's the other players, they lag sometimes, and I don't see why wouldn't you change bullets to TCP if you know how and if that lowers the lag.

Originally Posted by Just a Random User

Thanks for suggestion, but it's not me. I have a fine connection (6Mbit/s), it's the other players, they lag sometimes, and I don't see why wouldn't you change bullets to TCP if you know how and if that lowers the lag.

I have a 60mbit connection and experience lots of packet loss, I assume it has something to do with UDP... Many bullets just don't show up.

Do you, either of you, have any proof it's bullets not showing up rather than bullets showing up with invalid velocity, initial position, et cetera (purely a fault of JJ2 packet structure and not protocol used)? I never experienced the former.

I guess using bigjazz to play 1600x900 could show you. I can perhaps make a recording where it's clear bullets just don't appear at all even though you see the enemy shoot. Seeing the player shoot but not see any bullet appear is most likely a protocol issue imo.

...but doesn't bigjazz fail to show many distant sprites regardless of whether they're bullets or not? Besides, I did notice certain bullets don't show up if they spawn off-screen, but since there's a rule to it, it can't be protocols' fault. UDP issues will happen randomly and not orderly.

Originally Posted by Sir Ementaler

doesn't bigjazz fail

Yup

I was gonna scratch the bigjazz part cause I realized that myself but too many people were active in the forum so I didn't bother. I am talking about someone shooting in the normal 640x480 screen, a couple of tiles away. It's not a bullet spawning off-screen, it's a bullet shot from in my screen and not showing up at all (difficult to dodge?)

I would suggest writing a quick .j2as to count the number of bullets spawned, from a single player or overall, and compare results across computers.

Originally Posted by Sir Ementaler

Do you, either of you, have any proof it's bullets not showing up rather than bullets showing up with invalid velocity, initial position, et cetera (purely a fault of JJ2 packet structure and not protocol used)? I never experienced the former.

I just said what Nerd said. I have no proof for anything. I really know nothing about TCP/UDP and bullet spawning, so whatever you say it's okay for me.

The solution to bullet desync is not related to the protocol they're sent on; TCP vs. UDP is nothing but a tradeoff between delay and loss. I think bullets are sent over TCP, due to the way they "stack up" and get shot all at once during lag spikes.
It's a combination of two issues within the protocol: bullet velocities being calculated from local player velocities (which may vary across server/clients) instead of being sent with the "bullet shot" packet, and seekers moving towards players' local player positions (strongly desynced by extrapolation and packet timing inconsistencies).

To eliminate airhits, bullet velocities could be added to the packet that is sent when a player fires. To deal with seekers, the server could send the position of all (nearby) seeker bullets every few frames and let the clients extrapolate from there. This would preferrably happen over UDP. I have no idea how difficult it is to introduce new packets to JJ2's protocol, but these two changes should reduce the frequency of airhits by quite a bit, at least in low to moderate packet loss conditions.
It may be necessary to take AngelScript into account here (perhaps by adding a function that disables syncing for specific bullet types), as some levels might manipulate bullets client-side in some way for gameplay or visual effects.

3HKs are the result of player health not being updated reliably in some way, but I'm not sure where exactly the problem is located (health packets over UDP? Unusual client side condition needed for health update?), since I haven't looked too much into the protocol. The solution would be to periodically update player health, perhaps over TCP. Again, it requires protocol updates; hopefully it's doable.

Protocol updates are doable and Plus already contains quite some of them as a matter of fact.

I think 3hks happen when the server and the client differ in their opinions about the client's number of hearts. I figure the client dies if the server's opinion is that the client's last heart has been taken. I must admit, though, that I do not know what would then happen if the server would think the client has more hearts than the client itself thinks it does.

Originally Posted by Jerrythabest

I think 3hks happen when the server and the client differ in their opinions about the client's number of hearts. I figure the client dies if the server's opinion is that the client's last heart has been taken.

That's also how I understand it; what I am not sure about is the exact source of the problem: whether it's unreliable transfer of the health packet at protocol level, or perhaps the client deciding to discard the health update for some reason (I've seen 3HKs occur somewhat more frequently when the player gets stuck against a ceiling by seekers in a way that the ceiling prevents further seekers from targetting the player).

Originally Posted by Jerrythabest

...what would then happen if the server would think the client has more hearts than the client itself thinks it does.

It rarely happens anymore because of blur's carrot synchronization fix, but the player will probably either silently ignore the hit without entering the blinking/invincibility state, or play the hurt animation and blink normally, and just stay at the same number of hearts.

A general solution for periodic health synchronization in the protocol would solve both of these issues anyway.

Originally Posted by Jerrythabest

Protocol updates are doable and Plus already contains quite some of them as a matter of fact.

I think 3hks happen when the server and the client differ in their opinions about the client's number of hearts. I figure the client dies if the server's opinion is that the client's last heart has been taken. I must admit, though, that I do not know what would then happen if the server would think the client has more hearts than the client itself thinks it does.

I can tell you how my JJ2 acts when the latter happens. If I get hit at the moment I take a carrot, I at times go down to 2/1 heart (client side). However, if I get hit again I don't die, I just go back to the hearts I had before. If I take a carrot while I'm 2/1 and the server thinks I'm 3, it just seems like I take a fake carrot. The carrot however stays and my heart pops back to 3.

Originally Posted by Vegito

I can tell you how my JJ2 acts when the latter happens. If I get hit at the moment I take a carrot, I at times go down to 2/1 heart (client side). However, if I get hit again I don't die, I just go back to the hearts I had before. If I take a carrot while I'm 2/1 and the server thinks I'm 3, it just seems like I take a fake carrot. The carrot however stays and my heart pops back to 3.

I can back this up from my own experience too. My assumptions at first times were of course that I had mislooked my health when trying to take a carrot, but once it started to happen regularly and I was certain about what I saw it got obvious that my health was shown as lower number than it was supposed to be.

...ok...

Can the /ready command give coins too? Not infinite coins, but just some amount like GMR.

Originally Posted by KRSplatinum

Can the /ready command give coins too? Not infinite coins, but just some amount like GMR.

bool isGameStarted;

void onPlayer(jjPLAYER@ p) {
	if (jjGameState == GAME::STARTED && !isGameStarted) {
		isGameStarted = true;
		p.coins = 10;
		jjAlert("You get 10 coins!");
	}
}

Like Cooba said. The basic problem with this is that a sensible amount of coins would depend completely on the architecture of the level. The only way to do it right is via AngelScript.

This will be bizarre, so I'm sorry in advance - I have not applied a patch other than the 1.23 one (was it called that?); so...do I just download the file and run or is it far more complicated? Thank you.

LTNS! The installation section of the readme is a little less clearly organized than it could be, but in sum, you extract all the files into your main JJ2 folder and run plusifier.exe. This will create a modified game file—usually Jazz2+.exe—which you can run.

If LTNS is "long time no see", then same here. I had a huge rush of nostalgia, I searched for my old posts and somebody else's and then...well, I was hooked.

And thank you.

Originally Posted by Violet CLM

Remind me to tell you sometime what the "RandomFly" parameter on crate events does.

do tell, please

okay, so, like, don't tell anyone I told you this

If you shoot a crate with RandomFly set to 1, if ExtraEvent is set to anything other than 0 (doesn't matter if NumEvent is set or not), if you're playing in Hard, if there are bee objects in the level, there is a one in four chance that the crate will spawn a bee.

And thus not even a fly!

Now that's downright comedic. XD
I wonder who added that feature, and why, since it seems pretty much useless.

New release!
As ever, click here to download.
And click here to download the example levels, which have been split off from the main archive due to their multitude.



The full list of changes can be found over here. This is a major update that focuses on a number of areas, including brand new splash screens (one each for 1.23 and TSF), lots of new ways to draw tiles and sprites both with and without AngelScript, various improvements in the netcode, vastly increased 1.23/TSF interoperability, increased AS control over objects and various other things, mouse aiming, and so many bug fixes that some of the bugs fixed you never even knew existed. We're very excited (and also burnt out, but mostly excited) about this release, and we hope you will be too!

hello i'm new here... ok so here's the situation:
when i try to start jj2 with the new update i get "jazz jackrabbit 2 has encountered a problem and needs to close" popup error
when i run it with windows 95 or windows 98/windows me compatibility mode, it works, but not single player or multiplayer because after loading a lvl i get an access violation...

access violation contents:
access violation at address 1005CCD6h
attempted to "read" from address 00000000h
DS = 0023h
ES = 0023h
FS = 003Bh
GS = 0000h
CS:EIP = 001Bh:1005CCD6h
SS:ESP = 0023h:0013FB44h
SS:EBP = 0023h:0013FBE0h
EAX = 1h
EBX = 0h
ECX = 0h
EDX = 1570608h
ESI = Fh
EDI = 10h
EBP = 13FBE0h

omfg how can i fix this heeeeeeeeeeeeelp
i use Windows XP Professional Service Pack 2...

Hi juanpablo, this sounds like the kind of error that might be difficult to diagnose over the JCF. Do you have an instant messenger account I could contact you at?

I'm getting pretty much the same thing with 1.23+. It works fine through the splash screen and menu, but when I load a level the game crashes. Using TSF+ works fine, though.

I got an access violation when I pressed on X to close JJ2 window.

EDIT: I just came up to something very frustrating what happens very often. While spectating someone, if he has a PU, the ammo he picks up shows as non PUed sometimes. Hope it's fixed. I spectated someone in a server where I am not sure a new plus is installed and it worked fine.

This is awesome! great work jj2+ team.

One request: please have an configuration .ini for changing the controls during mousemode! I can imagine people want to play with the right mouse click or mouse wheel(weapon select perhaps or scrolling through weapons) and W,A,S,D for movement, W or space being the jump button. I think it's so groundbreaking it's not weird to have a set of different controls during this mode.

Originally Posted by Violet CLM

Hi juanpablo, this sounds like the kind of error that might be difficult to diagnose over the JCF. Do you have an instant messenger account I could contact you at?

you gotta get skype... a messenger program... because windows live messenger is no more, they have moved to skype...
my skype account is juanpablobouzas
oh and i don't have any instant messengers... like AIM (AOL Instant Messenger)... or something like these...

I'm amazed. It is finally out! Mouse aiming is REALLY AWESOME. Custom menus and HUD elements! This is the best update ever! Though I found something abnormal when playing plusPalettes.

Doesnt work for me. Crashes for both 1.23/TSF with an AV whenever i load a level...

Surprising how it crashes some while working fine for others (like myself). Although I haven't participated much in development and testing this time around, judging by the development discussions of the past weeks I'd say this release has gone through a longer and more intensive testing phase than any previous.

I wonder, if you people rename or move away your jazz2.cfg and plus.ini files, does it still crash? My idea being it could be some specific setting causing problems.