New map features

[wallyweb]

... thought a mention would be warranted (

The problem is with libicu. There were issues when I included it in my MinGW setup. Considering that it is optional, the easiest path was to exclude it. Thanks for posting the error message. I was curious what would happen if somebody whose language was read right to left were to encounter it.

[cirdan]

a small question, up to wich revision of trunk your "version" is compatible ? (it s just to know wich trunk version i can safely use to create scenario and then play them with your version)

That depends on whether you want to play the scenario now or eventually. As of now, my unmodified branch can load scenarios/savegames made with openttd revisions up to 26865 (give or take), which is right before more height levels got merged, 5 months ago, but that is just because I have not updated the maximum compatible openttd savegame version number yet (savegames would load, and I do it for testing, but it is disabled in the code). In a pinch, you can change

Code: Select all

static const uint16 OTTD_SAVEGAME_VERSION = 193;  ///< Maximum supported OTTD version

to 194 and everything should work. I will do this change myself, eventually, but I am waiting to see what the fate of more height levels is in openttd, since it seems that they are reconsidering whether to keep them for 1.5. (More height levels will continue to be supported in my branch irrespectively of what they decide, since I mostly wrote my own, different code for them and it has never shown the glitches they are now trying to fix.)

It is Lovely !! there is a noticable performance improvement ! I can't quantify it exactly but here is how i see it :

Well, this is something really unexpected (but welcome anyway, I guess). There are no changes since last update that would cause this, as far as I can tell. I am curious as to what is at work here.

Ok, it's a dirty hack and may break someone else's build, but I'll put it here anyway. Also worth noting is the exact same changes are required to build regular OTTD trunk on my system.

Thank you. I will see if I can merge your changes without breaking something else.

[HackaLittleBit]

Well, this is something really unexpected (but welcome anyway, I guess). There are no changes since last update that would cause this, as far as I can tell. I am curious as to what is at work here.

Maybe romazoon disconnected or changed his antivirus software.
That can make a huge difference!
In my computer antispyware etc slows it down by a factor of 2 or more.
I am thinking about mint linux now.

[romazoon]

In a pinch, you can change

ok thanks for the info. i can wait for now the scenario is still in my head so far

really unexpected

That can make a huge difference!

interesting then, i tried again before writing this post with the same (now a tad little bit more advanced) savegame and now I notice less improvement of performance, but i still notice on zoom out x8 less lag on the last revision than on the previous one.

And about antivirus, i checked the savegame on the different revisions right after each other without closing between the two test any other programs that might be running in background, but indeed it could also be it, i mean so many applicaction/service/software run in an hidden mode nowadays it could also be just that.

[Eddy Arfik]

Looking at that patch, you remove stuff guarded by
Code:

#if defined(__MINGW__)

- however that guarding seems not enough or not applicable to your MinGW version. I suggest you try to find an additional symbol which you have defined (maybe LP64?) but which the other MinGWs don't and adjust the #if defined directives accordingly. It would instantaneously make it to a proper and useful patch.

Revised patch is attached, I've only tested on my system but it shouldn't break anyone elses build. Maybe someone with a 32bit MinGW could verify this

Edit : removed file, attached new version to post below

[planetmaker]

Looking at that patch, you remove stuff guarded by
Code:

#if defined(__MINGW__)

- however that guarding seems not enough or not applicable to your MinGW version. I suggest you try to find an additional symbol which you have defined (maybe LP64?) but which the other MinGWs don't and adjust the #if defined directives accordingly. It would instantaneously make it to a proper and useful patch.

Revised patch is attached, I've only tested on my system but it shouldn't break anyone elses build. Maybe someone with a 32bit MinGW could verify this

openttd_mingw64_compile.patch

You can use

Code: Select all

#if !defined(__MINGW64__)
somecode
#endif

instead of an empty #if

[Eddy Arfik]

You can use
Code:

#if !defined(__MINGW64__)
somecode
#endif



instead of an empty #if

Yes you're right, the empty #if isn't the best coding style, attached is cleaner version, hopefully is acceptable

[planetmaker]

Yes you're right, the empty #if isn't the best coding style, attached is cleaner version, hopefully is acceptable

Thanks. Added to trunk in r27176.

[Quast65]

WOW! I am absolutely awestruck with this project!!

[cirdan]

attached is cleaner version, hopefully is acceptable

I see that your patch has been merged into openttd trunk, which means that it will eventually make it to my branch. However, the relevant commit in the openttd repository attributes its authorship to planetmaker, and I would rather have your patch show as authored by yourself in my branch. Would you like to be credited as the author of this patch? If so, I need to know the name under which you want to appear as author and a valid e-mail address; please note that this information will be made public in the project history.

[Eddy Arfik]

attached is cleaner version, hopefully is acceptable

I see that your patch has been merged into openttd trunk, which means that it will eventually make it to my branch. However, the relevant commit in the openttd repository attributes its authorship to planetmaker, and I would rather have your patch show as authored by yourself in my branch. Would you like to be credited as the author of this patch? If so, I need to know the name under which you want to appear as author and a valid e-mail address; please note that this information will be made public in the project history.

Thanks, but I don't think there's anything to really take credit for, if you remove the diff headers and context lines it's only 25 bytes of preprocessor directives, or in the case of your branch 50 bytes since it is applied in two places. Having a working compile environment is enough reward
I have to say I'm genuinely surprised that whoever edited the wiki page simply said 64 bit builds failed and provided no solution.

[HackaLittleBit]

Cirdan here you have a small patch for speed handling on custom bridge heads.
Train will reduce speed only when it has the intention to cross the bridge.
It will reduce speed on the bridge ramp.
Speed will not be affected when only the bridge ramp is crossed.
And ehhhh.. don't worry with credits etc.
We owe you!
Thanks.

EDIT:
This line of code takes care of braking when tile is entered diagonal or not.
You have to substitute.

Code: Select all

if (first->cur_speed > spd) first->cur_speed -= (first->cur_speed - spd) / (IsDiagonalDirection(v->direction) ? TILE_SIZE / 2 : TILE_SIZE / 4);

[Hafting]

Bug in cargo handling, cargodist makes cargo for unavailable destinations.

This happens when using cagodist and a complex economy like FIRS.
The game is supposed to only generate cargo for destinations where you actually transport stuff. The bug is that sometimes, cargo is generated for a destination where no train actually tries to bring that sort of cargo. This cargo is then unavailable for transport to "normal" places, and piles up in large amounts at various stations. The player looses money, (or must react and schedule lots of new trains. Trains for which there may not be room.)

This doesn't happen all the time, expecially not in the beginning. I think I have figured it out now:
Weird cargo is only generated when there are trains going to the weird destination that could be re-fit for the weird cargo. In the beginning there are few trains, so this doesn't happen unless you try to make it happen. The problem is that while a re-fit is possible, there are no actual re-fit orders so the cargo is never moved. Also, these "weird routes" never cancel, because new trains pass the pile all the time, and so cargodist erroneously think that "this train could bring such cargo, so the unserved route remains. Often, the re-build is of a kind that cannot happen in a station, only in a depot. So even "re-fit to available" won't help.

The error is that cargodist consider a cargo route viable if transport could happen through re-fits - even though the trains in question doesn't have such re-fit orders.

An example:

A train brings metal from a steel mill to a metal fabrication plant, and goes empty back to get more metal. For this, flat wagons is used. Now, the metal fabrication plant also receives some chemicals, as this boosts production. Unfortunately, chemicals can be transported on flat wagons. So if there is, say, a glass works near the steel mill, cargodist will think that the metal train should bring chemicals on the return trip and schedule cargo that way.

This disrupts everything, because now the chemicals pile up at the metal fabrication place, instead of being used there. Production gets lower as a result. And the metal train cannot bring chemicals, because it doesn't have re-fit orders for that. Actually, you can't re-fit from metal to chemicals in a station, so it is not as simple as changing the orders a bit. Such a re-fit can only be done in a depot, and it costs money.

This breaks the game totally around year 2000, with the newgrf's I use. At that time, the SH125 is the only reliable diesel locomotive. Unfortunately, it has a very small cargo capacity and can be re-fit for nearly any cargo. Even mail/passengers! So as my industrial lines all upgrade to this locomotive, cargodist sees LOTS of new opportunities. Cargo (and passengers) gets scheduled for all sorts of unexpected stations, because re-fitting allows this locomotive to bring anything. If I add "re-fit to available" to every stop for every train, some of that cargo will move. But not much, as the cargo capacity for this locomotive is very small. Stuff will pile up everywhere, with half-empty trains and ruin as a result, for the total cargo production remains constant. So the only option left is to quit the game.


The fix is conceptually simple:
Don't create a route that may be served by re-fitting a train, unless the train actually has "re-fit to available" in its order for that station. And obviously, only if that re-fit can be done at the station. If the re-fit is not allowed at the station, or simply not in the order list - don't create such a route.


I don't know if it is a problem with this patch, or the standard game. I haven't played the standard game for a long time, as I use the new map features a lot.

[cirdan]

Thanks, but I don't think there's anything to really take credit for, if you remove the diff headers and context lines it's only 25 bytes of preprocessor directives, or in the case of your branch 50 bytes since it is applied in two places. Having a working compile environment is enough reward

Well, you did the testing, even if that does not show up in the patch. But I am fine either way, so I will pick your commit as-is.

Cirdan here you have a small patch for speed handling on custom bridge heads.
Train will reduce speed only when it has the intention to cross the bridge.
It will reduce speed on the bridge ramp.
Speed will not be affected when only the bridge ramp is crossed.

That patch is incomplete, since it is only for the train controller but does not touch the pathfinder, which should be modified accordingly, and it also misses road vehicles. Besides, this is a change in known gameplay behaviour and I can see reasons both for and against the change, so I would rather not make it without having a general consensus on the matter.

Bug in cargo handling, cargodist makes cargo for unavailable destinations.

Thank you for your very detailed bug report. Unfortunately, my understanding of the inner workings of the cargodist subsystem is not very deep. Could you try to reproduce the bug in openttd trunk? I have not made many changes in cargodist in my branch, and I doubt they are causing this behaviour, so checking whether the same happens in openttd would give me a better starting point into this.

[romazoon]

Bug in cargo handling, cargodist makes cargo for unavailable destinations.

posting a savegame showing the problem would also be a good start, right ? i would like to check the problem, see if i can help solving it

[HackaLittleBit]

Ahh I saw it on the first page!(Known issues:)
Road vehicles forgotten by me. (Sloppy, I admit)
You can however see the patch as a vote.
As far as I understand, trains choose a track direction when they reach a new tile.
So for trains, the chosen direction remains the same until the end of a tile.
They can slow down until the bridge (wormhole part) is reached.

I am not familiar with road vehicle behavior.
I think that path finding for them is somewhere done while they are on the middle of the tile.
Still, the moment they choose to go in the direction of the bridge (wormhole part), their destination will
not be changed anymore and they could start slowing down if necessary.
See red dots on design.
Overtaking should not be allowed on bridge-heads for simplicity sake.
Regards

[Eddi]

i'm pretty sure road pathfinding also happens on tile borders. (but i don't actually know)

[Hafting]

Bug in cargo handling, cargodist makes cargo for unavailable destinations.

posting a savegame showing the problem would also be a good start, right ? i would like to check the problem, see if i can help solving it

But of course.
Here is a game with FIRS and a nice profitable steel business.

There are 3 groups of train.
One brings iron ore to the steel mill station. It also bring engineering supplies back to the mine, if any such is dropped off at the steel mill by other trains.

The other group brings scrap iron to the steel mill. It also pick up engineering supplies from a machine shop. Some of that gets used to boost the scrap yard production. Cargodist also ensures that some supplies are brought to the steel mill for transfer to the iron ore mine. The capacity for engineering supplies is deliberately too low, so some piles up at the machine shop. (Periods of low capacity is something I consider normal for this game, you can only afford so many trains. Later you may have the money, but then it is harder to keep an eye on everything.) Low capacity encourages cargodist to consider alternative routes.

The third group of trains bring metal from the steel mill to the machine shop, and creates the problem. Everything was fine until I added "refit to available". Such re-fitting is not necessary in this game, but it'd make sense if it was possible to pick up timber or wood at the machine shop station.

But now cargodist misunderstands. Metal is moved on flat wagons, and flat wagons are also used for engineering supplies. So cargodist seems to think that excess engineering supplies could be brought from the machine shop to be transferred at the steel mill by re-fitting my metal train. The metal train has a more direct route (no stop at the scrap yard), so it is preferred. Seems like a good plan, except that you cannot re-fit from metal to engineering supplies in a station. opengfx+ trains needs a depot for that sort of re-fit.

