Page 1 of 1

Usual depot connections not built on enh tunnels

Posted: 04 Apr 2007 04:05
by DaleStan
Yes. Dale is, yet again, putting on his "nitpick the one tiny problem with the otherwise outstanding feature" hat.

When building a depot facing an enhanced tunnel top (scr1), the connections that would usually be built with such a depot (scr2) are not. Was this oversight, or just TMWFTLB?

(OT: I'm surprised. That acronym doesn't seem to have escaped TT-F.)

Posted: 04 Apr 2007 05:24
by JGR
(OT: I'm surprised. That acronym doesn't seem to have escaped TT-F.)
It has escaped me, what on Earth are you on about: TMWFTLB?

I'll add it to my list of bugs to fix (it's getting longer), but don't be surprised if I fix the more glaring issues first (routing whilst leaving the tile, maglev tracks, the trace restriction cargo issue and the crashing road vehicle lists) :(

Thanks for pointing it out.

JGR

Posted: 04 Apr 2007 06:47
by PikkaBird
JGR wrote:TMWFTLB?
Too Much Work For Too Little Benefit.

Posted: 04 Apr 2007 07:10
by Pookey
PikkaBird wrote:
JGR wrote:TMWFTLB?
Too Much Work For Too Little Benefit.
Well, i've never heard of it either until now :( , your not alone JGR.

Posted: 04 Apr 2007 08:16
by eis_os
JGR: I hope you test your code with all possible length of vehicles. (short engines and combined ones) My code that tells vehicles not to jump may not work correctly. A train may be one pixel off after visiting complicate tiles, or jump below for one frame an so may crash with a train that enters/exits a tunnel. The code responsible for that is in the higherbridges system, and has serious flaws and was hacked together in a debugger. So please test this. It can create subtile crashes, like train consists get decoupled. (This doesn't mean the edges, but the time the vehicle virtually floats in the air)

You got warned and when you are done, please tell me your bitusage via email so I can fix my landscape doc, thanks... Nice additions to enhancetunnels. :wink:

PS: Can you really fix the pathfinder? - Ohh the crash isn't only the road vehicle lists, all lists behave bad. People reported problems with empty/broken train lists aswell...

Posted: 04 Apr 2007 13:19
by Vloris
PikkaBird wrote:
JGR wrote:TMWFTLB?
Too Much Work For Too Little Benefit.
That sounds much more polite than what I had in mind:

Too Much Work For The Lazy b****** :oops:

Posted: 04 Apr 2007 13:26
by m3henry
i think basetunnels will have to be redrawn for this new feature now

Posted: 04 Apr 2007 17:02
by JGR
Oskar: I encountered lots of train decoupling bugs before I fixed the PBS system.
Since then, I've tested it using my game, where train length varies between 14 and 28 carriages, and there are no obvious bugs (train decoupling/train crash) that I can see.
PS: Can you really fix the pathfinder?
Define "fix". I my opinion, the whole pathfinding system is crying out for a total rewrite, but I'm not going to do it (or at least not any time soon). I can certainly hack it using questionable programming practices and lots of exception cases.
I noticed that Rob has found a PBS bug so I will look into that, that may provide some clues.
As for the vehicle lists, it only occurs when win2k is off, and as I can't run TTD with win2k off, this makes debugging difficult.
At the moment I am looking at the trace restriction cargo issue...

DaleStan: I think this qualifies as a "TMWFTLB". Note that this doesn't work with custom bridge heads either.

m3henry: The basetunnel sprites seem to look OK to me (but then I'm very tolerant of shoddy graphics). If someone wouldn't mind drawing/trimming some suitable maglev track sprites, I can slip them in. (Or if nobody uses maglev track, don't bother :) )

JGR[/quote]

Posted: 04 Apr 2007 20:05
by DaleStan
JGR wrote:Since then, I've tested it using my game, where train length varies between 14 and 28 carriages, and there are no obvious bugs (train decoupling/train crash) that I can see.
I think Oskar is concerned about vehicle length, not train length. Specifically, shorter rail vehicles.
JGR wrote:As for the vehicle lists, it only occurs when win2k is off, and as I can't run TTD with win2k off, this makes debugging difficult.
Idea: I've had success running the DOS version under DOSBox. I don't know if DOS has the same crash, and I've never tried to debug with DOSBox, though. But this might be a solution.
JGR wrote:DaleStan: I think this qualifies as a "TMWFTLB". Note that this doesn't work with custom bridge heads either.
I wonder how I failed to notice that detail. I may look into it myself. Someday. ... Or maybe today.
/me adds another thing to his todo.

Posted: 05 Apr 2007 03:22
by DaleStan
DaleStan wrote:Or maybe today.
As it turned out, today it is. custombridgeheads were easier than I expected. Tunnels are another matter. Can you confirm these meanings for bits 4..6 of L7 on a tunnel-bridge, JGR?

6: Set if horizontal piece present over SE-entrances[0] (!), set if vertical piece present over other entrances
5: Set if vertical piece present over SE-entrances[0] (!), set if horizontal piece present over other entrances
4: Clear if perpendicular piece present

I've got memory dumps that seem to support this, so mostly I want to make sure that this is what you meant and that it isn't going to suddenly change on me.

[0] (L5 & 3) is 0.

Posted: 05 Apr 2007 07:54
by eis_os
Well JGR send me an detail update to my landscape doc which has these described aswell... (follow www link, projects, ttdpatch, docs) Current Version is 0.9

enhtnlconvtbl should be helpfull aswell...

Yes, I mean shorter rail vehicles, they sometimes really don't do what you expect. Actually thinking again about my higherbridges code, it should be generally work good. It does check the z difference, if the z difference is to much, it makes the vehicle(engine, wagon, bus... ) fly...

Btw. did you tested vehicles aswell without any orders if they work right?

Posted: 05 Apr 2007 08:56
by JGR
DaleStan: To get the L7 bit from the route direction bit for diagonal tracks, use the "calctrnum" function on line 403 of tunbridg.asm, and then add 4.
To get the route bit from the L7 bit use the enhconvtbl table as Oskar suggested.
Route bit value = tunnel direction << 2 + bit number (0 is perpendicular, 3 is parrallel, through tunnel).
Add sixteen to table offset to get route bit index instead.
I would suggest that you simply OR together the route bit values for the enhanced tunnel directions set, and pass that route map to the existing code.

Oskar: I've tested with shorter rail vehicles and with no orders, I found no problems.

JGR

Posted: 05 Apr 2007 16:48
by DaleStan
eis_os wrote:Well JGR send me an detail update to my landscape doc which has these described aswell... (follow www link, projects, ttdpatch, docs) Current Version is 0.9
Yes, I saw that, hence the reason I knew to use those three bits. But the description "track bits" is not particularly helpful when actually interpreting them.

EDIT: Never mind. I somehow missed the useful table that immediately follows that description.