I tested the tunnel signals.1. I built a one way signal on the tunnel exit tile.2. This caused a signal to appear at the tunnel entrance tile.3. I stuffed three trains into the tunnel.4 They all came out safe and sound.

I tested the tunnel signals.1. I built a one way signal on the tunnel exit tile.2. This caused a signal to appear at the tunnel entrance tile.3. I stuffed three trains into the tunnel.4 They all came out safe and sound.

Hey, I did some testing myself. It is not as if I am sending your drivers and passengers to a certain death.

By the way, are you sure about 2? Signals should not automatically appear at the other end of a tunnel when you first build them, only if you later try to turn them around.

Here is an update of the patch, to be applied against r25917. It builds on the previous one, and has quite a few internal cleanups and the following user-visible changes:

Allow overbuilding of airports. This is a small but very useful patch that I have had floating for too long; now that I have my own branch, I can as well merge it.

Multiple docks per station. This is a pet feature of mine that I wanted to have for a very long time, and now I have got around to implementing it.

I cannot compile that version, I get myriad errors about 'GameLog' and 'unique_ptr' and the like, such as " 'unique_ptr' : is not a member of 'std' ". I'm thinking it has to do with C++11 features being used that my compiler (VC++ 2008 Express) can't handle, but I'm not 100% certain.

I cannot compile that version, I get myriad errors about 'GameLog' and 'unique_ptr' and the like, such as " 'unique_ptr' : is not a member of 'std' ". I'm thinking it has to do with C++11 features being used that my compiler (VC++ 2008 Express) can't handle, but I'm not 100% certain.

It might be the case. Could you please try replacing

Code:

std::unique_ptr

with

Code:

std::tr1::unique_ptr

in lines 61 and 63 of src/gamelog.h and compiling again? Those are the only occurrences of unique_ptr in the sources, and I have seen reports that MSVC still has unique_ptr under the std::tr1 namespace, but not under std yet.

This has happened a couple of times while trying to unpause in the Scenario editor and in a game (same scenario).Now it is happening in the Scenatio editor when I try to build two or more oil rigs.The Crash reason is the same.The scenario was created in r25917M. I tried it as a game in 1.3.1 stable and got the same crash.

in lines 61 and 63 of src/gamelog.h and compiling again? Those are the only occurrences of unique_ptr in the sources, and I have seen reports that MSVC still has unique_ptr under the std::tr1 namespace, but not under std yet.

Unfortunately that did not help. It seems I need to upgrade my compiler...

Thanks for pointing me to that. My mouse left button thanks you and my right index finger thanks you.

@cirdan - I compiled a plain vanilla unpatched r25917 and the crash issue goes away.Also, the issue seems to only occur when building oil rigs.Note that i tested both with and without GRFs. The problem remained.

Multiple docks per station. This is a pet feature of mine that I wanted to have for a very long time, and now I have got around to implementing it.

Could we get the multiple docks as a seperate patch? I've also waited for this for a long time.

Well, if you are going to patch the sources, why not go with the full patch? No feature in it is forced upon you; you can just play without custom bridgeheads, signals in tunnels or any other addition.

wallyweb wrote:

CRASH REPORTIs it the diff, the compile or me?

This has happened a couple of times while trying to unpause in the Scenario editor and in a game (same scenario).Now it is happening in the Scenatio editor when I try to build two or more oil rigs.The Crash reason is the same.The scenario was created in r25917M. I tried it as a game in 1.3.1 stable and got the same crash.

wallyweb wrote:

I compiled a plain vanilla unpatched r25917 and the crash issue goes away.Also, the issue seems to only occur when building oil rigs.Note that i tested both with and without GRFs. The problem remained.

Aye, I introduced a bug in BuildOilRig when adding support for multiple docks per station. I forgot to add a check that the oilrig dock can be allocated, as I did for stations, and the pool code complains loudly. The attached patch should fix this.

Supercheese wrote:

cirdan wrote:

It might be the case. Could you please try replacing

Code:

std::unique_ptr

with

Code:

std::tr1::unique_ptr

in lines 61 and 63 of src/gamelog.h and compiling again? Those are the only occurrences of unique_ptr in the sources, and I have seen reports that MSVC still has unique_ptr under the std::tr1 namespace, but not under std yet.

