New map features

[wallyweb]

There is nothing in my patch, as it is now, that precludes implementation of enhanced tunnels; to the contrary, the new map array design explicitly allows for them. It is just that nothing has actually been done towards them. If they ever were to be implemented, this patch would be a far better starting point for them than current trunk, if only for the improvements in the pathfinders and wormhole handling.

Then my vote is for current patch implementation.

On a related note and in view of Supercheese's need to focus on his studies, I now have MinGW and Turquoise installed on my system and have compiled the latest diff. I'm still running some tests, but the crashes are gone and the custom bridgeheads are working as advertised.

Before I post a release, I do have one question ... Why is the version number not appearing? openttd.cfg shows:

Code: Select all

[version]
version_string = r
version_number = 14000000

and here is a screenshot of the splash screen:

noVersion.png (24.57 KiB) Viewed 6777 times

[Eddi]

content of openttd.cfg is irrelevant. version number is part of rev.cpp, which is automatically created by the makefile/config.lib (overwriting this file is useless, because it will be overwritten in each compile run)

[wallyweb]

So this begs two questions:
Question 1: Is question 2 the correct question to ask?
Question 2: When I compiled Cirdan's patch into the source and makefile/config.lib created rev.cpp, it would seem that the version number was not written. Did I miss doing something?

[Zuu]

Question 2: When I compiled Cirdan's patch into the source and makefile/config.lib created rev.cpp, it would seem that the version number was not written. Did I miss doing something?

How did you obtain the OpenTTD source code? When cloning hg/git or checking out from SVN, it will use that version when writing rev.cpp. Thus these methods are recommended over downloading the source .zip files. Also this allow you to pull the last changes instead of downloading a new full copy of the source code later when you want to update.

To aid trunk inclusion, you should of course:
a) split the patch up into separate changes (i know you've already done this, but i don't see a recent version published)
b) for minor things such as bug fixes that are (mostly) unrelated to the map features, make (individual) flyspray tasks

I had a quick look in your branch patch from April and from what I could see, there were some codechanges/fixes that would make sense on their own. I would suggest that you try to look through your patch queue and isolate changes that stands on their own and submit them to FS. This way you can reduce the size of your patch queue. (I saw that your combined patch file is 30k+ lines long which is a lot to review)

If you wish to aid reviewing and have some web space somewhere, you could upload your patch queue as individual numbered patches instead of contained in a single huge file. If you use hg or git locally you can use Bitbucket or Github to host your patch queue.


Note though that this is not a promise for review, only suggestions on what you can do to make reviewing easier. Also note that this message is my personal and not from the whole dev team.

[wallyweb]

How did you obtain the OpenTTD source code?

Thank you for replying.
I used Turtoise:

SVN Checkout.png (37.37 KiB) Viewed 6679 times

[MasterMeNL]

Now I don't know what's causing the problem, but there is a simple way to change the title in the title screen (and maybe some other stuff too).
It's located in projects/determineversion.vbs

Near the bottom you have this:

Code: Select all

	If version = "norev000" And FSO.FileExists("../.ottdrev") Then
		Dim rev_file
		Set rev_file = FSO.OpenTextFile("../.ottdrev", 1, True, 0)
		DetermineSVNVersion = rev_file.ReadLine()
		rev_file.Close()
	Else
		If modified = 2 Then
			version = version & "M"
		End If

		clean_rev = version
		If branch <> "" Then
			version = version & "-" & branch
		End If

		If version <> "norev000" Then
			DetermineSVNVersion = version & Chr(9) & revision & Chr(9) & modified & Chr(9) & clean_rev
		Else
			DetermineSVNVersion = version
		End If
	End If
End Function

I think you can just put something like

Code: Select all

version = " Special stuff rev25812"

The space is in front because the "OpenTTD" part is done somewhere else and otherwise it would read "OpenTTDSpecial stuff rev25812".
Consider this a workaround since it's not really a solution if you ask me.

I use TurtleSVN™ too and it does work properly over here. Have you tried running it as admin or disabling UAC?

Regards,

Melvin.

[wallyweb]

Have you tried running it as admin

I'm on Windows 7. I log in as Admin. Right click on the target folder offers SVN Checkout which I use. The menu also offers TurtoiseSVN with the folowing options: Repo-Browser; Export ... ; Create repository here; Import ... ; Settings; Help; About; none of which are discussed in the wiki.

or disabling UAC?

Unfortunately I am not familiar with UAC.

I agree that the workaround is not really a solution. I would rather find the problem and fix it. (The problem might be me. )

[Alberth]

The whole point of this revision detection stuff is to ensure OpenTTD versions are properly labeled. In particular, custom patched versions should not be labeled as a stable version.
People may try to join a multi-player version with it, get a desync, and then (unknowingly it was a wrongly labeled version) report the desync with us.

So please don't "fix" stuff the hacky way, you may be causing more harm than you think.

[MasterMeNL]

The whole point of this revision detection stuff is to ensure OpenTTD versions are properly labeled. In particular, custom patched versions should not be labeled as a stable version.
People may try to join a multi-player version with it, get a desync, and then (unknowingly it was a wrongly labeled version) report the desync with us.

