New map features

[Eddi]

A speed limit tax pathfinder
2: with GetSpeedLimit( etc etc

The actual slowing
3: and when the train is slowed in the train controller.

i don't know what you're trying to say here. 2 is there because of 3... how does that make it an "additional" penalty'?

[HackaLittleBit]

I am thinking along these lines.

Fixed track costs
diagonal - or not
curves
speed limit
slope
etc

Variable costs
signal red, green
station
loading
depot
etc

Fixed costs don't have to be calculated again and again
That is only necessary when layout is changed.
Speed limit should be applied to any kind of track if not available from sprite info.
(example non electrified=100 electrified=160)
No discrimination against bridges! (By not including speed cost for tracks bridges pay disproportional.)
Just add all tracks together with speed limitation and divide them by tracks counted.(including wormholes)
That way you could have:
A fixed average speed cost(cache) per node.
A variable cost.(maybe cache if nothing changed)
I know most of the things are done now already, but they are mixed.

Like that I think, you could choose more precisely the correct optimal track for trains.
e.g. slower trains on slower track(bridge), fast trains on fast track(bridge).
I don't know if this is possible.
It is just some brainstorming.

I don't have much time at the moment(weeks).
Have a nice weekend.

EDIT errr..

(example non electrified=100 electrified=160)

read this as: if faster or slower than that value you get penelized.

[romazoon]

I found maybe a bug.

La Rochelle Transport, 8 Fév 1935.png

(127.44 KiB) Downloaded 7 times

On this image : this bridge can not use the bridghead feature (apparently due to be built on what seems to be a double built on slope fundation)

La Rochelle Transport, 22 Fév 1935.png

(127.55 KiB) Downloaded 7 times

on this image, i try to build tramway tracks, but it fails and refuse to build any tram tracks on the bridge.

La Rochelle Transport, 22 Fév 1935#2.png

(122.86 KiB) Downloaded 7 times

there is a trick working though, it s to upgrade the bridge (but using the tram tracks building gui)

[romazoon]

after adding the tram track though...there is a real bug though

La Rochelle Transport, 22 Fév 1935#3.png

(122.8 KiB) Downloaded 7 times

-> dynamiting the bridge make appear a tile of road that i can t delete by any means.

La Rochelle Transport, 24 Avr 1935.png

(134.56 KiB) Downloaded 7 times

-> using the bulldozer tool...is even worst

La Rochelle Transport, 21 Mai 1935.png

(133.85 KiB) Downloaded 7 times

-> the message when trying to demolish the "buggy road"



those screenies/test were made in a fresh new game i launched with only one newgrf, ones that add tramways. version used is g93693d36M (i believe the 64bit compile made by Eddy Arfik, NOT the daylenght one)

[cirdan]

Thank you for your bug report, as always. I can reproduce the bugs in a new game on my own, and they do seem to be related with bridge heads on steep tiles. I will try to look into this as time permits.

[cirdan]

Branch updated with a month and a half worth of changes:

• Compilation with MSVC has been (hopefully) restored, at least with MSVC 2008 and MSVC 2010.
• Fixed a crash when loading a savegame in which a station had been deleted but whose sign was still lingering.
• Trains will now treat tunnel signals as any other signal when deciding whether to reverse while stopped at them (previously they would take a long time to reverse even if facing a one-way signal from the wrong side).
• Fixed a crash when no AI scripts are available and the game is configured to use a non-English language (openttd fs#6272).
• Fixed a bug when using the bridge building tool to add a road type to an existing bridge (reported by romazoon).
• Custom bridge heads can now be built on steep slopes (suggested by romazoon).
• Sync with openttd r27173.

Plus lots of code cleanups, as usual; this time it is mostly in scripting and newgrf handling. While these should not have any user-visible effect, there is always a chance that I made a mistake. Bug reports welcome.

[romazoon]

thank you for your continuous effort, you are amazing

[wallyweb]

Branch updated with a month and a half worth of changes

which are all included in the attached distribution:

OpenTTD-g506ca861-Win32.7z ( recompiled for fix noted below )

Guarantees and Easter eggs not included.

Thank you Cirdan.

Enjoy

[te_lanus]

Found a bug (hope this one is an easy fix)

Using Wallyweb's build, the re is no more gamescripts. doesn't happen in 1.5.0. when you go to select one it brings up a list with all the GS-libs. And using a config file from previous version with a GS selected cause the GS to crash on new game, and not function in a loaded game

[cirdan]

Found a bug (hope this one is an easy fix)

It was.

Using Wallyweb's build, the re is no more gamescripts.

Aye, I made a silly mistake with an identifier. I have just pushed a fix. Thanks for reporting.

And using a config file from previous version with a GS selected cause the GS to crash on new game, and not function in a loaded game

These I could not reproduce. Perhaps they are related to the other bug? If these bugs persist after last commit, could you provide more detailed information?

[wallyweb]

A new commit for Cirdan's fix noted above:

OpenTTD-g05b338d6-Win32.7z

(5.44 MiB) Downloaded 44 times

Enjoy

[TrueSatan]

Thanks Cirdan for the update and the fixes for the update
A bit l8er then wally this time, but here is the Ubuntu Version as well.
As usually its 64bit for Ubuntu 14.04

Happy playing.
Cheers

[te_lanus]

And using a config file from previous version with a GS selected cause the GS to crash on new game, and not function in a loaded game

These I could not reproduce. Perhaps they are related to the other bug? If these bugs persist after last commit, could you provide more detailed information?

Most that I tried this morning work, except one Busy Bee Tried reproducing the error in 1.5.0 but it works there so doubt it's a script error

On a side note is it possible to update the LAnguage files in the next release

[Eddy Arfik]

Compilation with MSVC has been (hopefully) restored, at least with MSVC 2008 and MSVC 2010.

Here is standard Windows 64bit binary, compiled with MSVC 2013 (I find MinGW more efficient, but I decided to test the MSVC compile, and indeed it is working again)

binary with daylength applied to follow in the next few days (patch doesn't apply cleanly and I don't have much free time until weekend)

[cirdan]

Most that I tried this morning work, except one Busy Bee Tried reproducing the error in 1.5.0 but it works there so doubt it's a script error

I may have found the cause of this bug. My branch was still advertising itself as openttd revision 25808 (the revision where I forked off a year and a half ago), and busy bee was using an interface that is no longer valid as of 27164. I have fixed this by advertising proper openttd revision compatibility; the commit is already in the repository. Note, however, that this means that the script will never work in a binary compiled without version detection (if it says "norev000" in the main screen menu title bar), and this is valid for openttd trunk as well.

Thanks for reporting; I am surprised that this had never shown up before.

On a side note is it possible to update the LAnguage files in the next release

You mean the translations? I forward-port all changes to the translations strings from openttd. Is there anything missing?

[te_lanus]

On a side note is it possible to update the LAnguage files in the next release

You mean the translations? I forward-port all changes to the translations strings from openttd. Is there anything missing?

I fixed quite a few translation errors in my home language, afrikaans, and the changes only show in trunk

[cirdan]

I fixed quite a few translation errors in my home language, afrikaans, and the changes only show in trunk

I deliberately lag a few weeks behind openttd trunk to be able to squash bug fixes with the commit that introduced the bug. If your changes were recent, it will take a while until they are merged into my branch.

[wallyweb]

I have fixed this by advertising proper openttd revision compatibility; the commit is already in the repository.

... and the 32 bit binary release is attached below ...

OpenTTD-g1a7823f8-Win32.7z

(5.44 MiB) Downloaded 42 times

[TrueSatan]

And here the linux updated

[te_lanus]

Most that I tried this morning work, except one Busy Bee Tried reproducing the error in 1.5.0 but it works there so doubt it's a script error

I may have found the cause of this bug. My branch was still advertising itself as openttd revision 25808 (the revision where I forked off a year and a half ago), and busy bee was using an interface that is no longer valid as of 27164. I have fixed this by advertising proper openttd revision compatibility; the commit is already in the repository. Note, however, that this means that the script will never work in a binary compiled without version detection (if it says "norev000" in the main screen menu title bar), and this is valid for openttd trunk as well.

Thanks for reporting; I am surprised that this had never shown up before.

Thanx it's working again