New map features

[wallyweb]

I may begin work on some other feature (suggestions?).

A while ago I had some chat and the possibility of the flat bridge abutment accomodating a station tile.
I have also seen mention of station tiles being buildable on bridges.

Will compile it later

Any chance of the executable being posted here?

[TrueSatan]

Hey Wally,

sorry i only compile a linux (Ubuntu 13.10 currently) version so far. Playing the patch on my laptop.
Tried to compile the windows version but constantly failed with my compiler setup lol.

But i could provide the linux version if someone wants it

[TrueSatan]

Sorry Cirdan, but i found some let me call it unusual behavior

If you use the auto completion tool for signals (CTRL + Direction)
I miss some signals or they are in the wrong direction.
No problem, its easy to fix, just click a few times until they are
completed or in the right direction, but maybe you could have a look (or two)

Oh and i like the idea of having station tiles on bridge heads. Never tried it,
but could be useful.

Like signals on station tiles would be nice too. Guess that will be a dream

Patch working flawless (except the little things mentioned earlier) on my save game.

Thanks again for that wonderful patch

[HackaLittleBit]

Ech tile contains information to indentify what it is. e.g. tree-tile, tunnel-tile, station-tile.
see http://hg.openttd.org/openttd/trunk.hg/ ... scape.html
So stations on tunnels is impossible.

Placing signals on tunnels is only manual.

I found small bug tough.
You have to check the signal placing code.
Placing and removing is not consistent.
To reproduce:
Place signal.
does not place signal on both sides.
Change signal direction places signal on other side.
removing:
Sometimes take both, sometimes only one.(depends on tunnel side)

Furthermore;
Amazing job Cirdan!

[wallyweb]

sorry i only compile a linux (Ubuntu 13.10 currently) version so far.

I do have a very old Ububntu installed on one of my PCs but the dust would require an archeologist to retreive it.
My XP box might be a candidate for a dual boot, but the hard drive is making scary noises.
My Windows7 lap top has lots of room but I wil wait a bit before mucking around with it.
Result?
I downloaded the snapshot tar.gz
Assuming that it is a fork and not a patch, I compiled it with MinGW.
The result is a playable version of OpenTTD and it does all that Cirdan said it should do.
However, the splash screen does not show a version number. Is this normal?

[TrueSatan]

Since i used git clone i got a rev number from there. dunno if you have any trouble without the right rev number.
maybe you don't get every available addon from the online content.

Guess i have to see if i can get windows compiling to work.

btw. why not trying to clone the git wally? you could use tortoise git -> http://code.google.com/p/tortoisegit/
for getting it and then compiling it with mingw.

Anyone tried Visual Studio Express 2013 for compiling the source?

[planetmaker]

However, the splash screen does not show a version number. Is this normal?

Builds from tar bundles have no means to establish version unless special precaution is taken during creation of the tar bundle. So yes, that's normal.

[cirdan]

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.

I would love to, as that would spare me from maintaining my own branch, but there is so much I can do about it.

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

They can really help with long bridges.

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.

That should already be possible. Have you tried cycling the signal at the exit of the tunnel? The exit signal can be either a normal signal or a one-way path signal.

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

Thanks! Testing is always welcome.

I may begin work on some other feature (suggestions?).

A while ago I had some chat and the possibility of the flat bridge abutment accomodating a station tile.
I have also seen mention of station tiles being buildable on bridges.

Gee, I announce that I am putting off signals on bridges because I cannot find the right way to code them and you suggest stations on bridges...

...or that is what I first thought. But a good question is better than a good answer, and on second thought your suggestion made me look at the problem in a different way. What if we stopped trying to always pack all the information about a bridge in the map array? When I designed the new map array, I reserved 4 bits for the information about a bridge above a tile, which is enough to store whether there is a bridge and whether there is a signal on the particular bridge segment and its state, if any, independently for both axes. But now I wonder if we could store the bridge as a sequence of tiles elsewhere, off-map, and make them full-fledged tiles. This does not mean that everything will be allowed on a bridge, and would not be required for all bridges either, only for those rail bridges that are not a simple long piece of track.

I will have to give these ideas some thought.

