Transport Tycoon Forums

Linux 64 bit version, for those interested.

FooBar wrote:I think the way it is now is just fine. It prevents you from doing stupid things in the first place, but if you really want to, you can still grab the old dynamite in order to get things done. This way it's relatively safe for the inexperienced users

Because inexperienced users don't use the dynamite tool? I think you're a bit confused here.

It was years before I figured what purpose that usually-disabled bulldozer tool served.

DaleStan wrote:

FooBar wrote:I think the way it is now is just fine. It prevents you from doing stupid things in the first place, but if you really want to, you can still grab the old dynamite in order to get things done. This way it's relatively safe for the inexperienced users

Because inexperienced users don't use the dynamite tool? I think you're a bit confused here.

It was years before I figured what purpose that usually-disabled bulldozer tool served.

Good, so I wasn't the only person to take years to learn what the bulldozer was .

DaleStan wrote:It was years before I figured what purpose that usually-disabled bulldozer tool served.

Probably because you didn't RTM

Anyways, you're probably right somewhere, so maybe that 'do you want to continue'-asking dialog isn't too bad after all.

Or forbidding to remove reserved track by default, and only allow it after enabling a patch option.

FooBar wrote: Or forbidding to remove reserved track by default, and only allow it after enabling a patch option.

How about using the magic bulldozer cheat for that? Reversing a train should always free the current reservation, but if YAPP really f*** up some situation the magic bulldozer would help to clean the mess. Can't use cheats in network games though, IIRC, so maybe not the best solution.

-- Michael Lutz

Hello wondering if anyone could help me i have used the patch and compiled it with v0.6.1 of OpenTTD using OTTDbuild. but when i come to look for any of the extra options in the configure patch menu it doesn't exist and does this patch include the PBS Signal GUI or do i get that separately, because that hasn't appeared either.

I am slightly confused by it all to be honest.

FooBar wrote:Probably because you didn't RTM

And, in your experience, users can be trusted to read the manual?

I want your users.

Beardie27 wrote:compiled it with v0.6.1...

You shouldn't compile with 0.6.1, but with r13495. 0.6.1 is far too old to support the current YAPP.

DaleStan wrote:And, in your experience, users can be trusted to read the manual?

Users? No. You? Yes.
But please notice that I've written that "you're probably right somewhere". That somewhere is "users in general".

FooBar wrote:

Beardie27 wrote:compiled it with v0.6.1...

You shouldn't compile with 0.6.1, but with r13495. 0.6.1 is far too old to support the current YAPP.

Right i have compiled it with the lastest trunk and i still don't get the extra options in the "Configure Patches" menu

Latest trunk might be too new for latest YAPP. Try compiling with r13495 (i.e. check 'use revision to match patch' in BOTTD). If it then still doen't work, there's something horribly wrong.

In that case, attach whatever output BOTTD has given you, as that might reveal what may be broken.

Also, sometimes it's useful to flush BuildOTTD's source cache. Just press the 'Purge' button in the interface before compiling. Sometimes that's required if there are major changes in trunk.

Fixed it now, its the link on the first page of this topic that i used to download it, and i get a error were OTTDBuild doesn't like it but it says V8 werid? I donwloaded the from the link on this page instead it works now.

I would have the first page of the topic changed and fix it if i was you.

Beardie27 wrote:I would have the first page of the topic changed and fix it if i was you.

The patch available in the first post is a perfectly valid patch file. It's unfortunate that BuildOTTD doesn't like it, but that doesn't make it any less valid. I do provide an SVN-compatible patch file exactly for this reason.

-- Michael Lutz

ok, but i was just thinking about people who first come on to this topic

Michi_cc: Maybe you should state explicitly, that BuildOTTD users should download SVN compatible patch?

Mchl wrote:Michi_cc: Maybe you should state explicitly, that BuildOTTD users should download SVN compatible patch?

I Think it has already been done now, Ty for that. Just don't want anyone to have the same problem as me.

Anyway just wondering why hasn't this patch been Incorporated into OpenTTD because i think it is one worth having it done.

Ammler wrote: Just for the logs, the assert we had so far:
src/pbs.cpp:137: void UnreserveRailTrack(TileIndex, Track): Assertion `(GetTileTrackStatus(tile, TRANSPORT_RAIL, 0) & TrakToTrackBits(t)) != 0' failed.
2x src/train_cmd.cpp void FreeTrainTrackReservation(const Vehicle*, TileIndex, Trackdir): Assertion `IsFrontEngine(v)' failed.

Having a savegame would certainly help... I especially don't have an idea how you managed to trigger that second assert. First one might be from demolishing some reserved tracks.

-- Michael Lutz

Beardie27 wrote: Anyway just wondering why hasn't this patch been Incorporated into OpenTTD because i think it is one worth having it done.

Developers seem to have mixed feelings about it. They're thinking about it, but haven't made a decision yet (neither positive nor negative).

(At least that is what I know about the matter. I am in no way dev team's representative)

Mchl wrote:
Developers seem to have mixed feelings about it. They're thinking about it, but haven't made a decision yet (neither positive nor negative).

Well i would like to see it done, but were going to have to wait.

Mchl wrote:

Beardie27 wrote: Anyway just wondering why hasn't this patch been Incorporated into OpenTTD because i think it is one worth having it done.

Developers seem to have mixed feelings about it. They're thinking about it, but haven't made a decision yet (neither positive nor negative).

(At least that is what I know about the matter. I am in no way dev team's representative)

I'm not really sure what the negatives are of including it in trunk to be honest. It's not like it's an option that you HAVE to use, you can still use the regular old signals if you so please.

I think it would be a great idea if it was put in the trunk.

phil88 wrote:I'm not really sure what the negatives are of including it in trunk to be honest. It's not like it's an option that you HAVE to use, you can still use the regular old signals if you so please.

One is using 10+% more CPU than a build without YAPP on a map with lots of trains that do not use YAPP signals. Progress is great, but does it warrant making OpenTTD run that much slower when you don't use the signals?

Another thing is the desync issue that some people mention. My current hypothesis is that this is a cache mismatch in YAPF between the client and the server. I haven't had the time to actually look into that though.