Chill's patchpack v14_7

[dkarn]

Sounds like an issue for http://bugs.openttd.org/ . I would not know where to start searching to solve this issue other then increasing the time before kicking clients.
Could you post the savegame and the server's config file there please.

Network code is indeed not very easy to understand.
Maybe someone that understands how the network code works can reproduce and find a solution ...

Edit:
By posting savegame I mean the one from clean trunk. If you post the one from the patchpack they will not be very happy me thinks ...

If saving the savegame on the server takes more than 10 seconds I would rather blame the server for being way too slow for serving that game. If the server is fast enough, then it's even worse because then the clients can't even autosave without being kicked for being too slow.

Thanks for help.
I currently test a patch to solve this, you can find it FS#4284 - Lag during Load and Save Multiplayer Game

[XaTriX]

We've some desynchros, i think it caused by cargodistribution..
We use Dkarn's version (Chillicore's PP + CD + Dkarn patch + openttd's dev patch on FS#4284 thread)

I'll test with another settings for frame_freq & sync_freq

XaT

[ChillCore]

If saving the savegame on the server takes more than 10 seconds I would rather blame the server for being way too slow for serving that game. If the server is fast enough, then it's even worse because then the clients can't even autosave without being kicked for being too slow.

Clients can be kicked for the server being too fast?
I always assumed that the server had to be the fastest machine.
By going by your reply the server should be the middle one? (in terms of processing power)
As I mentioned before, my online experience is zero.

Hi Guys, Not a bug, just looking for some advice on speedups.
...
What are some changes I can make to see things improve in speed?

I had a quick looksie at your savegame.
- You have a very big map.
- You have about 800 trains and 200 trucks. That is about where the coopsavegames stop because of the game slowing down too much IIRC.
- I have not checked your ships but if bouys are to far apart or non-existant they will have a negative impact on pathfinding
- You have signals on every tile, IIRC that will also have a negative impact on pathfinding. The coopguys can tell you more on the subject than I can.

As for speeding up your game:
- Try enabling the "forbid 90 degrees turns" for trains so that the pathfinder does not consider these paths and does not have to calculate if that route is shorter or not.
- Disable all details and animation.
- Disable vehicle effects. Every puff of smoke, spark and steam plume is a vehicle for as far as the code is concerned.
- Try a different blitter.
- Do a forum search on the subject as it has been dicussed many times before and more useful answers may be found.

As for disabling AIs completely: Just leave the setting at zero and no AI will start.

What patch are you talking about exactly?
The one in the first post or the different "true_daylength_patch" near the end of the thread?
The one near the end of the thread does not seem to have such a setting ...

I didn't know it had changed, i would guess the one with the most features if possible.
Either way, as long as one can select the income multiplier i am all happy.

Yes the new version has changed. Read the last few pages in the thread to know why.
I will have a looksie at he patch in the first post to see what code is multiplied/devided there that I have not yet modified.
I am all having the values calculated correctly according to the daylenght factor but for having a seperate setting ... there are grfs outhere that can/should be used for that. (As you kow since you are already using them.)

I meant a big map to be sent back and forth between clients in a multiplayer game.

Oh, that stuff
Well, i rarely have those issues with a 100MBit line and Quad core, 4 GB, 260 GTX machine.

Was it OpenTTD complaining or your OS? It has been a while I have tried generating such big maps ...

I don't recall what it said. It just complained about out of memory with a MsgBox style error. And then a crash dump.

If it was OpenTTD there might be a hardcoded limit somewhere. If it was your OS then there is little I can do about it.

Pretty sure it wasn't OTTD though as it should be possible, have been done before. Might be because i never restart my PC or whatever.
And it's not my OS either, probably just some random issue i couldn't be bothered to fix. I just wanted to play at that point in time. (Took me 2 hours just to find all the stuff i wanted to play with)
Running Win 7 Ultimate 64bit.

I remember Bilbo telling me about the memory usage for big maps but I can not remember if it was in this thread or in the More Height Levels thread ... I'll check later if I can find the discussion.

Think it was ~450 for 4096² and 1.3 gigs for 8192²