Sorry Cirdan, but i found some let me call it unusual behavior

There is nothing to be sorry about.

If you use the auto completion tool for signals (CTRL + Direction)
I miss some signals or they are in the wrong direction.
No problem, its easy to fix, just click a few times until they are
completed or in the right direction, but maybe you could have a look (or two)

I had hoped nobody would notice...

Seriously, that is more of a feature than a bug. Signals in tunnels are "magical" in that they do not obey the same rules as other signals, because the signal into a tunnel may be green even if there is a train inside, so I decided that automatic placement of signals should not mess with tunnels.

I found small bug tough.
You have to check the signal placing code.
Placing and removing is not consistent.
To reproduce:
Place signal.
does not place signal on both sides.
Change signal direction places signal on other side.
removing:
Sometimes take both, sometimes only one.(depends on tunnel side)

That is intended, as well. There must always be a signal at the tunnel exit. When you first build a signal in a tunnel end, it is placed to make that end the exit of the tunnel. But, if you toggle the direction it faces, a signal is automatically built at the other side. Similarly, if you remove the signal out of a tunnel, the signal into it, if any, is also removed.

Then again, being intended does not mean that it must remain this way. I am open to discussion about any and all features, particularly UI-wise. So if there is a general consensus that another UI for signals in tunnels would be better, I will happily change it (subject to technical limitations, of course).

I downloaded the snapshot tar.gz
Assuming that it is a fork and not a patch, I compiled it with MinGW.
The result is a playable version of OpenTTD and it does all that Cirdan said it should do.
However, the splash screen does not show a version number. Is this normal?

Yes, snapshots do not have any version information.


By the way, on the subject of compilation, the code is known not to compile under MSVC 2008 (9.0?). But, if somebody feels like helping and has access to such a compiler, I would appreciate if they could try a patch that I am carrying around but have not commited yet for lack of testing.

[TrueSatan]

Hey Cirdan,

TrueSatan wrote:
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.

Cirdan wrote:
That should already be possible. Have you tried cycling the signal at the exit of the tunnel? The exit signal can be either a normal signal or a one-way path signal.

Oh really should try it this evening then.

Okay I understand that tunnels are and will be "magic"al wormholes with signals or not
But I vote for signals at the beginning and the end of the tunnel in the right direction.
Currently it feels more like a "random" placement of signals, but only if you use the auto signal tool.
Strangely it works if you place them manually.
But thats my opinion

And tada... I made a windows 32bit version. No ICU support, because it failed with MinGW 32bit.
First cmemory.h was missing in LETypes.h after copying the whole common of ICU into the same directory linking failed...
without iculib it compiled without any problems.
Maybe I missed something, but I did everything like the wiki said.
But thats not the place to discuss that

Hope with providing the win version we have more ppl trying your great patch.

Regards

[Eddi]

But now I wonder if we could store the bridge as a sequence of tiles elsewhere, off-map, and make them full-fledged tiles. This does not mean that everything will be allowed on a bridge, and would not be required for all bridges either, only for those rail bridges that are not a simple long piece of track.

i don't know in how far you followed all the other brainstormings about flexible bridges, but one of the ideas was:
on creating a bridge, reserve a rectangular area (possibly 16x16, or 18x18 with a stretch of void tiles around it, or pherhaps only the smallest rectangular area covering the bridge, except ramps) of map tiles in some off-surface map pool

that means (at least in theory) that you could potentially put all the stuff you want onto such a tile, but you could easily restrict it to rail/road/station/... stuff.

such a change should probably come with a redesigned bridge building GUI (e.g. build bridge sections and bridge ramps separately), and should cover tunnels as well (the idea here was to "slice" the visible terrain at a certain height level, to make the tunnel underneath visible. this could also be used to build stuff under a bridge)

[wallyweb]

Thanks cirdan, TrueSatan and planetmaker.

Finally got TortoiseGit and Git for Windows up and running.
I now see something like a version but mine's a bit shorter than with TrueSatan's.
Probably something I'm doing/notdoing.
Any thoughts or hints?

[Eddi]

you're probably missing something in the toolchain. is "git" in your path?