So please don't "fix" stuff the hacky way, you may be causing more harm than you think.

I use this "hacky" way to change the label on my patch pack releases since I haven't found another (easy) way to do it.
But yeah, I agree. Better not label something custom as stable.

Regards,

Melvin.

[cirdan]

On a related note and in view of Supercheese's need to focus on his studies, I now have MinGW and Turquoise installed on my system and have compiled the latest diff. I'm still running some tests, but the crashes are gone and the custom bridgeheads are working as advertised.

Great. I am sorry I cannot personally help you with your problems regarding version detection; you seem to be running windows, where version detection is done by a vbs script of which I know nothing.

I had a quick look in your branch patch from April and from what I could see, there were some codechanges/fixes that would make sense on their own. I would suggest that you try to look through your patch queue and isolate changes that stands on their own and submit them to FS. This way you can reduce the size of your patch queue. (I saw that your combined patch file is 30k+ lines long which is a lot to review)

As I already said, the first 70 commits or so in the branch stand on their own, and they should still apply cleanly. Feel free to merge them if you want; for me, shaving the first 70 commits off a branch of (currently) 800 commits is not worth the effort of attracting your attention on the bugtracker. I already have a couple of ignored open tasks there.

Note though that this is not a promise for review, only suggestions on what you can do to make reviewing easier. Also note that this message is my personal and not from the whole dev team.

This pretty much summarises it all.

[wallyweb]

On a related note and in view of Supercheese's need to focus on his studies, I now have MinGW and Turquoise installed on my system and have compiled the latest diff. I'm still running some tests, but the crashes are gone and the custom bridgeheads are working as advertised.

Great. I am sorry I cannot personally help you with your problems regarding version detection; you seem to be running windows, where version detection is done by a vbs script of which I know nothing.

I will have more questions on this subject. Perhaps we could get a moderator to move it into a topic of its own in a more appropriate section and allow your (cirdan) topic to return to its original focus.

[cirdan]

Here is an updated version of the patch. I have rebased it on top of r25808, so it should apply cleanly against that revision, which is only a week old. The branch has not been fully ported yet, but all user-visible changes should be here (mainly custom bridgeheads). It does contain extra code for savegame compatibility, which means that future versions of this patch will be able to load savegames made with this version and with openttd trunk.

EDIT: Patch removed due to a savegame corruption bug. See below for an update.

[Lord Aro]

again, publish the patch queue, so the devs have a chance of reviewing it

[cirdan]

Well, they could always ask for it themselves, if they wanted it.

Anyway, this branch is no longer designed for review. It implements a new savegame format (new magic number, different gamelog and other changes), which is key to maintain backwards compatibility both within the branch and with openttd trunk. This branch is, in fact, a fork of openttd. I am going to wait for some days to give people a chance to test this, because porting 600 commits is likely to introduce bugs, particularly with 200-ish new commits shuffling saveload code. If everything goes well, I will merge the rest of my old branch and then start adding new features. I will also forward-port any changes to openttd trunk, which is easier than rebasing hundreds of commits across them, to keep features at a strict superset of openttd at all times.

EDIT: Patch removed due to a savegame corruption bug. See below for an update.

[michael blunck]

This branch is, in fact, a fork of openttd. [...]

This is the way to go, because chances seem to be minimal that your patches will get ever included.

regards
Michael

[Eddi]

a new savegame format (new magic number, different gamelog and other changes), which is key to maintain backwards compatibility both within the branch and with openttd trunk.

this might be a decent standalone feature to ease creation of patchpacks

[cirdan]

The last patch I posted contained a nasty bug that would corrupt linkgraphs when saving, rendering the savegame useless. The attached patch should correct this. If you downloaded my last patch, any savegames made with it will be corrupt. (This is one of the risks of messing with saveload code.) I am sorry for any inconvenience this has caused.

[wallyweb]

I am sorry for any inconvenience this has caused.

Not to worry .. Until you say otherwise, this patch is developmental and occasional inconveniences are to be expected.

[wallyweb]

Double Post - Release

Success at last.

NOT SO FAST BUBBA! The compile was on the wrong file. It has now been ammended.

Here is the ammended Win32 binary.
Unzip the file to your preferred location, copy your current newgrf folder (if you are using one) into the OpenTTD 25808M folder.
Note that saved games and scenarios from previous OTTD versions will not work, so keep those old versions handy if you have games or scenarios in progress.

Enjoy.

[cirdan]

Signals in tunnels are back!

I have finally ported the only remaining part from my original branch: signals in tunnels. And it is not a simple port, but an improved version:

• Tunnels with signals must still be one-way (all signals in a tunnel must be one-way and facing the same direction).
• A signal must be present at the exit of the tunnel. It can be either a normal signal or a path signal.
• However, there need not be a signal at the entry of the tunnel. If there is, it must be a normal signal, and it will behave specially. It will turn green as soon as the last train in the tunnel is at least one tile length away, allowing another train in.
• A train driving in a tunnel with signals will track the train ahead, if any, and will match its speed if it comes close, to avoid crashing.

As usualy, testing is welcome.