Download here

Suppose that client 1 fires a bullet at client 2 in an online server. Because it takes time to transmit information from one computer to another, inevitably client 1, client 2, and the host will all have slightly different ideas of where client 2 and the bullet are, and most importantly, whether they come into contact. Normally, JJ2 lets the server host decide whether the bullet hit client 2 or not. Sometimes this makes people upset if what they saw doesn't match what the server saw.

This build lets you play around with that dynamic, introducing three new boolean chat commands, all of which can be enabled or disabled independently. If you see a bullet hit client 2, who do you have to be for what you saw to matter?

• If /bulletserver is on (default), the existing behavior is maintained: client 2 gets hurt if the host sees the bullet hit.
• If /bulletshooter is on, client 2 gets hurt if client 1 sees the bullet hit.
• If /bulletvictim is on, client 2 gets hurt if client 2 sees the bullet hit.

Let us know (by posting in this thread) if anything feels good here or if this isn't an avenue worth pursuing. This is a very rough proof-of-concept build that doesn't even attempt to account for edge cases beyond, like, basic Battle servers where every player should be able to hurt every other player. This build is only interoperable with other players running this same build: you cannot join servers running other builds, nor can servers running this build be joined by clients running other builds.

I must admit I haven't tried the build because it requires a lot of setup (like other testers, server hosting, lag and replicating scenario's). It would be hard to make a fair side by side comparison. I think for a lot of players the 'faster packet build' is more easy to understand. It also helps that there is a video that explains the side by side comparison.

Hot take: Most players are vocal about lag when in reality it's just their frustration. If there's lag then it's often not as onesided as believed.

A connection delay between players is inevitable, it's just about whoever gets to be right about what visually happens: The shooter, the server or the victim. I'm confident that shifting the dynamic will just be controversial anyway. Players can think they benefit from a different setting until they are experiencing being on the worse end. I like the way it currently is, because the server deciding is a nice 'middle ground'.

I feel like the public test build is pointless and not something worth pursuing. Before testing I think it's better to question if there is reason to change something in the first place (and opening up a discussion that is a big can of worms). The fact that some players are frustrated seems a bit too flimsy as a reason to release a test build to me.

Players will always be frustrated (read: passionate) about the game. I'm sure that the server deciding what happens also benefits those same players in some ways, but that's not what players remember. I think even after collecting enough feedback a change will be too controversial to put through regardless.

Here's my experience from other games: I've played a P2P online game called Awesomenauts for many years where the shooter decides what happens (for damage calculation). This was not always fair due to the laggy players knowing their weaknesses in their connection and thus start adapting to a playstyle that works best for them. One of the things they do is go for swift strikes (playing like an assassin). Normally players have a very short time to react and retaliate to this playstyle, but with laggy players they now couldn't because of the damage already applying to them before it happens. Similarly, there's crowd effects in the game that work the opposite way (calculated from the victim), such as an area snare. You could never catch someone laggy in it.

In short: Shifting it will keep players unhappy. With >300ms games can be very frustrating and unfair. But that will always be the case.

I recently played in a public Zeal Duels server that was hosting this build. I recorded a few of those rounds (but only one of them is published so far). Video footage:

• https://www.youtube.com/watch?v=IlBhBdpSOrA

Some findings so far:

• Playing with all 3 reporter settings (shooter, server, victim) can make the game quite messy in the sense that it will become a lot harder to evade any bullets at all, since you'll account for multiple perspectives at once. Basically the more settings you enable, the higher the total death count in general, based on anecdotal experience in-game.
• I haven't got to test the shooter-setting or a combination of shooter- and server-settings yet, but I predict that would make players complain the most about "airhits" since those hits registered are the least likely to be in sync with which bullets hit you on your screen as a victim.
• Playing with server- and victim-settings enabled seems like it might be a combination that would make players complain the least, since at least that way a client should not be able to "ghost" a bullet that clearly hit them on their screen. Now I'm wondering does this also prevent the "bullet bounce" bug from happening locally? If so, that could eliminate complaints about enemy players bouncing off bullets that clearly hit them from a shooter's perspective.
• On the other hand, when playing with server- and victim-settings enabled, from the shooter's perspective there may be situations where a shooter does see an enemy getting hit from their bullets that didn't even touch on their screen, but the shooters are less likely to complain about cases where an enemy unexpectedly took a hit from their miss, than victims who clearly evaded the bullets on their screen.