[TrueSatan]

Hmmm do you get something like "git missing" at the beginning of compiling? had the same problem.
had to restart msys to get it working.
check your path with echo $PATH in msys, then you will see if git is in your path for compiling.

but it is a start you will be there in no time

[wallyweb]

you're probably missing something in the toolchain. is "git" in your path?

check your path with echo $PATH in msys, then you will see if git is in your path for compiling

PATH.png (7.51 KiB) Viewed 2394 times

configure shows this:

Code: Select all

checking revision ... no detection

make shows this:

Code: Select all

.../fttd/findversion.sh: line 90: git: command not found
.../fttd/findversion.sh: line 91: git: command not found
.../fttd/findversion.sh: line 97: git: command not found
.../fttd/findversion.sh: line 100: git: command not found

I have git installed in my Program Files (X86) folder.
I have msysgit installed in C:\
I have MinGW installed in C:\
I noticed that msysgit also has a mingw folder.

The problem persists.

=== EDIT === A PLAN OF ACTION ==========

msys.bat exists in my MinGW folder.
It also exists in my msysgit folder.
In the msysgit folder:
I will make a backup copy of msys.bat as msys.txt
I will then follow the package instalation described here with the exception of Subversion.

Does this sound safe to do?

[TrueSatan]

Looks fine so far wally.
checking with which git i got /c/program files/git/git.exe
guess it was modifying the path var in profile

in my case it was
c:\MinGW\msys\1.0\etc\
edit profile there
edit it that it looks like that

Code: Select all

if [ $MSYSTEM == MINGW32 ]; then
  export PATH=".:/usr/local/bin:/mingw/bin:/bin:[b]/c/program files/git/bin:[/b]$PATH"
else
  export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
fi

the modification is in bold its the path to mingw git. guess there will be an easier way,
but i am to lazy to figure it out now

i wasn't sure if it was that or the restart of msys. but it was that modification.
hope it works for you as well

regards

[wallyweb]

hope it works for you as well

Sadly it did not
but but but but but but but but but BUT!!!!!!!! ...
On Windows7, git installs to Program Files (x86) ...
So now we have:

Code: Select all

if [ $MSYSTEM == MINGW32 ]; then
  export PATH=".:/usr/local/bin:/mingw/bin:/bin:/c/program files (x86)/git/bin:$PATH"
else
  export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
fi

THAT WORKS !!!!

GitSuccess.png (10.24 KiB) Viewed 2350 times

Many thanks for all your help.

Are you up for a little collaboration? You provide the *nix bundles and I do the Win32 ones?
All we need is cirdan's usual heads up when something is ready.

Regards,

Wally

[TrueSatan]

Yeah the virtual machine only has a 32bit version of win7 Thats why.
So its working now wally, gratz

Dunno if anyone wants the linux version anyway. Maybe the Mac-version would
be more interesting.
And I would need to look how I compile a universal binary for linux, not just
for my current Ubuntu/Debian installation.
But its fine with me if you provide the windows version every time Cirdan
makes changes to the patch and/or updates the repository to a higher branch number.


Cirdan thanks for the hint about the one way path signals. It works, but not reliable though.
I had some deadlock on a busy station after using the one way path signal directly at the tunnel
exit. Removing it there putting it back two tiles nearer to the station solved the problem.
Next time I get a deadlock I will provide the savegame and a screenshot

Any news about updating the patch Cirdan? Guess I get banned for asking *lol*
But the patch is sooo nice to play with.

[cirdan]

First of all, thanks TrueSatan and wallyweb for providing binaries.

Okay I understand that tunnels are and will be "magic"al wormholes with signals or not
But I vote for signals at the beginning and the end of the tunnel in the right direction.
Currently it feels more like a "random" placement of signals, but only if you use the auto signal tool.
Strangely it works if you place them manually.
But thats my opinion

I will try to have a look at it, even though the signal autofill code is not something I am fond of.

i don't know in how far you followed all the other brainstormings about flexible bridges,

Where are they, exactly?

but one of the ideas was:
on creating a bridge, reserve a rectangular area (possibly 16x16, or 18x18 with a stretch of void tiles around it, or pherhaps only the smallest rectangular area covering the bridge, except ramps) of map tiles in some off-surface map pool

