Stats at https://piranmoto.uk/events/196
Last edited by Racon, .
Loss of InSim connection when skipping forward replay with MCI packets enabled
When skipping forward in a replay by clicking the timeline slider at the bottom of the screen, any connected InSims that receive MCI packets will lose connection.
Tiny jumps are unaffected, but even 5 seconds with 19 cars on track and an update interval of 100ms will trigger the disconnection. (~100 MCI packets?)
I'm guessing it's an outgoing InSim buffer overflowing, but I can't see an option to increase it in the client or cfg.txt.
I have tried to work around this by monitoring RIP and STA, but RIP does not fire when using the timeline slider thingy, and disconnect happens before the STA showing the change of ISS_PAUSED.
Attached image is my running the same basic program (print any STA/RIP) twice, both connected to the same client which is paused at the start of the replay. The left window is MCI off, the right is with MCI set to 100ms interval.
The first STA (from startup) you see in both windows, then the slider is clicked: the left window shows ISS_PAUSED is removed from Flags while the replay moves and is re-added afterwards, but the right window loses the connection before receiving the new STA.
--
Side note: This has also happened to me when joining a busy server with lots of new mods to be downloaded by the client - there is a time when the environment is loaded and showing, but players are still loading. You can see them on the minimap, but not in the environment, and there is often a sound loop at the same time. After a while it all catches up, but MCI-based InSims will have lost connection while non-MCI InSims won't.
I know this is my join causing me an effective pit-out for all players at once, and that the newer version has much better pit-out performance - I'm just mentioning this one in case it helps shed light on the other, it looks like it could be the same cause.
Tiny jumps are unaffected, but even 5 seconds with 19 cars on track and an update interval of 100ms will trigger the disconnection. (~100 MCI packets?)
I'm guessing it's an outgoing InSim buffer overflowing, but I can't see an option to increase it in the client or cfg.txt.
I have tried to work around this by monitoring RIP and STA, but RIP does not fire when using the timeline slider thingy, and disconnect happens before the STA showing the change of ISS_PAUSED.
Attached image is my running the same basic program (print any STA/RIP) twice, both connected to the same client which is paused at the start of the replay. The left window is MCI off, the right is with MCI set to 100ms interval.
The first STA (from startup) you see in both windows, then the slider is clicked: the left window shows ISS_PAUSED is removed from Flags while the replay moves and is re-added afterwards, but the right window loses the connection before receiving the new STA.
--
Side note: This has also happened to me when joining a busy server with lots of new mods to be downloaded by the client - there is a time when the environment is loaded and showing, but players are still loading. You can see them on the minimap, but not in the environment, and there is often a sound loop at the same time. After a while it all catches up, but MCI-based InSims will have lost connection while non-MCI InSims won't.
I know this is my join causing me an effective pit-out for all players at once, and that the newer version has much better pit-out performance - I'm just mentioning this one in case it helps shed light on the other, it looks like it could be the same cause.
If you're not a fan of OAuth you can have people specify their LFS username when they sign up on the site, give them a token, and then have an insim command to use the token to activate the account if the username matches.
Great idea, I look forward to tinkering with it 
Sorry, I have so many LFS things to do and very little LFS time at the moment... this one got lost in the shuffle. I will bump it back up the list, but no promises as to when I'll get to it.
Quick answer to all those questions is: Download it and put it anywhere you like, it doesn't need to be in a certain place. The image should be PNG format, in the same place. It's a commandline app, so it needs to be run from a DOS window (see usage above), and it saves the layout in the same directory too.
Quick answer to all those questions is: Download it and put it anywhere you like, it doesn't need to be in a certain place. The image should be PNG format, in the same place. It's a commandline app, so it needs to be run from a DOS window (see usage above), and it saves the layout in the same directory too.
Stats at https://piranmoto.uk/events/194
Last edited by Racon, .
Thank you, the server restart fixed it.
In combating/logging this, have you changed anything to do with users timing out from a server?
I'm always connected and have to rejoin after a lost connection every now and then, but today the server doesn't seem to notice that I've timed out.
I've had 'User name is already online' for at least half-an-hour now, usually it takes under a minute for the server to notice I've gone and let me back in again.
(It's not a hack - I'm showing as spectating on the same server, as I was when the connection was lost)
Edit: It's on my server, so I could kick myself from the control panel I think. I don't need to be logged in just yet, so I'll leave that until later in case there's some value in you looking at a live example of a stuck player
I'm always connected and have to rejoin after a lost connection every now and then, but today the server doesn't seem to notice that I've timed out.
I've had 'User name is already online' for at least half-an-hour now, usually it takes under a minute for the server to notice I've gone and let me back in again.
(It's not a hack - I'm showing as spectating on the same server, as I was when the connection was lost)
Edit: It's on my server, so I could kick myself from the control panel I think. I don't need to be logged in just yet, so I'll leave that until later in case there's some value in you looking at a live example of a stuck player
Last edited by Racon, .
Stats at https://piranmoto.uk/events/193
Last edited by Racon, .
Stats at https://piranmoto.uk/events/192
Last edited by Racon, .
Stats at https://piranmoto.uk/events/191
Last edited by Racon, .
That's not something PIE could do even if it wanted to! It uses PHP's built-in socket functions to communicate over the internet, but it doesn't have any more power than that over your connection.
What is DD? The Destruction Derby Doctrine
What is DD? The Destruction Derby Doctrine:
DD racing is not no-rules racing, there are limits to
acceptable contact. You can rub, bump, barge, lean on, crash,
bash, spin, pit and poke, but only with people you are racing
directly (on the same lap).
You cannot fight or obstruct people who are lapping you, but
they may fight you. You cannot divebomb into T1. You cannot
drive the wrong way except where a track forces you too. If
the track has a two-way section, you may play chicken with
other drivers, but you may not try to hit them deliberately.
You cannot stop or loiter in an interfering position, you
cannot behave in an annoying or toxic manner.
You may fight, revenge attack, and may hold a grudge for as
long as you like, but keep it friendly and within these rules.
The rules are there to set a hard limit on what is acceptable,
but the etiquette (soft limit) is up to the drivers on track
to regulate through retaliation.
Being aggressive is not against the rules; Attacking without
provocation is not against the rules; Attacking repeatedly is
not against the rules; Attacking at full strength is not
against the rules; Charging blindly through a crowd is not
against the rules; Driving impatiently is not against the
rules.
These things are regulated by etiquette by the drivers, not
rules by the admins.
DD racing is not clean racing, but it can be. The overall
level of 'fightyness' waxes and wanes with the drivers
present: Sometimes it's close to the rules limit, sometimes
it's no different from a clean race, and usually it is both
of those things at once, depending on who you're driving
near to.
It's a driver's own responsibility to defend themselves from
attack, and it is a free choice to forgo defence in pursuit
of position.
It's common to start the fighting gently and escalate as
appropriate, but it isn't mandatory to do so. It would seem
obvious for new drivers to read rules and start gently, but
it is to be expected that they transgress and require
correction. It is a driver's free choice to forgo caution
when dealing with a new driver.
It is common for a driver to get more attacks back than they
give out. It is a driver's choice to accept this 'interest'
or to continue escalation.
It is common for a driver to receive attacks that are part of
a charge, or otherwise untargetted. It is a driver's choice
how much they are prepared to accept as collateral damage to
another driver's charge.
It's common to save the bigger and/or cheaper moves for
someone who's not getting the message from smaller ones, but
that's not mandatory.
There is no right of way on a crossover, it is a driver's
choice to wait or not. There is no right of way on a merge,
it is up to the driver to choose between speed and safety.
There is no right of way or mandatory side of the road in a
chicken-run section of track (two-way traffic), it is a
driver's choice to yield or not. Side-of-road is often chosen
to minimise crossings, but it is not mandatory to do so. It
is not mandatory to choose the same side as other drivers.
There is no requirement for drivers to avoid or wait for cars
recovering from fights or errors. It is the inconvenienced
driver's right to minimise their loss.
It is the nature of DD to not know what to expect from many
of your track neighbours, to have to balance safety against
speed or position, to have to take risks, to be caught up in
other people's fights, and for it to be possible to end at
any moment through no fault of your own.
You can be safer by following and enforcing etiquette, but
you can never be safe. It is always the driver's choice to be
trusting of another driver. It is always the driver's choice
to forgo safety in pursuit of speed or position.
DD racing is not no-rules racing, there are limits to
acceptable contact. You can rub, bump, barge, lean on, crash,
bash, spin, pit and poke, but only with people you are racing
directly (on the same lap).
You cannot fight or obstruct people who are lapping you, but
they may fight you. You cannot divebomb into T1. You cannot
drive the wrong way except where a track forces you too. If
the track has a two-way section, you may play chicken with
other drivers, but you may not try to hit them deliberately.
You cannot stop or loiter in an interfering position, you
cannot behave in an annoying or toxic manner.
You may fight, revenge attack, and may hold a grudge for as
long as you like, but keep it friendly and within these rules.
The rules are there to set a hard limit on what is acceptable,
but the etiquette (soft limit) is up to the drivers on track
to regulate through retaliation.
Being aggressive is not against the rules; Attacking without
provocation is not against the rules; Attacking repeatedly is
not against the rules; Attacking at full strength is not
against the rules; Charging blindly through a crowd is not
against the rules; Driving impatiently is not against the
rules.
These things are regulated by etiquette by the drivers, not
rules by the admins.
DD racing is not clean racing, but it can be. The overall
level of 'fightyness' waxes and wanes with the drivers
present: Sometimes it's close to the rules limit, sometimes
it's no different from a clean race, and usually it is both
of those things at once, depending on who you're driving
near to.
It's a driver's own responsibility to defend themselves from
attack, and it is a free choice to forgo defence in pursuit
of position.
It's common to start the fighting gently and escalate as
appropriate, but it isn't mandatory to do so. It would seem
obvious for new drivers to read rules and start gently, but
it is to be expected that they transgress and require
correction. It is a driver's free choice to forgo caution
when dealing with a new driver.
It is common for a driver to get more attacks back than they
give out. It is a driver's choice to accept this 'interest'
or to continue escalation.
It is common for a driver to receive attacks that are part of
a charge, or otherwise untargetted. It is a driver's choice
how much they are prepared to accept as collateral damage to
another driver's charge.
It's common to save the bigger and/or cheaper moves for
someone who's not getting the message from smaller ones, but
that's not mandatory.
There is no right of way on a crossover, it is a driver's
choice to wait or not. There is no right of way on a merge,
it is up to the driver to choose between speed and safety.
There is no right of way or mandatory side of the road in a
chicken-run section of track (two-way traffic), it is a
driver's choice to yield or not. Side-of-road is often chosen
to minimise crossings, but it is not mandatory to do so. It
is not mandatory to choose the same side as other drivers.
There is no requirement for drivers to avoid or wait for cars
recovering from fights or errors. It is the inconvenienced
driver's right to minimise their loss.
It is the nature of DD to not know what to expect from many
of your track neighbours, to have to balance safety against
speed or position, to have to take risks, to be caught up in
other people's fights, and for it to be possible to end at
any moment through no fault of your own.
You can be safer by following and enforcing etiquette, but
you can never be safe. It is always the driver's choice to be
trusting of another driver. It is always the driver's choice
to forgo safety in pursuit of speed or position.
Thanks for the testing 
You can't adjust the button transparency in InSim I'm afraid, but maybe the lighter colour would be better. (Replace ISB_DARK with ISB_LIGHT)
Note to me: Adam suggested in discord the option for adding usernames above the dots.
You can't adjust the button transparency in InSim I'm afraid, but maybe the lighter colour would be better. (Replace ISB_DARK with ISB_LIGHT)
Note to me: Adam suggested in discord the option for adding usernames above the dots.
Stats at https://piranmoto.uk/events/190
Last edited by Racon, .
PIE and Lapper are different things, they're not compatible.
This script is only for the local user, not a server. (It could be modified to connect to a server and draw this for everyone connected, but that's not what this one does)
Thanks for helping explain things above.
If it doesn't connect at all, it might be that you have a password set for local InSim, you can check in the 'start host' section.
Your PHP installation isn't used for running PIE, so it's not a version thing. And I get my error messages in english, so my compiler is full of surprises
There is an update coming for PIE soon that can catch a disconnection more cleanly, and I'm still looking at a better way to detect when it's safe to start spamming buttons... but currently I'm receiving the packets that have to be drawn, I think, before it's safe to start. It's not every server, just when you have a lot of new mods to download in one place.
Definitely a WIP script, this one
Yep.
Quick recap for anyone who needs it: drop this script into a folder containing pie.exe, then from the commandline (or a batch file) run it with:
Default port is 29999, more detailed instructions in the main PIE post
Quick recap for anyone who needs it: drop this script into a folder containing pie.exe, then from the commandline (or a batch file) run it with:
pie radar.phpDefault port is 29999, more detailed instructions in the main PIE post
No, it's a local one - just for the person running it like LFSLazy or AONIO, rather than like JAR's server-side radar.
FGED GREDG RDFGDR GSFDG