New map features

[JGR]

Doing the rebase wasn't so bad in the end. I've pushed the result to the tracerestrict-cirdan branch on github.
I did however skip the PBS entry signal condition feature as this would likely be cumbersome to get working with Cirdan's changes to the map array and pathfinder.
Other than that it seems to work, but I haven't done a great deal of testing.

[TrueSatan]

Wow thanks JGR, I will give it a try l8er on.

And thanks Cirdan for looking into the multi line patch. I feared that you would say something like
that. I had no time myself to look into it. But my thought where the same about the
Different tracks on one tile. As much as I like the feature, I hate it if I convert
track types from one to another with the diagonal drag feature.
I usually forget that I have sometimes another different track type
nearby and bam its changes and the train get stuck lol
Guess if the diagonal track type converter tool would only convert
the track type from the first tile you pick while dragging it along, it could
be helpful for the multi line track layer tool as well.

Nevermind just throwing my thoughts in here

Thanks Cirdan and JGR for your hard work
Cheers

[wallyweb]

Doing the rebase wasn't so bad in the end. I've pushed the result to the tracerestrict-cirdan branch on github.
I did however skip the PBS entry signal condition feature as this would likely be cumbersome to get working with Cirdan's changes to the map array and pathfinder.
Other than that it seems to work, but I haven't done a great deal of testing.

I have Branch: tracerestrict-cirdan up on github but I am unable to find the URL to which to point git clone. The HTTPS clone URL on the right points to

Code: Select all

https://github.com/JGRennison/OpenTTD-patches.git

which seems to compile to the patch-pack.

[JGR]

I have Branch: tracerestrict-cirdan up on github but I am unable to find the URL to which to point git clone. The HTTPS clone URL on the right points to

Code: Select all

https://github.com/JGRennison/OpenTTD-patches.git

which seems to compile to the patch-pack.

You can use the -b branch switch with `git clone` to select which branch to use.
Alternatively after you've done the clone you can do a `git checkout branch` to switch to a different branch. This is probably what you want in this case.
`git status` shows which branch you're on. (On my system I've got the branch and various other git-related things in the bash prompt to help keep track of things).

[wallyweb]

...

Please excuse me while I have a DOH! moment. I use Tortoise Git, but your suggestions were not in vain. They helped me to reset my mindset. A proper look at the Tortoise Git GUI found a checkbox/textbox combo named ... Branch. With

Code: Select all

https://github.com/JGRennison/OpenTTD-patches

as the URL and tracerestrict-cirdan in the Branch box, I now have the source and have compiled a working windows 32bit binary which I will post in a day or two after a bit of testing. Thanks again for working on this.

@cirdan Is there anything in particular that you would like me to look at while testing this?

[TrueSatan]

Okay had some times to check out the JGR branch and compiled it as well.
Only tested that it runs under ubtuntu 14.04, nothing more until now.
So I borrow wallys word and brnach them
Untested, without warranty, maybe unstable
but with enthusiasm done.

Btw tried my save games and they crashed immediately.
Guess I need to star a new game.

Thanks again you two

[TrueSatan]

To bad my tracerestrict compiled version breaks down on certain signal constellations.
I will try to analyse it a bit further, but it has something to do with those
signals in tunnels. games crashes only if you have signals in tunnels.

I will provide a test save game if I am back on my windows pc
with a cleaner ottd profile.

Dunno if the attached save game is helpful, because you need
to add an signal on one of the tunnel sides to provoke the crash.

Regards

[JGR]

To bad my tracerestrict compiled version breaks down on certain signal constellations.
I will try to analyse it a bit further, but it has something to do with those
signals in tunnels. games crashes only if you have signals in tunnels.

I will provide a test save game if I am back on my windows pc
with a cleaner ottd profile.

Dunno if the attached save game is helpful, because you need
to add an signal on one of the tunnel sides to provoke the crash.

Regards

Thanks for all your work testing and the bug report, I've pushed a fix to github.
The pathfinder was trying to determine whether the signal was restricted, using a function which is only valid for plain rail tiles (not bridge/tunnel entrances).

[wallyweb]

I've pushed a fix to github.

Here is the Windows 32bpp binary:

OpenTTD g6bd79239-tracerestrict-cirdan-Win32.7z

(5.46 MiB) Downloaded 98 times

With your previous push, when I saw TrueSatan's bug report, I built a tunnel and put signals on it. There was no crash. I then tried to program the signal. Quite simply, nothing happened. The game continued.
With this latest push, I loaded the saved game without incident and repeated my attempt to program the tunnel signals and, as expected, nothing happend.
The attached savepack contains a scenario, a saved game and a GRF list:

savepack.7z

(41.43 KiB) Downloaded 135 times

A suggestion ... Is it possible to add a "Last visited Depot" option?

suggestion.png (73.12 KiB) Viewed 3015 times

[JGR]

With your previous push, when I saw TrueSatan's bug report, I built a tunnel and put signals on it. There was no crash. I then tried to program the signal. Quite simply, nothing happened. The game continued.
With this latest push, I loaded the saved game without incident and repeated my attempt to program the tunnel signals and, as expected, nothing happend.

The crash was when a train reached a junction tile before the tunnel, and was scanning ahead for pathfinding purposes to determine which way to go. Creating and trying to program the signal wasn't the problematic part.
In TrueSatan's savegame, that was the tile in front of the depot.

A suggestion ... Is it possible to add a "Last visited Depot" option?

I'll have a look, it's not stored in the vehicle struct at present.

[TrueSatan]

Strange thing... the train was out of the tunnel behind some other signal.
But it only happened if you placed a signal on the tunnel end.
Trains was running fine around without problems without the signal inside the tunnel.