I am puzzled. Why a rectangular (square?) area to store a row of tiles? I was thinking of a simple array.

such a change should probably come with a redesigned bridge building GUI (e.g. build bridge sections and bridge ramps separately),

This is not a rollercoaster sim. Why would that be required? Conceptually, you first build a bridge, then you build things on the bridge, and the UI should follow this.

Are you up for a little collaboration? You provide the *nix bundles and I do the Win32 ones?
All we need is cirdan's usual heads up when something is ready.

This looks like a compile farm. I will keep you posted on updates.

Dunno if anyone wants the linux version anyway. Maybe the Mac-version would
be more interesting.
And I would need to look how I compile a universal binary for linux, not just
for my current Ubuntu/Debian installation.

That is tricky, because, in a sense, it is very un-unix-like. Any binary you provide will depend on a number of shared libraries, and will only run with the same or a later version of those libraries. Therefore, the older the libraries you compile against, the more compatible your binary becomes. That is easy to do if you restrict yourself to a version of a particular distribution, because they usually ship a fixed version of each library. However, compiling against a version of a library older than the one you have requires some effort, and you would have to do that at least for libc. You could try static linking, but that increases the size of the binary, and it has its own whole set of problems.

Cirdan thanks for the hint about the one way path signals. It works, but not reliable though.
I had some deadlock on a busy station after using the one way path signal directly at the tunnel
exit. Removing it there putting it back two tiles nearer to the station solved the problem.
Next time I get a deadlock I will provide the savegame and a screenshot

Please do. I try hard to fix bugs.

Any news about updating the patch Cirdan? Guess I get banned for asking *lol*
But the patch is sooo nice to play with.

Well, I keep cherry-picking commits from openttd trunk, but I have no immediate plans for new features. I would still like feedback for my patch to select which cargoes to collect at a station (see here for a description), because I think it is a nice thing to have, and I have finally fixed the bug about station window resizing.

[TrueSatan]

Hello Cirdan,

I have compiled the nmf version with your patch and now have some strange problem.
all savegames with version g43b6fbab are shown with Startdate: 5000000.
And as you maybe can guess they are crashing to desktop immediately.
Older versions of my savegames are working fine in g43b6fbabM.
So I muse there was some change in savegame behaviour
not reflected in the collection.diff.
I have added the crash files for you.

I have one thing for the gui you maybe should change.
If you don't have any of those good ate the station it should be grayed out
and not pressable. At least if you set it to automatic.
It a bit confusing that you can press those little buttosn even they only
for example provide mail and passengers, no industry nearby.

And maybe it would be better to click something like "Collected Goods at this station" and get a new window with the full
name of the goods. Those abbreviations are to small on small resolutions.
That way you could use the current full translated textas well, even for something like FIRS, ECS and so on.
Just a thought, dunno how much hassle it is to implent it that way.

Teh patch could be interesting if some server script could access those things.
Or the "buy exclusive transport rights" would be altered in a way that you only can
buy one or more right (but not more then maybe 3 rights)
so get exclusive right for passengers, post and coal but the rest is open for all. Needs a port for the AI then as well

Currently I wouln't use the feature, because I play mainly alone only for building complexe networks
and accumulate money
Sometimes I really would like a reset station like ttd-patch had it as sign-cheat, but then... its cheating and has nothing to do with this patch

Okay my two cents about it. Hope someone else has a different position for a nice discussion.

*lol read your post again... looks like a manual compile farm... With human errors as far as the bits reach...

K, back to the normal nfm (called the other nfmplus )
Like Nelson Muntz would say, smell you l8er

[Eddi]

but one of the ideas was:
on creating a bridge, reserve a rectangular area (possibly 16x16, or 18x18 with a stretch of void tiles around it, or pherhaps only the smallest rectangular area covering the bridge, except ramps) of map tiles in some off-surface map pool

I am puzzled. Why a rectangular (square?) area to store a row of tiles? I was thinking of a simple array.

common requests include wider bridges, switches on bridges, diagonal bridges, ...