Recent Posts

Pages: [1] 2 3 4 ... 10
1
I think looking into a better factory economic model would solve the problem. In real life transport companies charge whatever people are willing to pay. If you set up a very low efficiency route it might be too expensive for the supplier and consumer to use. If you set up a low efficiency route then the product might become too expensive for the consumer reducing rate of sales (demand per month). A high efficiency route would have the opposite effect encouraging demand.

Factory routes would be mostly weighted on price. A factory does not care if coal takes 3 years to arrive to it as long as it is extremely cheap to do so. For players competing with each other it would become all about shifting goods as cheaply from one place to another.

Goods which are meant to have a limited shelf time would be mechanically implemented by "spoilage" based on the travel time. These apply to the factory and effectively mean that some of the product is lost upon arrival based on the calculated travel time (not actual travel time, so that convoy getting stuck for a while will not have high spoilage when it arrives but it might raise average spoilage due to raised calculated travel time). Using the above economic model this has the result of making the value of 1 unit more expensive to obtain for the factory as more than 1 unit must be ordered for 1 unit to arrive. This is then used when checking route viability allowing it to trade off travel time against cost in a way that makes sense. For example a factory that process fresh milk might prefer to use a very expensive but fast route with 0 spoilage over a very cheap but slow route with >50% spoilage due to the cost of the underlying milk. Ultimately there would be a time at which there is 100% spoilage, in which case the route is determined unviable anyway according to the above logic hence also limiting the maximum range one can move such goods.

Another part of this would be a knock-on effect in the case of factory chains. For example one might deliver hardware from a factory to a hardware shop very economically however the hardware still sells very badly because the coal and iron ore being delivered to the factory costs a fortune so the hardware it produces is already very expensive.
2
Since your version had a lot more testing/fine tuning I committed it.

It might be a good idea to do a release later this month as there have been a ton of features/changes made since the last one.
3
Bug Reports / Re: Bug in Just_in_Time=2 ?
« Last post by DrSuperGood on Today at 08:31:17 AM »
I have hopefully commited a fix for this.

The factory code is really messy. One day I am going to have to go through it all yet a gain to clean it up and hopefully stop bugs like this from happening.
4
I like the idea proposed by james, that the class of cunsumers will determine the demand for goods that travelled in higher class vehicles. But I think it should not be a simple maximum, but a weighted average. A coal or wood that was carried by horses for a short trip from the mine/forest to the harbor, then a long cheap trip by boat, and then again short trip by horse pulled cart, should not be much more expensive than stuff carried only on boat.

I like the cooling quality idea to allow for longer trips. A cooling car would have a multiplier how much longer any goods will last in it, and goods would have a maximum that is feasible. eg. Meat could have an unlimited lifetime if refrigerated, but fruit could be only cooled to get only double lifetime. And no increase in lifetime for newspapers at all. But this feature could be added later together with increasing the default class for vehicles with better cooling.

Spoiling goods due to bad handling is probably too much. Just like we don't simulate disasters.

For power consumption. All city houses have a proportion of how many passengers of each class they produce. That will be used for determining how much are they willing to pay for electricity. The city transformer station will show this. And if it is connected to a power plant making only expensive electricity, it will require less power. If there are more sources in the network with different prices the cheapest ones will be used first.



5
Pause timing illogical... Comments missing lol.
FTFY. All the timing spread out all over the place and mixing up frame timing with step timing is headache inducing.
Although pause is even worse. My patch to fix the fps limit is stalled trying to get pause to hit the target better.


Except you complained it was too much per second hence I added it...
Did I? Though I just pointed out what it was....


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.
1 or 2 + 2 or 3 is not enough. Even on LAN things would jump around too much, never mind trans-Atlantic hops.
Also, things work much better when integrals of the step frequency since stepping takes so much longer than sync_stepping normally when in network mode. Extended completely dies because of it's extra work - runs several frames super fast, pause, 5 super fast, pause, ... terrible smoothness.


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.
Does no harm, just looked like a stowaway. Not really needed IMO since it's a one time event here - disconnect.
6
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.
7
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.
8
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.
9
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)
10
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...
Pages: [1] 2 3 4 ... 10