New map features

[wallyweb]

Are texts and descriptions clear enough?

Select goods collect behaviour at stations:

"goods" is a cargo. This might be confusing. How about:
"Select cargo collect behaviour at stations:" ?

[cirdan]

We now have a git repository for the fork! This means that I will probably stop posting whole diffs here, as the sources can always be fetched from there. And you can download a tarball for whatever commit you want, too. I may keep posting patches here for new or experimental features, to seek review.

"goods" is a cargo. This might be confusing. How about:
"Select cargo collect behaviour at stations:" ?

That is certainly clearer, thanks.

If you'd hop on irc at some point, you can help the devs in explaining your rationale behind some of the patches

Sorry, but I do not use IRC; I have never used it, and do not really feel like starting. It may be that I am probably too old for it. Plus I do not think it is the best means of posting and reviewing patches. A mailing list or a bugtracker is much better suited for this task, as it allows everybody to reply in their own time, and properly format their thoughts.

And yes, i understand that this is somewhat of an uphill battle

I dislike this train of thought that states that contributors should have to chase the devs and fight their way to get a patch accepted. I have contributed to several other free software projects and in most of them contributions are welcome, and patches are actively reviewed. This does not mean that they are blindly accepted, but at least they are examined and you are told what is wrong with them. And you are very likely to receive a reply if you actively ping a patch for a year.

EDIT: I'll elaborate a bit further:
The main problem the devs have with your patches is that there seems to be several patch queues intertwined. For example, it is not clear how the saveload changes are relevant to the goal of the new map array. The devs don't like change for the sake of change.

The changes in the saveload code are there because the devs mostly ignored my patch for a year and a half when it did not touch saveload code (much), so I got fed up and started my own fork of openttd: I changed the savegame format and I prepared the saveload code to load savegames both from openttd and in the new format. And this took about 200 commits, which is what you are seeing now.

Anyway, most of those changes stand on their own. For instance, look at the following code snippet from openttd trunk

Code: Select all

/**
 * Do something of which I have no idea what it is :P
 * @param proc The callback procedure that is called
 * @param arg The variable that will be used for the callback procedure
 */

and check that it is no longer present in my branch. Guess why.

[wallyweb]

We now have a git repository for the fork! This means that I will probably stop posting whole diffs here, as the sources can always be fetched from there. And you can download a tarball for whatever commit you want, too. I may keep posting patches here for new or experimental features, to seek review.

I just compiled a Win32 binary using the source from git. As far as I can tell, it is the same as the binary I released above. Were any there changes since the released Win32 binary? If not, I'll not release the git one as it would only be repitition.

The only difference I can see is that the source in git does not include a version which might be handy for knowing which release the player is using.

[Eddi]

The only difference I can see is that the source in git does not include a version which might be handy for knowing which release the player is using.

that is probably your build environment's fault.

[wallyweb]

The only difference I can see is that the source in git does not include a version which might be handy for knowing which release the player is using.

that is probably your build environment's fault.

MinGW ... plus I downloaded the tarball without SVN Checkout.
Compiling OTTD from trunk gets me a version. Compiling a patch onto trunk gets me a version + M.
I could point SVN Checkout to git, but what URL do I use, and will that get a version?

[Eddi]

downloading a tarball will not get you a version, indeed. you need a git checkout to get a version

[wallyweb]

indeed. you need a git checkout to get a version

OK ... This suggests to me that SVN Checkout will not do the trick and that I gotta get git and point it to either git://repo.or.cz/openttd/fttd.git or to http://repo.or.cz/r/openttd/fttd.git
Now all I need is a Windows7 client. Any suggestions/recommendations?

[Eddi]

you need MinGW's git for the version detection, and then you can use either that for the checkout, or there should be a TortoiseGit...

[wallyweb]

you need MinGW's git for the version detection, and then you can use either that for the checkout, or there should be a TortoiseGit...

Tell my secretary to rechedule tomorrow's appointments. I gotta get git.

Thanks for the help.

[cirdan]

I just compiled a Win32 binary using the source from git. As far as I can tell, it is the same as the binary I released above. Were any there changes since the released Win32 binary? If not, I'll not release the git one as it would only be repitition.

That is right, the git repo does not contain anything new yet. It will, of course, in due time, as I start pushing there.

[wallyweb]

Good. This gives me time to get a git compiler up and running.

[WWTBAM]

You don't need a git compiler, you just need a git client. The default MinGW client should be called git.

[wallyweb]