I think it was ~800MB and 1.3 gigs but I would really have to look it up to be sure.
I can not test as I only have 1 gig on my machine.
If OpenTTD would use virtual memory I could test but I do not think this is the case.
Also have a looksie at Maverick's savegame and tell me if you really need such big maps.
I mean, the map looks amazing but I do not think it will ever be filled completely before your fast machine falls apart.

/I wonder how Wasila is doing as IIRC he was playing the same map as Maverick.

"Without actually digging into the ground", yes i love 2CC and NuTracks but i am talking more along the lines of just building underground without disrupting what's on the surface.
I know it's not gonna happen for the next couple of years unless someone crazy enough just makes it happen ignoring all those "limitations" that developers like to and keep talking about.
As much as i can appreciate and understand that the map array is the reason we can't I also am a man that thinks that NOTHING is impossible if you only have the time and energy to code it.

It is also possible to code OpenTTD on Turing machine - only enough energy and stamina is required . Limitations mentioned by developers means rather "It would take about 35 years to code" than "it is impossible to do due to limits of universe".

Except I wouldn't go as far as saying it would take 35 years to code... The problem doesn't lie in how long it would take to convert it but how much work it is to convert it and the amount of knowledge one needs to have to be successful in doing so.
And ofc the necessary motivations. Neither of which i possess

But i would assume someone, with the proper motivation and knowledge, could cook something up in less than 10 work hours. It's just a matter of getting it operational first and then refining it.

I think that estimate is wrong. By orders of magnitude.

I have to agree with Kogut there. If underground levels could be done in 10 hours someone would have done so a long time ago.

Take for example the More Height Levels patch.
I can tell you that it has taken a LOT of finetuning and bugfixing to get it in the state that it is today.
I have taken a break once in a while but still many, many, many hours have been invested by me personally and I even did not have to start from scratch.
The patch has been two years in the making and it is still not finished, almost but not yet.

Thanks for help.
I currently test a patch to solve this, you can find it FS#4284 - Lag during Load and Save Multiplayer Game

No problem, although I did not do very much to help you ...

We've some desynchros, i think it caused by cargodistribution..
We use Dkarn's version (Chillicore's PP + CD + Dkarn patch + openttd's dev patch on FS#4284 thread)

I'll test with another settings for frame_freq & sync_freq

XaT

Hi XaTriX,

Is your server against recent trunk?
There were some issues with desyncs fixed in trunk after r21336 (If your version is the same as dkarn was running that is).
@see http://vcs.openttd.org/svn/

ps:
I have downloaded the sources from the french site but I can not pull a patch from it as the zip is not under version control.
If you have a patch, could I see it please?

pps:
The warnings in french.txt can be fixed by changing {STRING1} to {STRING}. The 1 is only to be used in english.txt.
Not yet playtested, just compiled.

[XaTriX]

Which french site ?

XaT

[ChillCore]

http://forum.hardware.fr/hfr/JeuxVideo/ ... 77_229.htm.
C'est bien vous, non?

I compiled the debug version in the seventh post but without enabling debugging. (downloaded a few days ago).
There seems to be a little problem with it regarding backwards savegame compatibility with trunk.
Also when it crashes the music keeps playing?? That does not sound good.

I have noticed there is a newer version on the next page ... I have not tried that one yet.

Edit:
A patch would be easier to see what went wrong and where.

[dkarn]

http://forum.hardware.fr/hfr/JeuxVideo/ ... 77_229.htm.
C'est bien vous, non?

I compiled the debug version in the seventh post but without enabling debugging. (downloaded a few days ago).
There seems to be a little problem with it regarding backwards savegame compatibility with trunk.
Also when it crashes the music keeps playing?? That does not sound good.

I have noticed there is a newer version on the next page ... I have not tried that one yet.

Edit:
A patch would be easier to see what went wrong and where.

Hello Chill,

You can find here the patch on r21366.
It's always a working version, i not apply on it dev patch.

Dkarn.

[NekoMaster]

Is there anything wrong in the latest binary?

[ChillCore]

Hello Chill,

You can find here the patch on r21366.
It's always a working version, i not apply on it dev patch.

Dkarn.

Thank you for posting the patch dkarn.
However something went terribly wrong when you pulled the patch or when you uploaded it.
There is a chunk of code that is in the patch twice ...

To fix it I had to remove patch code from line 15393 until (and including) line 19868 so that the patch reads like this.

Code: Select all

