#UNLIMITED GAME
1 messages · Page 1 of 1 (latest)
Do you have the game id? It's the code in the address bar or browser history after join: openfront.io/join/xxx
Unfortunetly no
Ah unfortunately then it'll be hard to research
For the current investigation, can we still have your screenshot?
to reproduce the bug :
Make a game and attack with massively mirv like 20 minimum
maybe the spent hour is important because, as you can see the game was very long, 2h30
Thanks. The timer didn't stop right, as there was no win modal?
And the reproducing (20+ MIRVs in probably 1+ hour game) means you've seen it happen more than once?
i can corroborate that this doesnt happen 100% of the time, I think the MIRVs cause the server to desync due to packet lag.
thanks, that could be helpful to know
the timer didn't stop yes and no winner
i precise than it was on the .io and not the .dev
Reproduced in on .dev in single player (posting it here because it's another proof and files above 10MB are allowed on this server)
I'm doing research on the issue, it appears that whatever might be causing it is due to an EXTREME amount of updates per game tick. would anyone be able to find me a link referencing the code regarding how land is taken. if each pixel is an update sent to the server, then that MAY cause packet loss due to bottlenecking.
I would largely figure this isnt the case because it doesnt happen every time, and ive seen plenty of instances where land is being taken over extremely quickly with no server/client side issues
in the case of the game in #ðŸ’︱general it seems to've been another type of error. The win was registered but the things that need to happen after that didn't because of the error
gotcha so we are gonna nix that game from the evidence record?
id still like to keep note of it because it still provides key information to the underlying issue
that game had a lot of "expansionists"
its a good stress-test game
nothing is nixed hehe, and sure you're welcome to investigate it's open source
there's overall not too much traffic because the game runs client side mostly
not that i'm super in the know but that's the gist of it
im having @red bolt (who happily volunteered) on a profiler rn
maybe for use as one of your starting points. v22 branch is the current one on .io, the main branch is the one on .dev
main branch is already on v24 correct?
....
uh
thats a LOT of if statements...
just in the 300 lines of the typescript its basically just ifs.
v23 yes, or at least what's most likely going to be in it
this portion right here, im guessing its justified by eliminating attacking troops on the board?
therefore being a lag decrease?
im not entirely familiar with typescript im just using bare logical reasoning
but anyways thats just one avenue to trim the bottleneck
in pvp situations
hang on what am I doing what's happening
ive never seen this before
profiler investigation helps pinpoint causes of frame lag, can't really help with network issues
i know but what you are seeing is basically the object as it is, the network lag is a shadow of what you are seeing
essentially, stuff you point out there can help us here, so any information you have, whether it be relevant or not so long as you think its interesting to post here about the frame data, should be fine.
main information I have is that GameView.focusedPlayer() takes a wacky long time
anyways between the codebase not being documented and the branches being unclear idk what's going on here
Looks to me like that is whenever you click on someone via the leaderboard
when you what now
in openfront, you can click a name on the leaderboard and it brings your POV to their territory
oh well didn't know that was a feature
yep.
this being said it doesn't have an effect on their border color when I do that so what's the purpose here
i'm gonna go sleep, but will leave you with this https://github.com/openfrontio/OpenFrontIO/pull/696
and im guessing the other part is focused on the POV whenever you just start scrolling out
man imagine if we had documentation 
gotcha, thanks
would be nice to have more //
it can be interesting to see the diagram coderabbit makes, to see how everthing binds together. But also small things can do a lot with the performance indeed
k so hang on lemme analyze this
paintTerritory takes a tile and whether it's a border and determines what colour to make it correct
Im largely concerned if theres any feedback loops going on, and whenever the server recognizes a loop, it lags and reads the packet when it first entered
just a guess tho
my guess if this is all correct what im saying, then that would explain why MIRVing 20 times really quickly can cause packet loss
im not entirely sure if it has to happen at the same time the win state is supposed to occur and thats why people are seeing games not end, but if it happens at any percentage then its actually top priority to be fixed ASAP
- if it's a border but doesn't belong to anyone, nothing
- if it doesn't have an owner:
- if it's nuclear make it green
- else clear it
- if it has an owner:
... who cares point is the playerisfocused is only used to paint the border white if you're the active player
i was interested in the color side of things
you are seeing the same code so its a spectacle
i dont know if the border is causing the lag explicitly though
since it's that I'd first just move that function call directly to where it's being used as it can then skip the branch where it renders the defended borders (waait this doesn't make sense)
um
const lightTile = x%2 == y%2;
```is so much more legible lmao
i think its a cosmetic feature only and has no real effect on performance
the code is just a color mask only
also this doesn't actually appear to be in the game? hang on lemem check the live page code
no its the instance for defense posts, they turn the border to grey
yeah but this code I'm reading implies it should make a checkerboard pattern
does ? randomize it
because that could cause a gradient
nevermind that was a bad question i dont think it does
? is just an if statement for variables
ah
x = booleanVariableThatUsesAifTrueElseB ? a : b
this dictates the color distribution along the border no?
this code doesn't even match what's on teh actual page anyways so doesn't matter lmao
shoutout to git blame for showing me a little bit of what the intention behind things is
mm right so
its moving semi slow, pilkey is prolly gonna see all this tho
- every rendered territory tile game checks to see if it's the focused player
- focused player due to unimplemented logic just returns the active player
- since this is a replay, the active player isn't on the board
- the logic to return the active player, if unset, tries to set it by finding it based on the client ID
- this step creates a list of everyone on the board, searches through it to find a matching client, and returns it (or null if not found)
- since the active player isn't here, the value remains unset for the next loop
- focused player due to unimplemented logic just returns the active player
tl;dr: every paintTerritory call for a border cell when viewing a replay, the game tries to find the active player by scanning through an array of all players on the map. Every border pixel.
proposed solution: just have myPlayer immediately return null when viewing replays if this is something that can be implemented
simple if statement
also should work with whatever focus highlight features are wanted from that todo
@mellow jasper thoughts?
Idk i gtg rn will look at it later
thats crazy ðŸ˜
It's probably fixed by this commit: #🔗︱github message
I believe its a partial fix, we still have to tackle land grabbing updates causing desyncs as well
yeah please report if you still encounter it, this is for sure the reason at least some games didn't get a win modal but maybe not for all
agreed. grabbing a lot of structures really quick might exacerbate it as well
since each structure is flipping ownership when land is grabbed at a really quick pace, I.E. Island Outposts/ SAM islands
i do think there should be a soft limit per structure in a given pixel
there already is. First you could stack exactly on top of other buildings, then that was made impossible, then after a lot of complaints and a poll it was made partly possible again but there's always a few pixels between them