Mar 3, 2023, 01:30 PM | |
Public test: bullet reporters
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?
Last edited by Violet CLM; Jun 10, 2023 at 11:53 AM. |
Apr 26, 2023, 03:15 PM | |
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.
__________________
Last edited by FawFul; Apr 27, 2023 at 01:13 AM. |
May 7, 2023, 01:58 AM | |
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:
Some findings so far:
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...
__________________
Find It Out SP: https://www.jazz2online.com/downloads/9371/find-it-out-single-player/ MP: http://www.jazz2online.com/J2Ov2/downloads/info.php?levelID=5021 |
May 20, 2023, 03:09 AM | |
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. |
May 22, 2023, 01:30 PM | |
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:
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!
__________________
Find It Out SP: https://www.jazz2online.com/downloads/9371/find-it-out-single-player/ MP: http://www.jazz2online.com/J2Ov2/downloads/info.php?levelID=5021 Last edited by Superjazz; May 22, 2023 at 02:11 PM. |
May 28, 2023, 12:40 AM | |
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.
__________________
Find It Out SP: https://www.jazz2online.com/downloads/9371/find-it-out-single-player/ MP: http://www.jazz2online.com/J2Ov2/downloads/info.php?levelID=5021 |
May 28, 2023, 10:19 AM | |
Thanks, some interesting preliminary data. Are all your tests with people with two-digit pings?
|
May 29, 2023, 08:00 AM | |
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.
__________________
Find It Out SP: https://www.jazz2online.com/downloads/9371/find-it-out-single-player/ MP: http://www.jazz2online.com/J2Ov2/downloads/info.php?levelID=5021 Last edited by Superjazz; Jun 4, 2023 at 11:34 AM. |
Jun 4, 2023, 07:43 PM | |
Here's my summary of feedback we've received so far, as far as I can tell:
Last edited by Violet CLM; Jun 4, 2023 at 09:32 PM. |
Jun 6, 2023, 10:12 AM | |
Let me reply to some of the points which violet made above here.
1) i only played and recorded one duel vs SJ with bulletshoot and bulletserver (without bulletvictim). Ofc this resulted in lagbouncing again. Otherwise i didn't notice anything special about it, except once i heard the "hurt" sound multiple times after sj got hit. and one time the hurt sound happened delayed. Anyway i dont rly see a big benefit from using /bulletshooter. And I'm being told the more hits are client-side, the more cheating can possibly emerge from it. Therefore personally I'm against the use of /bulletshooter. 2) we only played one battle round with bulletvictim enabled. it seemed to produce the usual /bulletvictim-realted bugs. and one of the players reported that a +1 carrot took him back to 5h when he was only 1 or 2h iirc. 3) We have following bugs recorded on video (with either only /bulletvictim OR /bulletvictim+/bulletserver): - springs stop working midgame but later continue working again in the same round, seemingly after u get roasted. - getting hit and instead of dying, staying alive with zero h on screen. like a zombie - getting hit by low ammo, then by a bouncer-PU and still being alive (with 1h on screen, according to the player who got it.) but this happened only once. - kills happening without a kill message or change in stats. Sometimes after respawning, the player gets 3hk. If the player had the flag when he died, he respawns WITH flag. - in one rly weird moment there is a carrotkill long before blinktime ends and the player respawns with flag. all happening together lol. - something seems to be wrong with the carrot when /bulletvictim is on. Ppl theorised that C seems to be client-side too then, bcs in some duel-rounds both players started taking their own personal carrot during the match as it always respawned on their screen long before it was supposed to respawn after the opponent had taken it recently. and it wasn't fake Cs. One time a player reports he cant take a C which he sees on his screen, but after he got roasted it worked again. - based on subjective perception, sometimes the animation of the roasted rabbit stayed on screen for longer than usual or moved up and down a bit. one objective bug which was seen was already reported in the first bulletreporter version in my comment above. there sj kills dz and dz's ded rabbit stays onscreen so empive shoots it too and empive gets the kill instead of sj. - the "hurt" sound by the rabbit after getting hit could be heard multiple times at once sometimes or it happened delayed. - sometimes players reported that they see other played warping (but i guess this is nothing new and idk if its related to bulletreporters). - sometimes nocaps happened but idk if its related to bulletreporters as its also not new. all of this is recorded on video. but i'd only bother to invest the time to look up the exact timestamps of the bugs, if it's required. If nobody has the motivation and willingness to further invest time into finding the cause of the bugs and fixing them AND to retest and analyse it if the bugs are gone, i'm currently prefering NOT to go through the vids again to give exact timestamps of the bug moments. but if there emerges more motivation in the community to further develop this, i can do that. Read my next post for more RELEVANT feedback about bullet reporters. Last edited by t3Kev; Jun 6, 2023 at 01:00 PM. |
Jun 6, 2023, 12:58 PM | |
Regarding intervals:
From my point of view, we should use the lowest/fastest intervals for both server and client. The game works very nicely with them. To my eyes, this is confirmed by the video recordings of everyone who recorded by now. It seems the slower/higher the intervals, the more „lag“-moments appear, although this is based on limited video evidence and "lag" still seems to be minimal with /pxiserver 2. To some people it seems that with /pxiserver 0 „hits happen too fast" and dodging bullets becomes more difficult. I’m not sure if this is true or not objectively, at least subjectively I can’t confirm this. To my eyes, the videos of everyone who recorded by now, show that hits and flying bullets look totally normal with the fastest intervals and look just the same as with slower intervals. (I also tested a certain hit-scenario in a standardised way with /pxiserver 0 and /pxiserver 5. Both looked the same to my eye.) Bcs of the delay, different clients sometimes see players and bullets at slightly different locations on their screens sometimes. Does using the fastest intervals contribute to clients seeing the same on their screens, bcs info gets updated faster? If yes, then it would be another advantage of using the fastest intervals. (EDIT: I’m replying to some of the notes which violet posted here recently: - Yes we played rounds with /pxiclient >0, up to 70ms, which were found by at least one of the players to be more laggy than lower client-intervals - We also tried out different /pxiserver numbers up to 70ms. - Regarding high ping: Other than Empive, i have played one round with like 350ms using vpn connecting me to USA. Apart from a few airs, it seemed just fine. we used /pxiserver 0 and /pxiclient 0 in that round. Regarding bulletreporters: Lagbouncing is a real problem in multiplayer jj2. Sometimes players lagbounce alot in a round, unintentionally cheating death as if they have extra health. This ofc leads to lots of frustration on the opponent’s side. The use of /bulletvictim seemed to solve the problem of lagbouncing and oneself going through ammo on one’s own screen completely. Thus, the COMBINED use of /bulletvictim AND /bulletserver improved the gameplay BIG TIME by fixing these problems. Furthermore, the videos of everyone who recorded so far show that this fix comes with no visible downsides compared to playing with hits being only serverside (except for plenty of bugs. more on that later). A few recorded rounds seemed to be free of ANY kind of relevant „lag“, such as airs, people-going-through-bullets or lagbouncing. That’s how JJ2 should be optimally. However, currently /bulletvictim comes with many bugs in most rounds. Even if it was possible to fix the relevant bugs, I‘m told it’s uncertain to what extend it can be abused to cheat, if getting hit is made partially client-side. Myb there are two scenarios to consider: A) IF a cheater can only use it to prevent getting hit in the few times when the server doesn’t notice it, then it wouldn’t be much of a problem. At least for the overall gameplay it would still be the lesser evil compared to what we have now, where probably most (not just one of them) players lagbounce multiple times every or nearly every round. Why is it the lesser evil? Because LAGBOUNCING is exactly this same kind of "cheating"! It's cheating death/"getting hit" as if u have extra health. The only difference is that it's unintentional and we can't control it ourselves. It makes no sense to reject /bulletvictim from the start just bcs someone could theoretically use it to intentionally cheat "getting hit" a few times, because RIGHT NOW people ALREADY DO cheat "getting hit" multiple times a round by LAGBOUNCING unintentionallyt! /bulletvictim can end that "unintentional cheating". So we can choose between... A) people cheating "getting hit" unintentionally FOR SURE... and B) someone PERHAPS cheating "getting hit" intentionally in the future. But we don't know if this will ever come true. The unintentional cheating is already reality. The intentional one is not and perhaps might never even come true. Furthermore, if all players would lagbounce equally as often in a round, one could at least say the unintentional cheating is somewhat fair. But they don't. Players can lagbounce more often than their opponent in a round, thus giving them an unfair advantage - just how it would be if someone would abuse /bulletvictim to cheat "getting hit". Again, the only difference between the two scenarios is "unintentional" vs "intentional". B) But it would be more problematic, if it could be abused to cheat in more extreme/impactful ways than only hit prevention when the server doesn’t notice the hit. However even if it turns out to be true and we’d be steering into a bad future cheatingwise, couldn’t we simply end it again by reverting back to ONLY server-side hits like we have now? If yes, then myb it could still be worth a try to fix the bugs of /bulletvictim and make it more playable. Because lagbouncing is a real existing problem in the present. Whereas cheating from /bulletvictim is just a theoretical future possibility. Perhaps we’d get lucky and nobody would ever care to go through the effort of finding a way to cheat with it that would be worse than the current unintentional death-cheating multiple times a round via lagbouncing, and we could simply enjoy lagbounce-free JJ2. After all, the active online community is very small and I don’t think we will ever get like 20 new dedicated players again, where many future-cheaters could be among them. Based on the points i’ve made just now, i think it’s unlikely (but possible) that we’d steer into a bad future cheating-wise with /bulletvictim. Eventho this risk exists, i think it’s probability is too low to cancle further development of /bulletvictim right away, bcs the possible benefits of /bulletvictim might be far greater, perhaps. Imo the chance of gameplay benefit is bigger than the risk for the gameplay, here. Ideally it would be better if lagbouncing could be fixed in a good way without the cheatable /bulletvictim setting. But until there is a better method to fix lagbouncing, it seems we can't choose between a good option and a bad option, but only between two bad options. and /bulletvictim might be the lesser evil choose from (thus being the right way to go), bcs now players also "cheat" deaths/hits multiple times a round by lagbouncing. I don't see why the same kind of cheating death/hits multiple times a round is much less bad when it's unintentional, compared to intentional. But again, all this assumes the bugs can be fixed in the first place, which requires further coding and lots of retesting and analysing. And from what i see, this won’t happen so fast for now. I want to highlight again that when i talk about using /bulletvictim i always mean using it in combination with /bulletserver, so that "getting hit" is never fully client-side but only partially. I conclude that currently with all these bugs, bulletreporters should definitely not be included in the next official JJ2+ release. Here are the video recordings of SJ: https://www.youtube.com/watch?v=qvHMEUwdM3g https://www.youtube.com/watch?v=Pxv6B5qBb7s https://www.youtube.com/watch?v=ACrk3wEN4E4 Here are the video recorings of MS: https://www.youtube.com/watch?v=BaJk7v61RpA https://www.youtube.com/watch?v=1mn4kwgMXeA https://www.youtube.com/watch?v=CEQ1YYof4DA https://www.youtube.com/watch?v=k7MiAL18Nok https://www.youtube.com/watch?v=SJO5bIRTxOA https://www.youtube.com/watch?v=ZqB6QxwW3wo https://www.youtube.com/watch?v=H984KxKMiEI https://www.youtube.com/watch?v=9yV4_8t5mSw Here are a few of my own recordings: https://www.youtube.com/watch?v=tGj5d9Lv0oU https://www.youtube.com/watch?v=Wk6-ENuy5wQ And here u will find the majority of my own recordings, which are ALOT more: https://www.youtube.com/@jazzjackrab...ayer832/videos For now, i’d be glad if we get to see a new official JJ2+ in the near future, which has the interval issue included. Currently there are three different JJ2 versions running in the dedicated online servers. I hope this new offical JJ2+ version can end the split so we all go back to playing only 1 jj2 version. I’d like to report a strange moment which was caught on camera during the testing, in case it is found to be a bug: https://imgur.com/7pxBu30 In the scene MS gets hit and then hits Equinox with toaster around the time when MS starts to blink. One person had following thoughts on this scene: „What seems to happen is possibly MS holding the fire button at all times resulting in an immediate creation of an ‘instance’ of toaster that COINCIDED the very moment of blinking start-off. That subsequently was treated by mutualinjury as a bullet fired pre-blinking so it had the ability to hurt briefly. I also believe desync due to ping had a role in this. at any rate, it’s one of those extremely rare cases that, to my mind, shouldn’t be given a great deal of thought.“ Last edited by t3Kev; Jun 7, 2023 at 09:58 AM. |
Jun 6, 2023, 01:37 PM | |
Just posting my opinion quickly too, as I've only played a around 8 rounds with these settings.
/pxiserver 0 and /pxiclient 0 seems to be very nice, and I finally don't feel like I get hit from seeks when they are still pretty far from me. We tried the settings with pretty high values too (Iforgot the exact values, the match was on scrapyard with sj and kev I think - in case it was recorded), and that way the game certainly felt like when you have 300-500 or so ms ping. There was an instance of kevin not dying on elm super (dying but respawning instantly on the same spot*), it was recorded too. Good job, I like the update! |
Aug 20, 2023, 09:53 AM | |
The JJ2+ team would like to offer our thanks to all those who gave so much of their time to participate in this public test! The lower pxi code has been incorporated into version 5.12, out now. At this time we are not planning on moving forwards with the /bulletvictim command, because there are still far too many unknowns surrounding it.
|
«
Previous Thread
|
Next Thread
»
Thread Tools | |
|
|
All times are GMT -8. The time now is 03:38 PM.
Jazz2Online © 1999-INFINITY (Site Credits). Jazz Jackrabbit, Jazz Jackrabbit 2, Jazz Jackrabbit Advance and all related trademarks and media are ™ and © Epic Games. Lori Jackrabbit is © Dean Dodrill. J2O development powered by Loops of Fury and Chemical Beats. Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Original site design by Ovi Demetrian. DrJones is the puppet master. Eat your lima beans, Johnny.