New map features

[wallyweb]

Looking good. One month and 18 20 downloads since the last commit and compiles and no bug/crash reports.
I've started my first full game in almost two years and so far all is working as expected and intended.
Thank you cirdan.

[cirdan]

Looking good. One month and 18 20 downloads since the last commit and compiles and no bug/crash reports.
I've started my first full game in almost two years and so far all is working as expected and intended.

That is good to know.

In the meanwhile, I am not idle with my fork, even if it may seem so. There is not much worth of publishing at the moment, but I am currently trying to clean up the scripting code somewhat, although this will not have any direct impact on the game from the point of view of a user.

[wallyweb]

I am currently trying to clean up the scripting code somewhat, although this will not have any direct impact on the game from the point of view of a user.

clean up spells s-t-a-b-i-l-i-t-y

[TrueSatan]

Any chance - while cleaning up - to catch up with the trunk?

Game runs very good so far

Guess if I find the time I will see if there is any chance to apply
the Multil-ine Tool (http://www.tt-forums.net/viewtopic.php?f=33&t=70966)

Thanks again for this wonderful patch-pack

Cheers

[cirdan]

I am currently trying to clean up the scripting code somewhat, although this will not have any direct impact on the game from the point of view of a user.

clean up spells s-t-a-b-i-l-i-t-y

Yes, and I am very keen on simple, clean, understandable code. And it certainly pays off—I have found and fixed many bugs just because they became apparent after tidying up a subsystem. Take, for instance, this recent openttd bug (with thread) regarding pathfinding on mixed electrified/non-electrified rail tracks. I have tested it on my branch and it does not exhibit this bug, but I had never found it before as such, so I can only guess that it was fixed as a consequence of the heavy rework I did in the pathfinding code.

Any chance - while cleaning up - to catch up with the trunk?

I try to keep my branch lagging about 2 weeks behind openttd trunk, to review their commits in batches (not that there are that many, though) and sometimes pick several of them together, but I only update the public repo every now and them, usually when I have a bugfix or a new feature. This means that my local branch is more or less up to date with openttd trunk, but the published one is not.

(Besides, I am currently away from my main development system, where I have the ssh keys to the repo, so there will not be any update in a few weeks anyway. I would tell you not to find any bugs in the meanwhile, but last year I did and you immediately reported one. )

Game runs very good so far

Nice to know.

Guess if I find the time I will see if there is any chance to apply
the Multil-ine Tool (http://www.tt-forums.net/viewtopic.php?f=33&t=70966)

I may have a look, but from the first post in that thread I do not quite get if the "full" patch is multiplayer-safe, which is a must.

[TrueSatan]

I will try my best to find that bug then
Maybe then you will find a way to access the main development computer
Just kidding, its okay, I haven't found anything unusual. So far game runs great.

And I am aware that you are using your own devel branch but its not
a bad idea to be near the same devel point that the main trunk has.
And maybe some day the devs will have a look into your code and
will have it in trunk as well

For the Multi-Line tool:
I only wanted to see if its possible to use with your patch. I am not sure
that there is a way to apply it, because you modified the way you
can lay tracks (like having two types of track at one tile).
But it would be a nice addition. I will have a look if I find some time.
Always thought it would be a good idea to lay double tracks, safes some time.

In any way the current code is stable enough to experiment with other patches.

Thanks again Cirdan and all others contributing in any way

Happy construction and playing

[adf88]

Guess if I find the time I will see if there is any chance to apply
the Multil-ine Tool (http://www.tt-forums.net/viewtopic.php?f=33&t=70966)

I may have a look, but from the first post in that thread I do not quite get if the "full" patch is multiplayer-safe, which is a must.

It is multiplayer-safe. Limited version is compatible with unpatched servers.

[cirdan]

I have pushed a new batch of commits to the repository. The most prominent change is a thorough cleanup of the scripting code: I have wiped about 3000 lines of code, and the text segment of the resulting binary has shrunk by 100K; if you usually play with any kind of scripts (computer opponents or game scripts), testing is certainly welcome. There is also a fix for a crash that could happen on very rare circumstances when a company went bankrupt, and I have imported openttd changes up to revision 27327.

And I am aware that you are using your own devel branch but its not a bad idea to be near the same devel point that the main trunk has. And maybe some day the devs will have a look into your code and will have it in trunk as well

Do not hold your breath. They have had years for that.

It is multiplayer-safe. Limited version is compatible with unpatched servers.

I will try to have a look then.

[wallyweb]

I have pushed a new batch of commits to the repository.

Good to see you back in your home environment.

... and here is the Win32 binary ...

Note that I have now included in the folder name the OpenTTD version number to which NMF has been rebased.
This so that a player wishing to apply a patch to NMF wiil have a quick reference to the compatibility of the desired patch.

Enjoy

OpenTTD-REBASED-r27327-g58c462c2-Win32.7z

(5.44 MiB) Downloaded 35 times

[TrueSatan]

Hurray, thanks Cirdan
Here is the Ubuntu 14.04 64bit version as usual and some warnings, that I think
I haven't seen before.

Code: Select all

[SRC] Compiling script/script_infolist.cpp
[SRC] Compiling script/script_instance.cpp
In file included from /nmf/src/script/script_instance.cpp:13:0:
/nmf/src/script/script_instance.cpp: In static member function ‘static SQInteger ScriptInstance::Import(HSQUIRRELVM)’:
/nmf/src/script/../string.h:365:55: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘std::map<const char*, const char*, StringCompare>::size_type {aka long unsigned int}’ [-Wformat=]
  snprintf (bstrfmt__buffer, bstrfmt__size, __VA_ARGS__); \
                                                       ^
nmf/src/script/script_instance.cpp:230:3: note: in expansion of macro ‘bstrfmt’
   bstrfmt (fake_class, "_internalNA%u", engine->loaded_library.size() + 1);
   ^
/nmf/src/script/../string.h:365:55: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘std::map<const char*, const char*, StringCompare>::size_type {aka long unsigned int}’ [-Wformat=]
  snprintf (bstrfmt__buffer, bstrfmt__size, __VA_ARGS__); \
                                                       ^
/nmf/src/script/script_instance.cpp:230:3: note: in expansion of macro ‘bstrfmt’
   bstrfmt (fake_class, "_internalNA%u", engine->loaded_library.size() + 1);
   ^
[SRC] Compiling script/script_scanner.cpp
[SRC] Compiling script/squirrel.cpp
[SRC] Compiling settings.cpp
[SRC] Compiling settings_gui.cpp
[SRC] Compiling ship_cmd.cpp
[SRC] Compiling signalbuffer.cpp
[SRC] Compiling station_cmd.cpp
[SRC] Compiling strgen/strgen_base.cpp
[SRC] Compiling strings.cpp
[SRC] Compiling subsidy.cpp
[SRC] Compiling timetable_cmd.cpp
[SRC] Compiling toolbar_gui.cpp
[SRC] Compiling town_cmd.cpp
[SRC] Compiling train_cmd.cpp
[SRC] Compiling tunnelbridge_cmd.cpp
[SRC] Compiling vehicle.cpp
[SRC] Compiling water_cmd.cpp
[SRC] Compiling waypoint_cmd.cpp
[SRC] Compiling widget.cpp
[SRC] Compiling window.cpp

And someone can dream about getting this patch some day into the trunk.
But yes I guess its very unlikely.

Btw no time to spend investigations on multi line building tool or JGR's patch with the programmable signals.
Read the threads tough and guess its to complicated and time intensive to adapt them now.

Cheers

[wallyweb]

...JGR's patch with the programmable signals.

JGR's patch is currently based to r27386 whereas NMF is currently based to r27327. We must wait for when Cirdan is ready to rebase NMF to a later version than r27386.

[JGR]

...JGR's patch with the programmable signals.

JGR's patch is currently based to r27386 whereas NMF is currently based to r27327. We must wait for when Cirdan is ready to rebase NMF to a later version than r27386.

Nothing major has changed between r27327 and r27386, and you'd need to do a rather involved rebase/cherry-pick either way, so there wouldn't be anything to be gained by waiting.

[wallyweb]

[... so there wouldn't be anything to be gained by waiting.

It failed ...

[JGR]

[... so there wouldn't be anything to be gained by waiting.

It failed ...

It's not going to suddenly start working if you wait. Cirdan's branch looks nothing like trunk.

To port it across you'd need to do something along this line of (having checked out Cirdan's branch)

Code: Select all

git cherry-pick -x master..tracerestrict

and resolve the merge conflicts at each stage. I had a go yesterday but don't have time to finish the doing the conflict resolution/renaming things at the moment. I may do the rest in a few days.

[wallyweb]

I had a go yesterday but don't have time to finish the doing the conflict resolution/renaming things at the moment. I may do the rest in a few days.

As you have seen and Cirdan has noted in many of his posts, much of his work has been cherry picking and code clean-up. The nice thing is that he has been able to push along the way and has been able to resolve bugs quite quickly. I am a big fan of your tracerestrict work in TTDPatch and appreciate your porting it as a patch to OpenTTD. If I knew what the Heck I was doing, I'd offer to lend a hand in adapting your patch to Cirdan's NMF. Your efforts are greatly appreciated. Hopefully this is not an ongoing project to be repeated with each new NMF push.

@Cirdan, In your pevious rebase, I was able to apply HackaLittleBit's Everest patch successfully. One thing that I and SwissFan91 noticed was that saved scenarios did not work accross to a similarly patched OpenTTD. Is this to be expected, perhaps due to the differences between NMF and trunk?

[cirdan]

Here is the Ubuntu 14.04 64bit version as usual and some warnings, that I think I haven't seen before.

You are right, those warnings are new, and could cause trouble on 64-bit big-endian machines. I will fix them.

JGR's patch is currently based to r27386 whereas NMF is currently based to r27327. We must wait for when Cirdan is ready to rebase NMF to a later version than r27386.

I no longer rebase my branch against openttd. Any patch against openttd must be manually picked on top of my branch.

In your pevious rebase, I was able to apply HackaLittleBit's Everest patch successfully. One thing that I and SwissFan91 noticed was that saved scenarios did not work accross to a similarly patched OpenTTD. Is this to be expected, perhaps due to the differences between NMF and trunk?

Yes, anything from openttd should load in my branch, but the reverse route is not possible.

[wallyweb]

Thanks for the replies

I no longer rebase my branch against openttd. Any patch against openttd must be manually picked on top of my branch.

... and this describes what JGR wrote here ?

[cirdan]

Yes—merge conflicts as JGR describes are bound to happen if both patches touch the same piece of code. And my branch changes only certain parts of the codebase, but those that it does are changed heavily, making conflict resolution very difficult (and git markers almost useless). Usually the best course of action in this case is to rewrite the changes, one commit at a time, from the new branch.

[wallyweb]

Usually the best course of action in this case is to rewrite the changes, one commit at a time, from the new branch.

My gratitude to JGR for his efforts just increased exponentially ... ^10

[cirdan]

Guess if I find the time I will see if there is any chance to apply the Multil-ine Tool (http://www.tt-forums.net/viewtopic.php?f=33&t=70966)

I have taken a look into this and unfortunately adf88's patch interferes with some changes I did to allow two parallel tracks of different types on the same tile. This is not to say that porting his patch is impossible, but it will require non-trivial merging.