So engineering supplies piles up at the machine shop. Increasing capacity on the train that actuall moves engineering supplies won't solve this, as the metal train with its direct route seems preferable.


In this particular case, the problem is easily solved by the player. It is no longer easy when you have 150 trains on all sorts of routes, trying to maximize profit by never letting anything pile up anywhere. It is fine that cargodist tries to take advantage of re-fit orders - I like that! But it should only consider re-fits that are possible. With 're-fit to available', check if the re-fit sought is possible to do in a station. Some re-fits are depot-only, cargodist should not consider those. (There is never cargo in a depot.)

So, flat wagons can be re-fit to engineering supplies, but not if they currently have the stakes on. Then it is metal/timber/wood only.

Similiar problems arise with other re-fits that cannot be done in a station. My oil trains often use re-fit to available, in order to pick up petrol & chemicals produced when they arrive at the oil refinery. That re-fit is allowed, but problems happen if a milk train stops at the same station. You can't re-fit from oil to milk in a station, but cargodist will assume it works. Similiar for a few other re-fit options.

A third such problem is with flat wagons & forests. Bringing farm supplies to a forest and wood out is both done with flat wagons, but that re-fit is not allowed in stations either. If such a train has re-fit to available anywhere along its route, then other trains will drop farm supplies off at that point. Supplies that are very much needed somewhere, but cannot be picked up.

