Patch: New passenger destinations

[athanasios]

Let's wait 2 years and we will see. There are practically no more single core processors available in the market. A few Athlon advertised as for office use only.

[Tiberius]

OpenTTD is inherently very difficult to parallelize ...

Key sentence: Serializing/Locking the map array access (among others)

[Eddi]

Let's wait 2 years and we will see. There are practically no more single core processors available in the market. A few Athlon advertised as for office use only.

you are forgetting:

a) that openttd is impossible to parallelise, that would basically involve a complete rewrite of the game
a*) even if you can parallelise pathfinding and other high CPU demanding tasks, multiplayer will be impossible to handle because the order of execution is vital for that
b) a lot of handheld devices are just starting to get into the range where they can support openttd
c) >50% of the people here will use the same PC in 2 years than they do now

also, CPU usage is hardly the main problem of the current patch

[MJS]

also, CPU usage is hardly the main problem of the current patch

Is it? But it gives OTTD decisive hiccups at the start of every new day. Or is that just me? If I turn paxdest off in the patch settings, the game runs as smoothly as ever. And the hiccups start occuring only after I have created a large amount of stations, growing longer as I add even more stations...

[Eddi]

i didn't say it is not an issue. but seriously, the main problem of this patch is the multiplayer compliance

[athanasios]

the trend is to go multi core and not increase the speed dramatically. So eventually OTTD will have to change...

[amirtaheri]

Hi. I'm trying to apply this patch to the latest trunk build of OTTD. The merging of the patch went fine and I have myself the make file etc, but when I enter "make" or "make build" to compile the patch, this is what I get:

Macbook:/users/amirtaheri/openttd amirtaheri$ make
make[1]: *** No rule to make target `/users/amirtaheri/openttd/src/core/alloc_func.cpp', needed by `alloc_func.o'. Stop.
make -C /users/amirtaheri/openttd/objs/lang strgen
make[2]: *** No rule to make target `/users/amirtaheri/openttd/src/core/alloc_func.cpp', needed by `alloc_func.o'. Stop.
make[1]: *** [/users/amirtaheri/openttd/objs/lang/strgen] Error 2
make: *** [all] Error 2

I have no idea what is missing or what is wrong, but I desperately want this patch!

Any ideas as to what's wrong?

[belugas]

the trend is to go multi core and not increase the speed dramatically. So eventually OTTD will have to change...

Who cares about the trend??? trends come and go. Not going to pursuit all the new stuff coming in and going out as quickly.
Like... Savegames in XML!! Yeah... a Riot... XML, savvior of the world! And now, of course, it's time for the multi-core stuff... Come on...

And Eventually, OTTD will have to change??? Have you ever heard of a rewrite? That's what OTTD will need in order to support those multi-core.
No thanks.

[athanasios]

I understand it needs a rewrite. Quite impossible.

Yet we were discussing multi-core years ago (at least my history with PC's goes back to 386 times) and now it is a reality. With current technology it seems there is no other way to increase the speed. We have almost reached the "wall". If we are to implement new passengers dest., Ai's, pathfinders, larger maps, etc, there is no other solution.

You would make my day, if you could prove me wrong.

regards
athanasios

[Grandmaster]

Is it possible to make a AI that is a stand alone program and that the game can use that program. The game can still stay with one core and the AI program can use the power of the other core's and simply sends the results to the game of some sort. If it can work u can also link the separate AI's together in a multi player game. Don't make it to smart, because i don't want terminator scenario's when they link together

[BlueEagle_nl]

Guys, are we still discussing the New Passenger Destinations patch here???

[Eddi]

Like... Savegames in XML!! Yeah... a Riot... XML, savvior of the world!

XML is like violence, if it doesn't solve your problems, you are not using enough of it...

[Grandmaster]

Guys, are we still discussing the New Passenger Destinations patch here???

Yes, In a way we are still talking about new passenger destinations and what should happen to make it smoothly work in the game. The use of more core's can help en on that point the discussion went about the core's and that the game should get a rewrite and no one of the dev's are willing to take the job for several reasons.

[fonso]

That's all idle talk. Paxdest can well be done without a complete rewrite and it isn't necessarily a resource hog. The problem with the previous implementation is the pre-calculation of routes. Each month it runs a complex algorithm across all stations on the map in order to find out, where the passengers are going. This is a waste. You don't need to know where they are going beforehand. You can recursively assign an importance rating to each station and vehicle, depending on configurable parameters, and have them choose vehicles and stations to enter and leave on the fly. This can easily be done by drawing random numbers weighted by importance (they don't even have to be strictly pseudorandom, only well spread across the available spectrum). Even the recursive calculation can (and should) be broken up into an iterative process. Each time a vehicle enters a station both the vehicle and station check if something has changed with each other since the last time the vehicle was there. If that's the case both recalculate their importance. Each single calculation will be very simple then and as long as nothing changes there will only be the random numbers as additional calculation compared to the absence of paxdest.

[prissi]

On look at the last old passenger destination patch, which was built wiht the simutrans experience in mind to make it an as small resource hog as possible using binary search of weighted arrays and the like.

[MJS]

Hear, hear! Anyone wanting to take this up? What was bad about the old patch again? Just that it wasn't geared at cargo packets, or was there more?

[prissi]

It has synchronisation troubles with network. Also it used array (which are more efficient than lists), which have to used with cargo packets.

The synchronisation troubles might go away with reimplementation, since these originated mainly from the old limit of 4095 people at a station and not saving the additional routing info with stations.

[BlueEagle_nl]

What bothers me most of the current paxdest are:

• The small hiccups at the begining of each day, especially with large networks (as described a few messages before)
• The fact that routing information is not saved in the savegame, which can result in some 4000 passengers on a station, wanting to go to a station which is not connected to the current line, or even doesn't accept passengers (which happened to me each time I loaded a Paxdest Savegame)
• Not so very much understandable abbreviations in the Stops-screen (well, you have to read the readme to understand them, I didn't the first time I played with it...

Especially when routing information would be saved in the savegame, I'd love to test this patch to squash those bugs and get it in trunk!

[Vikthor]

If you would follow openttd IRC you would know that this patch won't get to trunk. The symptoms you are describing are caused by fundamental flaws in the patch, so the only viable solution is complete rewrite - new patch.

[MJS]

you have to read the readme to understand them

Where did you find this readme? The first post only has a *.diff...