Chill's patchpack v14_7

Ferrarius · **Joined:** Tue May 03, 2011 11:52 am **Posts:** 29

damerell wrote:

Ferrarius wrote:

Another possibility I just came up with is simply saving the amount of space travelled, and the percentage which every transporter added to that. That won't see the memory usage rise as much as the cargo packet's memory usage is static.

And times, remember. But the packet's memory usage can't be static if this problem is to be solved. If all the transporters are to get the right payment when the packet finally arrives, the packet has to know who they all were, and that is a list of potentially unlimited length.

Does a server serve serve an unlimited amount of users? No, at most 29. 14 AIs and 15 players (using r22273).

Michi_cc · **Posted:** Tue Apr 03, 2012 1:28 pm

damerell wrote:

Or would using some more memory on modern systems be basically unnoticeable? I don't know and neither do you, and I'd be interested if anyone who does know comments.

It's not only about the used amount of memory which is indeed not very relevant with multi-GB memory. The real problem with big memory usage is that the random access bandwidth of memory hasn't significantly increased in the last years. Marketing always refers to the peak bandwidth for continuous transfers, but lots of cargo packets with lots of additional data bits are the complete opposite of continuous memory.

-- Michael Lutz

handrake · **Joined:** Mon Mar 26, 2012 10:23 am **Posts:** 55

Michi_cc wrote:

damerell wrote:

Or would using some more memory on modern systems be basically unnoticeable? I don't know and neither do you, and I'd be interested if anyone who does know comments.

It's not only about the used amount of memory which is indeed not very relevant with multi-GB memory. The real problem with big memory usage is that the random access bandwidth of memory hasn't significantly increased in the last years. Marketing always refers to the peak bandwidth for continuous transfers, but lots of cargo packets with lots of additional data bits are the complete opposite of continuous memory.

-- Michael Lutz

Does this mean any program with a big enough memory usage (such as OpenTTD) should have its own memory (de)allocator to resolve fragmentation issues?

Lordmwa · **Posted:** Tue Apr 03, 2012 4:15 pm

The problem with OTTD is not the memory useage it is the CPU usage. I usually find OTTD uses very little ram but is maxing out a core of my CPU

Michi_cc · **Posted:** Tue Apr 03, 2012 6:00 pm

handrake wrote:

Does this mean any program with a big enough memory usage (such as OpenTTD) should have its own memory (de)allocator to resolve fragmentation issues?

I'm not talking about memory fragmentation. Cargo packets are accessed at random, no allocator can change that. As more memory is used, the percentage of it that fits into the CPU caches shrinks and more and more stuff has to be pulled from main memory. Randomly accessing main memory is a lot slower than reading a continuous stream of data.

-- Michael Lutz

damerell · **Joined:** Fri Feb 22, 2008 11:09 pm **Posts:** 176

Ferrarius wrote:

damerell wrote:

Ferrarius wrote:

Another possibility I just came up with is simply saving the amount of space travelled, and the percentage which every transporter added to that. That won't see the memory usage rise as much as the cargo packet's memory usage is static.

And times, remember. But the packet's memory usage can't be static if this problem is to be solved. If all the transporters are to get the right payment when the packet finally arrives, the packet has to know who they all were, and that is a list of potentially unlimited length.

Does a server serve serve an unlimited amount of users? No, at most 29. 14 AIs and 15 players (using r22273).

Wait, you are concerned only with the right allocation of per-company payment? That makes more sense. I agree that, while it doesn't fix many of the problems, it would be a useful step forwards for games where multiple companies may transport the same packet, and the memory usage is necessarily limited in that case.

ETA: I misunderstood you because I read "transporter" as "vehicle" not "company".

damerell · **Joined:** Fri Feb 22, 2008 11:09 pm **Posts:** 176

Michi_cc wrote:

I'm not talking about memory fragmentation. Cargo packets are accessed at random, no allocator can change that. As more memory is used, the percentage of it that fits into the CPU caches shrinks and more and more stuff has to be pulled from main memory. Randomly accessing main memory is a lot slower than reading a continuous stream of data.

Aha, interesting point. But presently in large games, can one not already reach a state where essentially no cargo packet data is cached when it is needed?

Eddi · **Joined:** Wed Jan 17, 2007 12:14 am **Posts:** 4618