(line 15391) ...
+			break;
+
 		default: NOT_REACHED();
 	}
 
+	LinkGraphSettings &lg = _settings_game.linkgraph;
+	if (!_settings_client.gui.new_nonstop) {
+		if ((lg.distribution_armoured | lg.distribution_default |
+				lg.distribution_express | lg.distribution_mail |
(line 15401) ...

A few errors that you can already fix to avoid compiler warnings, if you want to do so ...
- After patching I had to remove the double declaration of strnatcmp in strings_type_h.
- For fixing the errors while compiling french.txt:
-- RAW_String to STRING
-- STRING1 to STRING

More important.
I know it looks cool displaying a custom revision in the title bar but that is a big nono. For a few reasons.
- Devs don't like it when you do that. If you file a bugreport there is no way of knowing what revision your patch is based upon as that string will be displayed in the crashlog. You can argue that that is not reason enough because you have no intent of posting such a crashlog on FlySpray and the GPL liscence says you are allowed to do so, but also read below ...
- You are telling your exe it is based on a version it is not, so savegames that are not compatible but saved while having the same version string will report as compatible but will crash anyway.
If the two reasons above are not enough ... here's a third.
- As of recent NewGRFs have the option to enable/disable themselves based on the revision number. Meaning that if an author knows that his grf only works after revision xxxxx. He can disable it if the revision is older than xxxxx. I have no idea what happens if the such a grf can not determine the revision but it can not be good behaviour. A few grfs are using this feature already and I suspect that their number will increase over time.

A quick test trying to load coopsavegames showed me that:
- The problem with backwards savegame compatibility with trunk is still there. This should not be too hard to restore but you will most likely lose compatibility with your current version.
- Upon crashing there is still the music that keeps playing. My patch does not display this behaviour and neither does MagicBuzz his extended version.

More when I had the time too compare the code and look at your additional code.
I have not yet compared your code to mine for other possible errors as I still have to "svn add" the new files and pull a new patch to be able to compare with my patch. I am on linux and my order of files is different in pulled patches ...
Also I have not yet bumped v11_1 neither. I will do so tomorrow.

I have seen enough code for today. Time to play a little myself.

Is there anything wrong in the latest binary?

Anything as in something that was not there in previous versions?
My savegame started with v10 still runs steady ...

Or do you mean why I have not yet updated the first post?
There was some changes in trunk recently just after posting v11_1 that I have not yet tested enough.
I am going to bump my source tommorow and if my test goes well I will post a new more recent version and update the first post also ...

Or do you mean the problems dkarn and XaTriX are having?
They are testing multiplayer and there seem to be some problems there. Although some of their problems can be reproduced in clean trunk ...

For as far as I know there are some problems loading recent coopsaves however (HQ -> Objects) and the sometimes corrupting savegames when saving manually ... I need to review the saveload code magic some more.
If I can not fix properly it I am thinking of breaking compatibility with previous versions somewhere around v12 keep it again for a while afterwards.
It is a bit harder than I anticipated and the code becomes somewhat complicated to maintain with current trunk and the patchpack both bumping at the same time ...

I have not properly tested the posted windows binary however because I was too busy.
Have you experienced something that should not happen?

Also, I am not suprised with the many bugreports as there seem to be playing a lot more people that care to report bugs than before ... Actually it suprises me more that there were fewer before.
That does not mean that there were none before or that I do not appreciate them less as can be seen by re-reading the thread.
There are just ... more.
Maybe because of trunk getting stricter in some areas ... who knows.
I'd say ... keep them coming so that I know about them. (And can then deny them coming from the patchpack while trunk gets better. )

[Sensation Lover]

Hi Chill and everyone!

I'm using your last patch. seeing the patches it contains i think it's one of the best ever patch pack. however, during the game, i'm not able to add/remove/move the newgrfs from the newgrf settings window... it's possible that i'm missing something?

[Kogut]

http://www.tt-forums.net/viewtopic.php? ... rf#p912753

[Sensation Lover]

Now that was real time. Thank you and sorry that i didn't read all the pages

[Wasila]

Did some one say mah name? I'm not really playing right now but 500 trains, 500 RVs (6 ships) and 100 aircraft, taking up (upon first loading) 300MB RAM and 23 MB HDD on the world map.

[ChillCore]

Did some one say mah name?

Yah ... I did.
Maverick is playing the same map as you, you may want to have a looksie to compare.

I'm not really playing right now but 500 trains, 500 RVs (6 ships) and 100 aircraft, taking up (upon first loading) 300MB RAM and 23 MB HDD on the world map.

Is your game running slow also with so many vehicles?
I know you have not built signals every other tile and I think that is one of the reasons of his game running so slowly (-> patchfinder going nuts ...) but I am not sure.

[Wasila]

Oh yeah, and I forgot to mention that's just me. Add to that 1,500 RVs, 35 trains and 1300 aircraft . Yeah - I did actually stick signals on every other tile - I find it necessary at least on the busiest routes - does it really impact the pathfinder?

From what I can recall from my playing it was just starting to slow down but just running it quickly now (without doing anything) with everything in the background it runs surprisingly fluidly.

[ChillCore]

Oh yeah, and I forgot to mention that's just me. Add to that 1,500 RVs, 35 trains and 1300 aircraft .

... snip ...

From what I can recall from my playing it was just starting to slow down but just running it quickly now (without doing anything) with everything in the background it runs surprisingly fluidly.

Wow that are many vehicles
Would you mind uploading your last version if you find some time, so I can compare gamespeed with Maverick's game.
Also please remind me what version you are playing.

Yeah - I did actually stick signals on every other tile - I find it necessary at least on the busiest routes - does it really impact the pathfinder?

It has been a while looked at your game. I thought you had them spaced further apart.

I myself usualy use pbs exclusively and from what I remember the last time I tested having signals every other tile, my trains did a lot of stop and and go when having trains running closely together. Maverick's trains slow a little down also just before reaching the next signal.

I once read an article on the coopserver, they have a few god tutorials there, about signal distance and according to that the best result was achieved with a signal distance of two tiles. That is what I mostly use myself also ...
I do not remember about what signal type and pathfinder the article was but as most of their games seem to be based on blocksignals, I gues it was about blocksignals ...

[Eddi]

that signals slow down the pathfinder is probably a myth, i have no clue how you got that idea.

signals are considered at three places in the pathfinder:

1. the last signal gets a penalty, to guide trains to free platforms
2. the first signal gets a penalty to avoid blocked tracks
3. the first ten [may be configurable] signals get a penalty to provide some basic load balancing

so anything beyond this doesn't affect the pathfinder at all.

what does slow down the pathfinder is having many paths of (almost) equal length. this is most common for ships, but some train networks also have this problem. Buoys/Waypoints help here.

[Maverick]

Hi Chilli,
Thanks for having a look and replying, it's appreciated!

- You have a very big map.

: Great isn't it! Really I do understand that's going to affect performance, but coming from a DX2-66MHz on 256x256 w/ 150 trains to a i7-860-3.6Ghz w/ 8192x4096 w/ 800 trains, I thought it would handle it

- You have about 800 trains and 200 trucks. That is about where the coopsavegames stop because of the game slowing down too much IIRC.

- Is 800-1000 really the hard ceiling?

- I have not checked your ships but if bouys are to far apart or non-existant they will have a negative impact on pathfinding

- Duly noted, I'll lay down some shorter routes with more waypoints.

- You have signals on every tile, IIRC that will also have a negative impact on pathfinding. The coopguys can tell you more on the subject than I can.

- I did some searching on the coop forums that I found through google, do you by chance have a direct link to their forums or other threads where they discuss performance?

As for speeding up your game:

- Try enabling the "forbid 90 degrees turns" for trains so that the pathfinder does not consider these paths and does not have to calculate if that route is shorter or not.

- Done, but no noticable difference

- Disable all details and animation. -

Where can I disable that? In advanced options?

- Disable vehicle effects. Every puff of smoke, spark and steam plume is a vehicle for as far as the code is concerned. -

Done, I'm unsure if it has made a difference, but every 1% helps.

- Try a different blitter. -

Which blitter is the highest performance? I've tried the opengl, and standard 8bpp, but it's hard to notice a difference from one to the other.

- Do a forum search on the subject as it has been dicussed many times before and more useful answers may be found.

- I have done A LOT of searching, but nothign that was really relevant to what I'm doign at the moment.

If OpenTTD would use virtual memory I could test but I do not think this is the case.
Also have a looksie at Maverick's savegame and tell me if you really need such big maps. - It's an amazing experience. I can sit down for 30 minutes after work just plotting and planning what the best route is. Part of the game becomes exploring this massive open world and trying to connect it altogether. It's no longer about fiddling with switches and small routes, but about really charging through hills, mountains and across rivers and fjords.
I mean, the map looks amazing but I do not think it will ever be filled completely before your fast machine falls apart. - I don't plan to fill it completely

/I wonder how Wasila is doing as IIRC he was playing the same map as Maverick. -

Wasila, I've dropped you an email, talk soon mate!

"Without actually digging into the ground", yes i love 2CC and NuTracks but i am talking more along the lines of just building underground without disrupting what's on the surface.
I know it's not gonna happen for the next couple of years unless someone crazy enough just makes it happen ignoring all those "limitations" that developers like to and keep talking about.
As much as i can appreciate and understand that the map array is the reason we can't I also am a man that thinks that NOTHING is impossible if you only have the time and energy to code it.

On the topic of NuTracks, is it possible for the houses above the lines to generate passengers?

[Wasila]

Running r20768M - I think it's v9_6 or something. Can we see yours, Maverick?

http://rapidshare.com/files/434998687/G ... y_2016.sav

[ChillCore]

- You have a very big map.
: Great isn't it! Really I do understand that's going to affect performance, but coming from a DX2-66MHz on 256x256 w/ 150 trains to a i7-860-3.6Ghz w/ 8192x4096 w/

800 trains, I thought it would handle it

There is a reason that Vanilla OpenTTD has not yet increased the mapsize to beyond 2048 * 2048 ...
I first tuned the patch to have longer sides possible without increasing total mapsize.
If not for someone asking to have bigger maps (in tiles) I would not have changed it.

- You have about 800 trains and 200 trucks. That is about where the coopsavegames stop because of the game slowing down too much IIRC.

- Is 800-1000 really the hard ceiling?

By no means but you have reached a limit somewhere ...
Maybe it is a combination of settings that causes the slowdown for you or maybe there is something that has changed while updating/expanding the patchpack.
I will do some more testing later after I have checked out Wasila's savegame to compare the speed it runs at.

OpenTTD will continue untill your processor melts if you let it ... maximum vehicle limit has increased, not so long ago, to more than any pc can possibly handle.
For the exact number I would have to check the sources but is A LOT.

- You have signals on every tile, IIRC that will also have a negative impact on pathfinding. The coopguys can tell you more on the subject than I can.

- I did some searching on the coop forums that I found through google, do you by chance have a direct link to their forums or other threads where they discuss performance?

I will see if I can find it later.
It is possible that I was confused as Eddi pointed out and that the article was in fact about flow of trains over the network instead of sytem performance.

Here's the link to the main page: http://wiki.openttdcoop.org/Main_Page
Some section you should defenately check out.
- Blog. -> Has some very intersting articles on advanced building concepts and from time to time savegames to show the article in action.
- Public server and pro zone archives. -> Woot, crazy savegames.
- All other links.

- Disable all details and animation.

Where can I disable that? In advanced options?

Same menu that you select to open the advanced settings, ingame, but a little lower.

- Try a different blitter.

Which blitter is the highest performance? I've tried the opengl, and standard 8bpp, but it's hard to notice a difference from one to the other.

http://wiki.openttd.org/Blitter for more info. (ps: The wiki has a search function)

- Do a forum search on the subject as it has been dicussed many times before and more useful answers may be found.

- I have done A LOT of searching, but nothign that was really relevant to what I'm doign at the moment.

Hmm, I did not find anything neither by searching. Must have used the wrong terms.
I am sure there are a few topics in the general and problems section ...

On the topic of NuTracks, is it possible for the houses above the lines to generate passengers?

I do not think so as they are rail tracks and not houses. They can not be both I think.

Running r20768M - I think it's v9_6 or something. Can we see yours, Maverick?

Lol at v9_6 or something ... good thing I put the patches in the backed-up binaries.
Link is posted on the previous page for Mavericks savegame. v10_7.

[Wasila]

Or v9_9_6... anyways, I decided it was best not to upgrade because it the advantages weren't worth the risks; I really don't want to risk losing my savegame.

Maverick, that is one hell of a game!