EDIT: Oh and one more thing, that probably does not happen in the above video but did happen in some other rounds I played in; It happened me multiple times in a round that I took hit quite at the same time as I collected a carrot to regain health. Now it seemed that my health went out of sync with the server, since my game showed my health as 1 after taking the carrot, but I didn't die from the next hit I took, and my health was again 1 or 2 (don't remember which one exactly). I haven't looked at the code personally, but could it be, that there is a corner case where a client registers a hit on themselves, while the server does not see it that way, but instead sees them take a carrot, thus the health goes out of sync between the client and the server? Or is this business as usual in JJ2? Just guessing...

Here are the two videos, which SJ recorded:
https://www.youtube.com/watch?v=IlBhBdpSOrA (Ancient Museum) (sj posted this here already)
https://www.youtube.com/watch?v=ELKXBffosxA (Jungle's Edge)

Here are some bugs which were reported/seen in the bullet reporter test version:
- what SJ mentioned at the end of his previous comment.
- spring stopped working midgame https://imgur.com/npTNR35 (not on video)
- In the recording on Jungle’s Edge at game timer 4:15: SJ kills DZ, but as the dying rabbit stays on screen, Empive shoots the rabbit again and gets the kill instead.
- In the recording on JE, another player reports "hearing the damaging noise like 4 times every time" during the game.
- In the recording on Ancient Museum another player reports "getting hit after dying and respawning with 1" during the game.
- In the recording on Ancient Museum another player reports "respawning with same ammo" during the game.

I agree with what SJ said, especially regarding the potential benefits of using both the victim-setting and server-setting in combination. Maybe this can fix our own lagbounces (=bullet touches my rabbit but it bounces off the bullet without losing health) on our own screens, thus reducing the frustration of opponents during the game and leading to a better game experience.

The above test build has now been updated to include a community requested enhancement to the networking code. Direct link here.

In addition to the bullet reporters functionality and configuration as described above, this build now includes additional configurations to change the interval of how often an online game server and its clients exchange packets.

Just a disclaimer, that since I didn't work on this enhancement from start to finish (and this is just a public testing phase with configuration options before finalizing the actual enhancement for the next JJ2+ release), there may be some gaps or assumptions in my knowledge on things, and I'm basing the description on what I've been told/heard my teammates discuss about this enhancement.

Just like the bullet reporter commands, the packet exchange intervals are controllable with commands for the server and remote admins. In addition, the server menu of the game window has been temporarily adjusted to include menu options to switch between different interval levels, plus the levels can be configured into the server section in the server's plus.ini-configuration file.

The server/remote admin commands are as follows:

• /pxiserver (-1-5/auto)
• /pxiclient (-1-5/auto)

The command /pxiserver, sets the interval in game ticks, of how often the server should send packets to its clients, and the command /pxiclient sets the corresponding interval of how often clients should send packets to the server, when they are connected to that server. The acceptable values for the command are -1 to 5 and auto (where auto stands for automatic and -1 is an alias for auto). The value auto (or -1) stands for the current, original behavior of the game (or Plus) regarding this, which is that the game adjusts the packet exchange interval dynamically based on the number of active players in that server.

In JJ2 the game ticks are run 70 times per second, so 1 tick takes roughly 14 milliseconds. As an example, if we issue command /pxiserver 1, it means that the packets get sent by the server based on the time it takes for 1 tick to be executed, so every 14,2857... milliseconds. Issuing /pxiserver 2 will then increase that interval to 2 ticks, so 28+ milliseconds, and so forth. Issuing /pxiserver 0 is practically the same as /pxiserver 1, since the packets won't be sent more often than once every tick anyway, so roughly 14 milliseconds, but setting the interval to 0 will guarantee that the packets get sent every tick even in theory, since there are some corner cases where an interval of 1 game tick is not always reliable.

As mentioned earlier, the packet exchange intervals can also be controlled via configuration in the plus.ini, under [Server] as in the example below:

PXIServerInTicks=1
PXIClientInTicks=2
PXIServerInTicksLAN=2
PXIClientInTicksLAN=3

The configuration keys with the LAN-suffix are currently used as a default for games hosted via the Local Network TCP-menu or simply just delisted servers. For global internet games, just use the top-most keys without the LAN-suffix.

Finally, this test build is still a very raw version of the enhancement and like with the bullet reporters-feature, there may still be some cases what we have overlooked or it could be that some of the configuration values available are of no other use than simply discovering the differences between different values. In essence, the lowest intervals ensure the best responsivity of the game between the server and its clients, but they will be also more heavy on your internet connection. This build is here to try those things out.

As with the previous build; This build is only interoperable with other players running this same build: you cannot join servers running other builds, nor can servers running this build be joined by clients running other builds. So if some players are running a build that has only the bullet reporters-functionality in it, they'll need to re-download this patch again.

