Custom Bridgeheads

[ZxBiohazardZx]

like i said, i fail to see why we dont have this feature yet/anymore as its is one of the better ones in my personal opinion, and i dont wanna swap to TTDP just for that XD

I fail to see why you haven't created a patch for it yet then.

so would it be hard to update it over 10k revisions

Yes, as already said it would be more like a rewrite

or did the code change to much?

Yes

and if at all, would any of our main developpers shed some light on what they think of the Custom Bridgeheads at this moment

A nice feature, why did nobody write a (good) patch for it yet?

my coding capability stops @ SQL, aka i suck in cpp, to say the least, it would ruin more then it would fix XD

that on a sidenote, thx for the answers, ill just sit+hope that someone else CAN do cpp and code it

[Rubidium]

Looking back over the posts in this topic, I think there are two reasons this patch wasn't maintained:
1) Its primary maintainer is inactive.

Then your and my opinion on inactive differ, although it is true that the last commit activity of that person was just under a week ago. So yes, he was inactive w.r.t. commits the last five days.

2) The assumption was that the forthcoming new map array would force a rewrite anyway.

Get your assumptions right. The new map array project (i.e. map branch) stranded half a year before the introduction of this thread. There might have been other attempts at a new map array, but they started after the map accessor 'project' which started after this patch was not maintained anymore.

The map array, IIRC, is in development hell now. A number of fundamental things have changed since the initial write, including the C to Cpp migration. I think YAPF was introduced after the fact, or around the same time. I'm playing with the source code now but I'm not that familiar with it. It's (almost certainly) not a quick fix, else someone would have done it by now.

The map array is not hampered by the C->C++ migration; after all, it was just compiling C with the C++ compiler at first. The map array is still very very C-like. Whether or not YAPF was introduced doesn't matter a tiny bit; the pathfinders work mostly via an abstraction layer thus they aren't the main problem. That it's not a quick fix anymore has more to do with the other changes to the code and the assumptions than those two projects you mentioned.

For example the "bridge over anything" feature has broken this patch far further than any of the other things. The introduction of tram tracks probably comes at a steady second place.

Note 1: that there has been a second attempt after the bridge over anything feature was introduced for only cbh for rail, but that stranded because trains broke up when turning around on the bridge; this might be related to signals, but that I'm not sure about.

Note 2: I was not around at the time of this patch, however the subversion history (i.e. the map branch) and a look at the patch tell me quite a lot. I started working on the second map rewrite attempt with a few others (LordOfThePigs, glx, egladil, Belugas) but then Tron took over and finished it in trunk.

[Mackensen]

Fair enough; I wasn't playing around with the code then and I've been trying to dope it out from the SVN history. Also, it was really early here and I got two developers confused in my head.

[Lord Aro]

Bump! i'm sure there isn't , but is there any progress, or anybody thinking of re-starting this?

[planetmaker]

Do you really think that it'll become more likely by bumping this thread? Or that someone speaks up like 'oh, yeah, I totally forgot. I have a working version of it'?

[Lord Aro]

no, just that one of the slightly newer forum-ers that can code and haven't heard of it quite well might like to have a go at it.
or even Peter1138/n

[boekabart]

Do you really think that it'll become more likely by bumping this thread? Or that someone speaks up like 'oh, yeah, I totally forgot. I have a working version of it'?

Definately gets more likely by bumping. Probably just a small, tiny bit more likely though...

[Vaulter]

or anybody thinking of re-starting this?

You ?

[Wolf01]

New forum rule: who bumps a >=1 year old topic asking for a feature must code it

Stupid things apart, with the current stage of development shouldn't it be easier to code due to the various improvements?

[...]

And you, where were you hidden? I'm waiting for your lively rivers and sea-level patches

[Eddi]

most of the infrastructure problems surrounding custom bridgeheads were probably solved in some of the major refactorings of the recent years, but the main problem surfacing in the last attempt still remains: how to make trains obey to signals on the bridgehead? this is mainly a conceptual problem, and in the second phase a developer time constraint problem.

to my knowledge, none of this has been attempted since the last serious discussion about a year ago...

[Gremnon]

This leaves me with the question of are signals on bridgeheads actually used often? Most of the uses of custom bridgeheads I've seen in TTDP is to create a junction closer to the bridge. So is it really a necessary part?

OTOH, if they are to be included, perhaps the patch on signals on tunnels and in bridges can provide some insights?

[Wolf01]

This leaves me with the question of are signals on bridgeheads actually used often?

IMHO no, but the problem is that the bridgehead when changed to a bent (without a junction, just a normal bent) become a standard tile so it can be suitable for a signal.
I tried some approaches with sloped stations and the CBH is the same (at least that's what I tried), the only difference is to allow the editing and replacing of the bridgehead tile which I wasn't able to do.
If we can build a track in an impossible combination (an EOL track facing the slope, but at max tile height, so the track will build a foundation), a train should be able to continue running on the bridge, if the train is aware to be on a bridge tile.

At least with sloped stations this worked well, I was able to build a station on a slope facing the foundation, then placing more tracks the train felt down and continued, the other step was to draw the sloped track and made the train follow the slope instead of the step.
The main problem were the graphics which doesn't suit the sloped station, but with grfs this would be a minor problem.

I think the approach is the same: let the player build a track in an impossible combination ‾\_ -> ‾‾|_ then remove the bridgehead as now, if I remember correctly, a bridgehead is not any more required to tell the train that there starts a bridge, but only to let the train get to the bridge.

[Eddi]

So is it really a necessary part?

yes. certainly.

imagine the following:
A station. next a bridge over a road. then a signal. then a junction.

compared to the current method, you can reduce the space consumption by 2 tiles if you build the station and the signal on the bridgehead!

fact is: if you can't build EVERYTHING that you can also build on a normal rail tile, people WILL complain that "XYZ doesn't work as expected".

[Gremnon]

Alright, so what exactly are the main issues preventing it from working as it stands in current trunk?
As far as I can see, currently the issues are:

-Getting signals to work (Perhaps a look at the patch for allowing signals on tunnels and bridges can help here?)
-Drawing the foundations. Surely the graphics exist for this, it's just a case of explaining to the game how it's done?

Any others? I think if each point is tackled one by one, and the order is decided on, some headway might be made. Just as soon as I can compile again, I plan on looking at the original port and seeing how it worked, and if any of it is still usable, though I'm not holding any hopes up for that happening soon.

[Eddi]

-Getting signals to work (Perhaps a look at the patch for allowing signals on tunnels and bridges can help here?)

i believe that patch is completely useless in that respect, as it doesn't address this at all in a generic manner

-Drawing the foundations. Surely the graphics exist for this, it's just a case of explaining to the game how it's done?

all this stuff was already implemented once or twice, most of that might be able to be salvaged e.g. from the branch.

[Gremnon]

Well, I thought it might have something of use, I was wrong. I've never actually looked into how signals work at all, so I wasn't to know.
In theory then, it looks like all that really needs to be done is to port the original branch to trunk, which could be interesting, and is a little beyond me.

[maquinista]

I like this feature of TTDPatch. There are needed some new foundations for bridges.

[ReisRyos]

I like this feature

[JacobD88]

...There are needed some new foundations for bridges...

OT Question maquinista, on the second screen-shot (needed_foundations2.png) you have a double layer of foundations on the north-south diagonal track next to the station that goes down two levels to the corner of the water edge Is this a by-product of a bug in custom bridgeheads or a separate feature? Building layered foundations like that would be useful

[cmoiromain]

It has nothing to do with custom bridgeheads; the patch simply doesn't know how to draw diagonal foundations like OpenTTD does.