In long-running games I tend to get long routes with lots of re-fits along the way. A single train can then bring several kinds of cargo in very flexible amounts, and serve many industries along the way. A bulk wagon train can serve all the different kinds of mines and drop off at many consuming industries. This works well for bulk, where the re-fits I need are all allowed in stations. And then I put a few flat wagons on such a train, to spread out engineering supplies to those mines. And suddenly, metal piles up here and there Usually solveable by adding a metal train following the same route, but that is expensive and often inefficient too.

[Eddy Arfik]

It is fine that cargodist tries to take advantage of re-fit orders - I like that! But it should only consider re-fits that are possible. With 're-fit to available', check if the re-fit sought is possible to do in a station. Some re-fits are depot-only, cargodist should not consider those. (There is never cargo in a depot.)

This problem exists in trunk as well, it has been discussed in several other threads. Basically "depot-only refit" is a bad feature*, any refit that can be done should be able to be done at a station, as the game assumes that to be the case.

* it's more game-breaking than using GEAR cargo imo

[Hafting]

It is fine that cargodist tries to take advantage of re-fit orders - I like that! But it should only consider re-fits that are possible. With 're-fit to available', check if the re-fit sought is possible to do in a station. Some re-fits are depot-only, cargodist should not consider those. (There is never cargo in a depot.)

This problem exists in trunk as well, it has been discussed in several other threads. Basically "depot-only refit" is a bad feature*, any refit that can be done should be able to be done at a station, as the game assumes that to be the case.

* it's more game-breaking than using GEAR cargo imo

If depot-only refits are bad, how about fixing that in the game? Either allow all re-fits in stations - or drop the depot-only refits completely. In one case, an oil tank can be converted to milk at a station. In the other case, you decide what kind of tank it is when you first buy it, you can never change from clean cargo to dirty. (Other than by selling the wagon and then buy a new one - which costs.)

I guess obsoleting newgrf's won't be popular? So an old newgrf may still specify a depot-only refit, but the game won't have to honor that spec.