I will compile the new version l8er if I am back on my linux laptop.

Thanks for the fast fix JGR
So cool to have the restrict window back.

Regards

[TrueSatan]

And here is the newest cridan jgr version

Nice I can load my save games now

[cirdan]

As much as I like the feature, I hate it if I convert track types from one to another with the diagonal drag feature. I usually forget that I have sometimes another different track type nearby and bam its changes and the train get stuck lol
Guess if the diagonal track type converter tool would only convert the track type from the first tile you pick while dragging it along, it could be helpful for the multi line track layer tool as well.

Yes, this is something that I should really fix, but I cannot wrap my head around the selection code.

Is there anything in particular that you would like me to look at while testing this?

Nothing in particular, although any testing is always welcome.

The pathfinder was trying to determine whether the signal was restricted, using a function which is only valid for plain rail tiles (not bridge/tunnel entrances).

Signals in tunnels are magical; I doubt that any additional fancy behaviour can be attached to them in a sane way.

@JGR:
In case you are interested, my fork has special code to ease savegame compatibility for patches. There is an "additional version" field at the beginning of the savegame that is always 0 in my branch and can be used freely by patches to indicate a custom savegame. That field is written here (note the constant 0 as second element in the array) and checked here (note that the code complains if it is not 0). You can choose your own tag and use it instead of 0 for your modified savegames.

[JGR]

In case you are interested, my fork has special code to ease savegame compatibility for patches. There is an "additional version" field at the beginning of the savegame that is always 0 in my branch and can be used freely by patches to indicate a custom savegame. That field is written here (note the constant 0 as second element in the array) and checked here (note that the code complains if it is not 0). You can choose your own tag and use it instead of 0 for your modified savegames.

Thanks for that tip, I've used the tag 'TRRT' and switched off the experimental savegame flag. I've also added some extra fields when using that tag for future versioning.

[wallyweb]

A suggestion ... Is it possible to add a "Last visited Depot" option?

I'll have a look, it's not stored in the vehicle struct at present.

What about "Train Number"? That would solve my need for "Last visited Depot".

[JGR]

What about "Train Number"? That would solve my need for "Last visited Depot".

What sort of setup are you trying to achieve, out of curiosity?

[wallyweb]

What about "Train Number"? That would solve my need for "Last visited Depot".

What sort of setup are you trying to achieve, out of curiosity?

I was afraid you would ask.
I am attempting a very extreme test of traceroutes-cirdan.
The setting is a city station with scattered platforms with traceroutes determining access to each platform.
Referring to the attached screenshot and saved game, Train 17 should not be loading at it's current location.
That platform should be reserved for the unloading of Trains 11 and 15.
Train 17 should load at the goods platform adjacent to the factory.

The proper solution would be for each of those industrial stations to be separately named, but then that would not be extreme.

[JGR]

What about "Train Number"? That would solve my need for "Last visited Depot".

What sort of setup are you trying to achieve, out of curiosity?

I was afraid you would ask.
I am attempting a very extreme test of traceroutes-cirdan.
The setting is a city station with scattered platforms with traceroutes determining access to each platform.
Referring to the attached screenshot and saved game, Train 17 should not be loading at it's current location.
That platform should be reserved for the unloading of Trains 11 and 15.
Train 17 should load at the goods platform adjacent to the factory.

The proper solution would be for each of those industrial stations to be separately named, but then that would not be extreme.

I'm a bit reluctant to add train number or last depot conditions because they seem quite fragile.
One day you replace a train with a newer model or add another train to an existing route and your network subtly goes wrong, or if you forget to use service orders trains can near-randomly head to the wrong depot and cause all sorts of non-deterministic behaviour.

Having a group membership condition would be a bit more robust, but I'm not sure how the UI would work for that.

With reference to your savegame, the restriction pointed to by the red arrow in your screenshot does not make sense.
The result of the first 'if' clause is unconditionally overridden by the second 'if' clause. Trains which an carry goods or food are always allowed, and all others are always denied.

[cirdan]

I have pushed a minor update to the repo. It contains openttd commits up to revision 27339 and fixes importing of script libraries in 64-bit big-endian machines (reported by TrueSatan).

There are also internal changes to the drawing of waiting cargo in the station window. There should not be any visible difference, so please report anything suspicious, particularly if you play with cargodist. Game mechanics are unchanged, only the station interface could be affected.

I am preparing some changes that will make the land raising and lowering tools in the scenario editor behave the same as in game (by dragging). Is there anybody that will miss the old functionality of terraforming a square area of selectable size (as in the image below)?

[wallyweb]

I'm a bit reluctant to add train number or last depot conditions because they seem quite fragile.
One day you replace a train with a newer model or add another train to an existing route and your network subtly goes wrong, or if you forget to use service orders trains can near-randomly head to the wrong depot and cause all sorts of non-deterministic behaviour.

Good points. Bin my suggestions.

Having a group membership condition would be a bit more robust, but I'm not sure how the UI would work for that.

?

With reference to your savegame, the restriction pointed to by the red arrow in your screenshot does not make sense.
The result of the first 'if' clause is unconditionally overridden by the second 'if' clause. Trains which an carry goods or food are always allowed, and all others are always denied.

Aye! There has to be a "logical" way to combine the two "if" clauses. I will find it ... eventually, but then that is why I am testing this, isn't it?

I have pushed a minor update to the repo.

There will be a Win32 binary later today.

Is there anybody that will miss the old functionality of terraforming a square area of selectable size (as in the image below)?

The two methods are good. The "drag-and-drop" has the advantage of size/shape flexibility. Go for it!

@JGR & cirdan: With this push from cirdan, will JGR have to do a push against it as well? Is it possible (or even recommended) for me find a way to merge the two when I compile?