Unfortunately that did not help. It seems I need to upgrade my compiler...

Did you get the same errors? It seems that I will have to get access to a MSVC compiler to avoid these issues in the future.

Supercheese wrote:

Well, I upgraded to Visual Studio Express 2012, and now I get different errors (although fewer of them, so I guess that's a plus).

I seem to recall reading somewhere in the forums that MSVC 2012 does not compile openttd trunk either. Could you please check if you get the same errors there?

From the log you posted with MSVC 2012, the compiler seems to dislike applying the sizeof operator to a non-static member array. I could try to look up the relevant parts of the standard to see if this is valid or not, but that would not help you anyway: telling you that the compiler is at fault will not make the code compile. But, at the very least, considering that previous versions worked just fine, I would call it a regression.

Anyway, let us try to get it working. If those are the only errors you get, you should be able to fix them by explicitly stating the lengths of the arrays. Changing 'lengthof(AiSaveload::name)' to '64' and 'lengthof(AiSaveload::settings)' to '1024' in _ai_company, and similarly in _game_script, should allow the compilation to proceed.

I, too, would like the multiple docks per station patch separately. Also, zeppelins are indeed the best method of transport.

Can I third this? A separate patch would almost certainly be far easier to work into my little patchpack than your enormous thing - I'd probably just have to start from scratch for that.

Unfortunately, adding the possibility of multiple docks per station requires some changes to the pathfinders, and all three of them (remember--there are three pathfinders for ships) underwent massive changes when I added custom bridgeheads. Plus there are many other, more recent changes in other parts of the code which make cherry-picking the relevant commits highly non-trivial.

I am attaching the whole branch I currently have, if anyone is interested in trying themselves. Apply on top of r25808 with 'git am'; the last 5 commits implement multiple docks per station. Be prepared for heavy merge conflicts, though. (I should really find a place to publish my branch and post changes, to stop spamming the forum with huge attachments.)

FLHerne wrote:

Could also give it a better chance of trunk inclusion - looks like several of the smaller changes already got in?

Yes, Lord Aro took it upon himself to push some patches to the devs. He has managed to merge 10 of my patches in openttd; in the meantime, my branch has grown by 50. I do not think this pattern will converge...

On a related note, I have begun implementing cargo selection at stations to be added to my branch. Currently, cargo can be chosen to be automatically gathered at all stations or only at those stations already visited by a vehicle capable of loading a particular cargo type, and this works on a game-global scale. My plan is to give players the ability to manually select which cargoes to gather at each station, so you can start collecting cargo before a vehicle arrives, or stop accepting it after that.

I have more or less sorted all the technical details, but I would like input on the user interface and some other details for this feature. As of now, companies have a setting for station cargo gathering, which can take the following values:

Always: Any cargo is delivered to any station within range.

Automatic: Cargo is only supplied to stations marked to accept the particular cargo type; stations initially accept no cargo; a cargo type can be manually toggled to be accepted or not; a vehicle trying to load cargo triggers supply at the station.

Manual: Cargo is only supplied to stations marked to accept the particular cargo type; stations initially accept no cargo; a cargo type can be manually toggled to be accepted or not; no automatic change ever happens.

Also, each company has its own value for this setting; the attached screenshots should give you an idea of how it works.

The first issue is whether this system matches what people would expect. If you have ever wanted such a feature, would the above meet your needs?

The second issue is what to do with neutral stations (eg oilrigs). Should the server be left to decide, or should their behaviour be hardcoded, and to what?

The third issue is the user interface. Is it intuitive? Can you think of something better? Are texts and descriptions clear enough?

(I should really find a place to publish my branch and post changes, to stop spamming the forum with huge attachments.)

Have you considered an openttdcoop devzone repo? They're relatively easy to set up

cirdan wrote:

FLHerne wrote:

Could also give it a better chance of trunk inclusion - looks like several of the smaller changes already got in?

Yes, Lord Aro took it upon himself to push some patches to the devs. He has managed to merge 10 of my patches in openttd; in the meantime, my branch has grown by 50. I do not think this pattern will converge...

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

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

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.

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum