New map features

[romazoon]

that s not what you need ? but that s all i ve got when the game crash (the crash.png+crash.log+emergency save).

And about the crash, yes it did happen when i built a signal on that exact tile showed on the screenie, and the tile before is a waypoint.

Me wonder if the problem is not coming from the depot located behind that freight train loading, and being connected to all the freight's station tracks...i suspect it cause i ve seen the depot act a bit strange lately with pathfinder...

sorry for not reporting this before actually, i m just never able to reproduce exactly those strange behavior :

the 1st strange behavior i talk about is that some trains stay locked inside the depot waiting for free path (happens usually after a train visit a depot and try to exit, if there is no free path at the exact time the trains tries to come out i ve seen train staying locked until i tell them to ignore signal).

The other strange behavior is concerning trains that have an already reserved path to a depot (let s say to go for service). Now, if i try to give them the order to stop inside depot by clicking the train's depot icon , trains say there is no depot accessible (on stable it works)

[Eddi]

no, the debug file must come from the person who compiled the .exe

but you should also have a crash.dmp file.

[romazoon]

no, the debug file must come from the person who compiled the .exe

that would be wally then i believe.

but you should also have a crash.dmp file

yes you are right, i also have crash.dmp, i hope you don t need it though cause it got "replaced" since that other day with a new and unrelated "crash.dmp" (my savegame got corrupt(message) and crash on loading, probably cause i ve modified a couple newgrf so i m not reporting it neither complaining or anything...)

now the good news into my broken savegame is that now I will restart a game, and this time will try to keep the newgrf shorter and avoid to mess to much with newgrf

[wallyweb]

no, the debug file must come from the person who compiled the .exe

that would be wally then i believe.

Recompiling with --enable-debug
I should have it up later today.

[wallyweb]

The debug version is compiled and available here.

[cirdan]

And about the crash, yes it did happen when i built a signal on that exact tile showed on the screenie, and the tile before is a waypoint.

Thanks. I will see what I can do, but keep your expectations low, since the bug is not reproducible and I have no usable stack trace.

the 1st strange behavior i talk about is that some trains stay locked inside the depot waiting for free path (happens usually after a train visit a depot and try to exit, if there is no free path at the exact time the trains tries to come out i ve seen train staying locked until i tell them to ignore signal).

I cannot reproduce this on my own. A savegame where this is happening (the train in the depot is stuck) would be useful here.

The other strange behavior is concerning trains that have an already reserved path to a depot (let s say to go for service). Now, if i try to give them the order to stop inside depot by clicking the train's depot icon , trains say there is no depot accessible (on stable it works)

This one I can reproduce and has been appended to my bug queue.

[cirdan]

Branch updated.

• There are many changes in the network code that deals with multiplayer. Ideally, the only user-visible change should be a slight reduction in network bandwidth usage, but there may be bugs lurking.
• A bug regarding sending a train to a depot when it was already halfway into one has been squashed (reported by romazoon).
• I have fixed this openttd bug, since it also affected my branch and it looks like it will not be fixed there.

As always, any feedback is welcome.

[romazoon]

sounds great and thanks for the fix as usual.


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)

[wallyweb]

Branch updated.

Thank you and here is the latest unguaranteed Windows binary:

OpenTTD-g93693d36-Win32.7z

(5.44 MiB) Downloaded 41 times

Question: Did anybody attempt to download the debug version of the previous release which I linked to above?

[romazoon]

Thanks Wally for the binary, will use that right away

and about the debug version, i did downloaded it, but i haven t tested it much, i tried a bit to reproduce the "signal" crash, but with no success.

[wallyweb]

Thanks Wally for the binary, will use that right away

and about the debug version, i did downloaded it,

Excellent. It was too fat for these forums so I tried something new to me: Google Drive. I'm glad it worked.

It takes a while to compile and almost as long to upload to the drive, so I'll only be doing it if there is a need, but do not hesitate to ask.

[Eddy Arfik]

Here is a Windows 64-bit binary

OpenTTDnmf_g93693d36M_win64.7z

(5.27 MiB) Downloaded 35 times

Also here's a binary with applied daylength patch

OpenTTDnmf_g93693d36M_daylength_win64.7z

(5.28 MiB) Downloaded 42 times

[TrueSatan]

And here is the Ubuntu 64bit compiled version of g93693d36

[Eddi]

OpenTTDnmf_g93693d36M_win64.7z

you should probably double check that. it shouldn't have "M" in the version.

[romazoon]

want some feedback on latest version ?

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

with revision g8bebb0db, i load a very busy game (around 1000 trains, over 2500 RV, 389 ships, map 2048x1024, 750K unit delivered per trimester), on the two latest zoom it s lagging so much that i had to desactivate the x8 and x4 zoom (out) so i would not by mistake take the laggy zoom mode (it became really almost frozen)

with the latest revision, i tried same savegame and with both the 32bits from wally, and the 64 bits from Eddyarfik, and both run smooth on zoom out level x4 and x8, and i mean really smooth.

so I guess i have got to say thanks for that you just gave me many more hour of enjoyment on a game i cherish

[Eddy Arfik]

OpenTTDnmf_g93693d36M_win64.7z

you should probably double check that. it shouldn't have "M" in the version.

Yes, since it isn't modified in any gameplay way it probably shouldn't have the M, but it appears automatic since MinGW requires changes to win32.h and strings.cpp in order to compile 64 bit binaries. Maybe next time I'll manually edit rev.cpp to avoid confusion.

[planetmaker]

OpenTTDnmf_g93693d36M_win64.7z

you should probably double check that. it shouldn't have "M" in the version.

Yes, since it isn't modified in any gameplay way it probably shouldn't have the M, but it appears automatic since MinGW requires changes to win32.h and strings.cpp in order to compile 64 bit binaries. Maybe next time I'll manually edit rev.cpp to avoid confusion.

You should use the exact same version information each time you compile. It even creates less confusion

Honestly: submit the modifications to make it compile as patch sot that you do not need a modified source!

[Eddy Arfik]

Honestly: submit the modifications to make it compile as patch sot that you do not need a modified source!

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.

nmf_MinGW_64bit_compile.patch

(1.15 KiB) Downloaded 40 times

[planetmaker]

Honestly: submit the modifications to make it compile as patch sot that you do not need a modified source!

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.

nmf_MinGW_64bit_compile.patch

Looking at that patch, you remove stuff guarded by

Code: Select all

#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.
The code referenced in your 2nd hunk in string.cpp is not part of OpenTTD anymore for 10 months already (as of r21476).

[te_lanus]

I've also found that the current (win32) build is faster than before.

@wallyweb found a missing "feature". Accidentally changed me language to Arabian (since it's just below Afrikaans), and it complained:

Clipboard02.png (1.85 KiB) Viewed 1727 times

Doubt anyone uses it here, since I've yet to see someone complain, but thought a mention would be warranted (