Enjoy!

Some findings so far (I only played online CTF matches):

When playing CTF online with the lowest possible packet interval rate, the game basically couldn't be any smoother, when it comes to player movement of remote clients and overall experience. That combined together with having the bullet reporter settings of server and victim enabled makes for a game that at least from my perspective is lag-optimized to the maximum.

Basically such a game has all the weird lag issues eliminated, that typically happen in a friendly/competitive CTF match, like players getting hurt/roasted by bullets that looked like they were far from being a hit on their own screen or remote players moving in a jerky way on local screen. I think having the victim-setting enabled as a part of the bullet reporters-feature plays a big role in ensuring that you always get hit from bullets that you land on in your local screen, which further seems to eliminate the typical "bullet bouncing without taking damage when should"-cases that happen in online games. However, I think it is good that the server is not being fully ditched as being a "secondary" reporter, so that there won't be too much of a synchronization issue between those clients who shoot bullets and those who touch them.

So, I would say that lag-wise I am really happy about how this combination turned out , but bug-wise there are some things to take a closer look into.

One of the bugs seems to be, that springs (randomly?) stop working for certain clients middle of the game. This did not occur to me yet, but on one of the rounds I had 2 other players, DanZeal and Spyro, reporting about springs not doing anything. I'm not completely sure if the springs in question started to work again later on or whether it was all of the springs or only some of them. If more input is required, I suppose Spyro and DanZeal can be contacted, e.g. on Discord. Also, based on the rumors I heard earlier, e.g. from ak-47, it seems like this is something that has happened already on the previous build of bullet reporters w/o pxinterval-changes, but I don't recall who experienced what. I think Kev might recall this better too?

Another bug that happened to me personally in-game, was that I seemingly went from 1h to 0h and did not die or respawn, after taking a hit from a bullet. The issue resolved only after taking another hit from a bullet that finally ended my "zombie mode".

I recorded several rounds of my CTF games, but only uploaded a few of them onto youtube so far. Anyway, here are 2 good examples of the findings:

https://www.youtube.com/watch?v=qvHMEUwdM3g - On this round we played with the lowest pxinterval-rates and with ONLY victim-setting enabled. DanZeal and Spyro reported that their springs stopped working mid-match, around 4:30 video-time marker. Also what ak-47 writes in the chat at 5:55 may or may not have something to do with the bug that I experienced with having 0 (or negative?) health and thus DanZeal was not able to pick up carrots when supposed to.

https://www.youtube.com/watch?v=ACrk3wEN4E4 - On this round we played with the lowest pxinterval-rates and with BOTH server- and victim-settings enabled. Around 1:00-1:15 video time I experience the bug regarding health I mentioned above.

Thanks, some interesting preliminary data. Are all your tests with people with two-digit pings?

No, but the only player with a 3-digit ping that I can recall testing this with is Empive, who said that lag-wise the experience was positive, iirc.

Here's my summary of feedback we've received so far, as far as I can tell:

• /bulletvictim is getting generally favorable reviews, especially when /bulletserver is also enabled. We don't know if people would like it to be optional or mandatory.
• We don't know if anyone has tried /bulletshooter for more than a few minutes, or without /bulletvictim also on. It is described as having its intended effect.
• We don't know if anyone has tried any of these commands in any gamemode other than CTF.
• We don't know if anyone has tried any of these commands in conjunction with any other settings that interact with bullets, such as /evilice, /friendlyfire, /frustration, /mutualinjury, /noblink, or /weakpowerups.
• We don't know if anyone has tried any of these commands in a server where the host is one of the active players instead of an idle server.
• There are reports about bugs with /bulletvictim where clients seem to have the wrong amount of health, including not dying when they are supposed to. Nobody has reported a reliable method of reproducing this.
• There are reports of a bug where springs sometimes stop working for certain players. We don't know whether it's all springs or only some springs, or whether they ever start working again. Nobody has reported a reliable method of reproducing this. Nobody has reported anything about the spring objects' properties (e.g. jjOBJ::state) when they are unusable.
• People seem to like /pxiclient 0. However, we don't know what other numbers people have tried, if any.
• There seems to be some hesitation around /pxiserver. We don't know how widespread it is. We don't know what numbers people have tried. The hesitation seems to involve a misperception that it affects bullet speed somehow.
• We don't know if anyone with slow internet speeds has tried either /pxi command.
• We don't know if anyone with a high ping has tried either /pxi command, other than Empive. We don't know how long Empive tried or what the context was.
• We don't know how the /pxi commands affect contexts where bumping into other players is important. (For example, street fight and pushing frozen players.)