Recent Posts

Pages: 1 ... 7 8 9 [10]
91
Web & Wiki / Re: You have a question to Tikiwiki?
« Last post by Frank on Yesterday at 09:43:04 AM »
maketoc is for page navigation

for this exist a Quicktag ( line 3 in the middle 'toc from page', the left from 3 )
92
Patches & Projects / Re: Sort Vehicles in Depot Window
« Last post by DrSuperGood on Yesterday at 09:05:15 AM »
"Active date" sounds bad English I think. Something like "Available" sounds better.
93
Pak128.Britain-Ex / Re: [db357ad] Nightly Linux builds bloating
« Last post by DrSuperGood on Yesterday at 09:00:00 AM »
If one can place the files loosely on a server then one could develop some kind of auto update system. I believe that currently very few files are changing each night however one still needs to download everything.

The tool would work by first recording the SHA-1 (or SHA-256) hash of each file that makes up extended. This gets stored in a file on the server, which should be fairly small (<<1MB). The clients then run a tool which downloads the nightly build list from the server and compare it to its current list. Any files which have had their recorded hash changed are then downloaded individually and replace the existing file. Same applies to file additions and deletions. Once all such differences have been resolved it then finally updates the hash list itself. Technically the hash list is not required client side as it could be built from the current install but its cache like nature would speed up the update process considerably.

The potential bandwidth savings might be quite significant and add up to many GBs every week.
94
Larger Projects / Re: One-way Two-lane road Fun Patch
« Last post by THLeaderH on Yesterday at 07:10:49 AM »
Today I followed the commit of the master brunch and the binary for windows is available.
The repository is r8346 based now.
https://drive.google.com/open?id=15L3AY3wZ_bZuczHZQbRrBPXT2l_4S59E

To understand how to use this patch, please see this post.
95
Pak128.Britain-Ex / Re: [db357ad] Nightly Linux builds bloating
« Last post by Spenk009 on Yesterday at 06:54:07 AM »
I understand entirely. There are bigger tasks on hand at the moment and you're fully involved in the whole mail & pax classes code. This affects very few users, while the other issues affect all users.
96
Patches & Projects / Re: Sort Vehicles in Depot Window
« Last post by HyperSim on Yesterday at 06:44:25 AM »
I committed the patch in r8344. Please feel free to work on design changes. I will happily submit more patches to modify the layout.

Thank you for integration!
Here's an update patch to modify the layout I posted before. (I attach the image again.)

I think reducing lines for vehicle information is needed because there's too many line for the info.
I united "Power:" and "Gear:" lines and "Intro. date:" and "Retire date:" lines. (So, I reduced 1 line.)
I want to know what do you think about it.
97
Quote
It's highly probable that once a client hits the safety net, they will get one frame behind before advancing into the net again. i.e. never recovers. Again, next_step_time is not being properly handled.
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.

Edit:
Attached is an update version addressing some of above. I hope to commit it tomorrow sometime.

I slightly changed to functionality of server_frames_ahead so it now controls how often tick packets are generated by the server. A value of 0 means every sync step frame, a value of 1 every second frame, 2 every third etc. This seemed a reasonable idea to do as ultimately the tick rate determines latency so ties exactly in with the functionality of server_frames_ahead. This solves the problem with Nagle as setting the value sufficiently high will prevent it from delaying excessively.

Check packets are also used for timing and the server will never generate a tick packet on the same frame. Slightly saves on bandwidth.

Tick packets are used for timing as well now. Should make frame rates more stable.

Added some arbitrary delay when paused. This might or might not be the right thing to do but it appears to not have broken anything except made pause mode slightly lower frame rate.
98
Well it cannot be any worse than currently where the client would be prone to disconnect with it on due to arbitrary packet delay.
no. Current pps is low enough for inter packet timing to be beyond time outs. You actually end up with a steady stream. This patch puts things right into the problem zone.


It uses same delay as when paused I thought? If this is a problem then it is also a problem with pause.
No. There's no problem with pause. There is a problem with this patch. next_step_time....


Not really a problem and I am sure few players will care. They mostly want to remain connected instead of going out of sync and having to reconnect repeatedly. Any flaws here existed with the old algorithm except now an extra safety net stops the client from advancing more than is safe to do so.
It's highly probable that once a client hits the safety net, they will get one frame behind before advancing into the net again. i.e. never recovers. Again, next_step_time is not being properly handled.
Simutrans timing is rather complex (overly so IMHO), the control variables all behave completely different depending on if  paused, fast forward, normal, network mode. And the control is performed in many unrelated places. You can't just stop updating the timing state as this patch does.

99
Simutrans Extended Discussion / Re: Small ships and range
« Last post by DrSuperGood on Yesterday at 02:49:24 AM »
I would suggest removing range tests for actually getting to a destination. They should only be checked when advancing stops on a line and throw the error if the next 2 stops are too far apart.

The logic behind this is that the ship can be thought of as implicitly stopping for supplies along the way. This would be for player convenience as they then do not have to worry about making a temporary route just to get a ship between places due to range restrictions.

A better implementation might even force the ship to implicitly stop at docks along the way and throw an error if there is no path made out of hops of the required distance. However this might be harder to implement.

Another solution would be to allow teleporting of depot content. Where you can move something from one depot to another, possibly at some fee or cost of time. This avoids the complexities of physical navigation entirely and can be used to solve problems such as convoys stuck inside lakes.

In both cases what should happen is that in a well built up map with no huge open oceans a ship from one side of it could be reassigned to a line on the other and it will automatically make its way there without the player needing to care about the range or route it takes.
100
Simutrans Extended Development / Command line server build issues
« Last post by DrSuperGood on Yesterday at 02:42:27 AM »
Quote
I have also noticed the posix issues with Windows builds of the command line server: the game will instantly quit when started, with no error message
It likely only effects Standard when building with MSVC. It seems MSVC POSIX link system does not support the windows only UTF-16 Unicode aware API, throwing link errors as the implementations cannot be found. This means my recent drive for Unicode awareness has broken the ability to build POSIX servers in MSVC.

When trying to build a simple windowless server from the other back ends apparently the graphics code tries to access mutexes it should not (no graphics so no mutexes) so causes a segmentation fault unless built single threaded. This might only apply to standard.
Pages: 1 ... 7 8 9 [10]