so just because a problem is already there, you can safely make it worse?

damerell · **Joined:** Fri Feb 22, 2008 11:09 pm **Posts:** 176

Eddi wrote:

so just because a problem is already there, you can safely make it worse?

Well, if the game runs well with cargo packet data being essentially all cache misses, it wasn't a problem and you wouldn't be making it worse.

Edited (whoops, twice in three posts) to add: I'm not just trying to handwave this concern away; but increasing the memory issues wouldn't be being done for no good end; it would be being done to fix another problem, one that is very frequently complained about and particularly is an issue for games where multiple companies may transport the same cargo packet. So an obvious question to ask there is which problem is the worse one.

ZxBiohazardZx · **Posted:** Thu Apr 05, 2012 6:45 pm

is there a pre-build version somewhere? i got the last prebuild from a friend, but the extra heightmaps are messing up heightmap generation bigtime, the maps come out compeletely different on the version i have compared to the 1.1.1 stable release, using the same generator && settings

Ferrarius · **Joined:** Tue May 03, 2011 11:52 am **Posts:** 29

http://bundles.openttdcoop.org/chillpp/ ... h4f8131fc/ Pick the proper one

SwissFan91 · **Posted:** Mon Apr 09, 2012 9:21 pm

This.

Any help?

Supercheese · **Posted:** Mon Apr 09, 2012 9:22 pm

Well, IIRC if you use conditional orders, automatic vehicle separation will fail.
Also IIRC, if you have ships with buoys in their orders, they cannot be autoseperated.

SwissFan91 · **Posted:** Mon Apr 09, 2012 9:32 pm

I hope this screenshot is helpful!

The four buses on this route have all seemed to bunch up together. They haven't even been running that long, and I made sure to leave a gap between each vehicle when they were created.

Supercheese · **Posted:** Mon Apr 09, 2012 9:50 pm

You say they've not been running long, so does letting them run for a bit longer help? The autoseperation doesn't immediately take effect, from what I've observed. Try fast forwarding for a while and see if everything is automagically solved.

SwissFan91 · **Posted:** Mon Apr 09, 2012 9:53 pm

Further investigation finds that they are 19 years old. I'll try leaving it a while longer whilst I build elsewhere, but it is fairly annoying seeing all my departure boards 'ruined' by all four buses arriving at once.

Chris · **Posted:** Mon Apr 09, 2012 10:27 pm

For autoseparation to work, you need all of the buses to have shared orders, and absolutely no conditional order, which included service at depots. You cannot, unfortunately, have perfectly separated vehicles which also don't go to the depot at random times.

ChillCore · **Posted:** Mon Apr 09, 2012 10:30 pm

Swissfan,
Only vehicles that are part of the same shared orders group are seperated provided that they also have a timetable (automated or not).
None of the busses in your screenshot belong to the same group, I can tell from the greyed-out button next to the autofill button.

Also ... I have not yet abandoned my patchpack, I have found a few days to code last week and managed to bump aproximately 500 revisions closer to trunk than r22555 while maintaining savegamecompatibility with the older versions. Yay :lol:

This means a few new (trunk) features, support for version 8 NewGRFs and lots of bugfixes that come with bumping.
Also the warning when using the original graphics is gone ... it was indeed a mistake on my side (read: spritecount was of compared to the openttd.grf that actually comes with r22555).
No new features have been introduced by me for the moment.

I still have a little conflict to fix between r23067(IIRC) and the infastructure sharing patch besides testing a little bit if everything still works before I will post the newer version.
Now don't get your hopes up too much yet in regards of me being able to bump all the way to trunk, there is still a little more than 1000 revisions to go and the hardest part has yet to come.

I will answer some more questions tomorrow.

Edit: Ninja'd by Class 165

SwissFan91 · **Posted:** Mon Apr 09, 2012 10:32 pm

I'm fairly sure my buses never go to the depot. So I need to set up shared orders exactly as detailed here?

[EDIT] Thanks, Chill.

ChillCore · **Posted:** Mon Apr 09, 2012 10:40 pm

Quote:

So I need to set up shared orders exactly as detailed here?

Yes indeed, if that does not work then please post your savegame.

Transport Tycoon Forums

Chill's patchpack v14_7

Who is online