Recent Posts

Pages: [1] 2 3 4 ... 10
1
Quote
Changed pause timing. r3 broke single player pause fps.
Pause timing illogical... Comments missing lol.
Quote
Reverted to NWC_STEP every sync_step. With it every 4, it was far to likely for the client to actually encounter it. I don't see bandwidth as really a concern; If a server can't keep up this stream, it'd never transfer the save in a reasonable time anyway...
Except you complained it was too much per second hence I added it...

One can counteract running into the sync step wall by adding a client frame behind, or at least that is my theory. One could set the server to 1 or 2 frames behind with the client an extra 2 or 3 frames behind and it would drastically reduce bandwidth requirements.
Quote
Removed apparent stow away addition:
Timing is a real mess if that is not needed... Since the function adjusts timing in response to some packets it seemed only logical to set it to a reasonable default value on disconnect.
2
Attached is my suggested version of the patch.

Only gross timing adjustments on NWC_STEP. Both gross and fine fom NWC_CHECK.
Changed pause timing. r3 broke single player pause fps.
Reverted to NWC_STEP every sync_step. With it every 4, it was far to likely for the client to actually encounter it. I don't see bandwidth as really a concern; If a server can't keep up this stream, it'd never transfer the save in a reasonable time anyway...
Renamed step to server_sync_step in "pull out server sync step" since step != sync_step.
Removed apparent stow away addition:
Code: [Select]
if(  nwc==NULL  &&  !network_check_server_connection()  ) {
  dbg->warning("karte_t::process_network_commands", "lost connection to server");
+ *ms_difference = 0;
+ next_step_time = ms + fix_ratio_frame_time;
  network_disconnect();
  return;
and stuck in my suggested revision to default timing settings. Behaves so much better with things integral to frames_per_step, and with the extra 4 frames of margin.
3
The tick packets are used to define the maximum frame clients can go to. They are used for timing much like the check packets currently are but they are simpler and more regular.

Also they are not per frame anymore, client_frames_ahead now controls how often they are sent as it shares functionality overlap to some extent. This solves potential bandwidth problems.
4
I tested by pausing a server with debugger attached and checked if the clients stopped. I then resumed the server from the debugger and all clients went back to normal and remained in sync.
When you pause a server, it's knows it's behind and send the check packets which get the clients going. Manipulating the networks flows is a much better test. On windows play with 'clumsy' for a simple tool.

With r2, I can get it into an unstable hiccupy state just with some delay jitter.
You stealth edit adding r3 wasn't seen so will need to try with it.

tick packets for timing sounds bad - you don't want timing adjustment per frame.
Server frames ahead can never be zero, that would mean the server expects the client to be executing the command this tick. Still haven't looked at r3 though...

Nagle on actually improved the stability! (just for some corner cases though, still better when off for those with quality connections)
5
Bug Reports / Re: Bug in Just_in_Time=2 ?
« Last post by TurfIt on Today at 02:24:16 AM »
The attached patch above should still be valid. I don't like stepping on others section of code, so didn't commit...
6
This is not part of standard. In Extended it pushes elements of the convoy to the far top of the component selection list in the order they were selected. In standard it just shows/hides elements as appropriate and does not put elements of the current convoy at the top of the convoy component selection list.
7
Bug Reports / Re: Bug in Just_in_Time=2 ?
« Last post by DrSuperGood on Today at 02:19:32 AM »
I will look into this soon. I think I might know the cause as I did not consider farm production changes when caching state. In retrospect I think caching state was maybe a bad idea...

In server tests no one noticed this because the game is save/load cycled every time someone joins, which is quite frequently. The cache state is rebuilt on load, so gets corrected.
8
The reason goods are not profitable to transport is because 1 vegetable farm only makes 1 unit every 4 or 5 months. Convoys sit idle most of the time.
9
The idea of different qualities of accommodation and handling are interesting, but are likely exponentially to increase the complexity of implementing this. It is also likely to be very difficult to get accurate data on the significance of cooling - just how much longer can milk be transported in a modern refrigerated lorry than it could be transported in milk churns in an ordinary box wagon in a railway train? What of UHT milk (and at what stage does it become UHT milk)? Does refrigeration have more of an effect for fish and/or meat than milk? What about vegetables? What about frozen meat - would that be transportable with an indefinite time? As to stock losses, would the player just receive slightly less revenue based on the amount actually delivered, or would the player have to pay compensation? If so, that would have to be calibrated to the actual value of the stock lost, which would be a whole other set of research to do and pakset data to implement.
10
Splendid, thank you for confirming. Can anyone upload a saved game in which this can reliably be reproduced to assist Ves in his debugging of this? It would be very helpful.
Pages: [1] 2 3 4 ... 10