You don't need a git compiler, you just need a git client. The default MinGW client should be called git.

That is how I got the OTTD binary with no version. As Eddi mentioned, I need something for the Checkout.

[Gremnon]

First, make sure your MinGW envrion actually has git available.

Code: Select all

git --version

(Just in case.)
Then, find the path to the repository you wish to use and tell git to go get it for you:

Code: Select all

git clone git://repo.or.cz/openttd/fttd.git

Which should create the folder 'fttd' in the current working directory. cd into it and run configure and make as per usual.

[cirdan]

I have pushed a bunch of changes into the repo. Some of them are cherry-picks from openttd, others are code cleanups (mostly in the track follower), and there is a workaround for the compilation problem with MSVC reported by Supercheese here (thanks!); by the way, section 5.3.3 of the C++ standard states that sizeof can be applied to an unevaluated operand expression, so the compiler is misbehaving here. There is only a user-visible fix, namely trains coming to a full halt when a block signal is immediately followed by a one-way path signal before accelerating again.

I am attaching my current patch for cargo selection at stations, to be applied on top of the current development tip (4eac8644915137c45a6c91da62b0d8f58821ac69). It is large, but mainly because of the amount of strings removed from translations, and still subject to change (that is why I have not pushed it yet). The only issue I can find with it is that open station windows will resize in unexpected ways if you change the collect behaviour on the fly, although their contents will be correct, but I cannot seem to get it right (any advice?). Also, I have not received any feedback about what to do with neutral stations (oilrigs), if we should hard-code their behaviour or add yet another server setting for them. As always, testing is welcome; note that the savegame format is not finalised yet, so any savegames made with this patch will not load with anything else, not even with trunk when the patch is merged (you will get a prominent message about this at program startup).

There is another question I would like to seek help on. Time ago, I received a report about custom road bridgeheads not having pavement (sidewalks). While this is working as intended, because that is how I designed them, it does not mean that we cannot change it. What do you think? How does TTDP do it?

[Eddi]

i had another idea for a cargo selection mode: if cargodist is set to anything other than "manual" (this may be different for each cargo), then supply only cargo if there is a connected destination (i.e. don't generate any cargo "to any destination")

neutral stations should probably be hardcoded.

[cirdan]

i had another idea for a cargo selection mode: if cargodist is set to anything other than "manual" (this may be different for each cargo), then supply only cargo if there is a connected destination (i.e. don't generate any cargo "to any destination")

Could you elaborate a bit on this? I am not familiar with cargodist, so you may have to fill in some details for me. I understand that a link is only created after a vehicle capable of carrying a particular cargo type completes a trip; is this correct? And you want cargo to appear only after such a trip completes, right?

neutral stations should probably be hardcoded.

To what? Collect cargo after a vehicle tries to load it?

[Eddi]

I understand that a link is only created after a vehicle capable of carrying a particular cargo type completes a trip; is this correct? And you want cargo to appear only after such a trip completes, right?

i'm not quite up-to-date with this, but in the past i had the problem that before the round-trip was complete, a lot of cargo with "to any stations" appeared, and this means it cannot be unloaded at intermediate stations. but you should probably talk to fonso about the details.

neutral stations should probably be hardcoded.

To what? Collect cargo after a vehicle tries to load it?

no idea, honestly.

[cirdan]

I have updated my branch here. It now contains all the features and bugfixes added to openttd trunk up to revision r26359, which is two weeks old, plus a lot of internal code changes, but no other new user-visible features. In fact, I have published my recent work because I am somewhat stuck with my roadmap; my plans were to work towards signals on bridges and custom tunnelheads, but I have not found an elegant way to code them, so I may leave them for a while, waiting for inspiration. In the meanwhile, I will keep picking commits from openttd trunk, or I may begin work on some other feature (suggestions?).

[TrueSatan]

Thanks Cirdan
Will compile it later.
I really enjoy the new tunnel behavior.
Would really like to see that in trunk. It make long tunnels finally more usable.

Custom tunnel heads would be nice, maybe only for diagonal and only
for slow tracks Never seen any high speed track on a tunnel head.
Or only for roads not for tracks.

Dunno if signals on bridges really needed.
Since your patch brings at least signals on bridgeheads.

Only feature i really would like to see currently is PBS support at the end of a tunnel.
Since i usually build my bigger stations with PBS and sometimes a long tunnel
connects up to the station so i need one tile track for the PBS.

But i am very satisfied with the patch as it is, using it since month now and had no crash so far.

Keep up the excellent work