Transport Tycoon Forums

Rubidium wrote:

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.

You telling me that OpenTTD uses a lot of CPU, because i didn't think it did and if it doesn't 10% more percent CPU usage is not A LOT.

I don't really know if that effects gameplay and peoples computers, but you would think it wouldn't.

Beardie27 wrote:You telling me that OpenTTD uses a lot of CPU, because i didn't think it did and if it doesn't 10% more percent CPU usage is not A LOT.

Tell that to the people complaining on an almost daily basis that they can't connect to some server because they are 'too slow'. There are furthermore many savegames that do not run smoothly on my computer and adding another 10% extra CPU usages makes both groups grow.

And 10% CPU is actually an awful lot more CPU wastage with respect to any other feature that is not used.

Why is the CPU usage so high if you don't use the signals? Would disallowing YAPP in a patch setting stop it? That way the YAPP stuff is only loaded and used iff the user wants it, if the user doesn't want it, then only the code that we have at the moment is used. Or are the changes to the code to spread out to simply turn it on/off.

Beardie27 wrote:You telling me that OpenTTD uses a lot of CPU, because i didn't think it did and if it doesn't 10% more percent CPU usage is not A LOT.

We have regularily games on our server which cannot be joined anymore by people who don't have the latest gaming hardware, e.g. a processor with very fast cores (only the speed of one core matters!). Try out a map with 1000 trains - it fills one core of a 2GHz core2duo easily. An additional 10+% would make even looking at that game impossible.

So I agree with Rubidium that speed is definitely an issue - especially, if a patch affects the speed, even if it is not in use.

We're playing for some time on the openttdcoop PS with this nice patch now and we had a few crashes (the server exited).
I'm posting a screenshot and a savegame, where train 67 meets a green PBS signal that should be red and crashes into another train (marked by the red circle). This situation made the server exit, on single player the train crash just happens without a game crash.
When loading the autosave from half a minute before the crash, it does not happen. I hope that helps.

PS: the assert was:
...ottd/yapp/src/train_cmd.cpp void FreeTrainTrackReservation(const Vehicle*, TileIndex, Trackdir): Assertion `IsFrontEngine(v)' failed.
You need the ottdc_grfpack for this save from http://www.openttdcoop.org/wiki/GRF.

Regards YAPP, and knowing that there's now a system for a train to create a path for itself, how possible would it be to allow two trains to pass signals into a single platform, as long as there was enough track for it to safely enter the station? Having seen the system work, trains won't move until they can reserve a free path, so surely the problems of train crashes can be avoided?

Obviously we have the problem of trains becoming deadlocked against each other, but players can create waypoints to stop that occurring. Increases station capacity and reduces the amount of platforms required.

For a real life example of platforms used by two trains, see Birmingham New Street.

Dave Worley wrote:Regards YAPP, and knowing that there's now a system for a train to create a path for itself, how possible would it be to allow two trains to pass signals into a single platform, as long as there was enough track for it to safely enter the station? Having seen the system work, trains won't move until they can reserve a free path, so surely the problems of train crashes can be avoided?

Obviously we have the problem of trains becoming deadlocked against each other, but players can create waypoints to stop that occurring. Increases station capacity and reduces the amount of platforms required.

For a real life example of platforms used by two trains, see Birmingham New Street.

while i'd really like to see that feature, i'd say this is beyond the scope of this patch

this patch should get feature locked and focused on getting into trunk

usage of partial platforms is more of a shunting operation and should get in a separate patch [probably building upon YAPP reservations], but there are more problems involved than just "reserve half a platform"

Dave Worley wrote:how possible would it be to allow two trains to pass signals into a single platform, as long as there was enough track for it to safely enter the station? [...] Increases station capacity and reduces the amount of platforms required.

Something like this can be easily done w/o PBS/YAPP by using non-track tiles like this:
regards
Michael

I believe that he wants to make it possible for two trains to enter the same platform from two side, but also to just drive through the station. With your layout this is not possible. Or else you need two different types of platforms but it makes the whole station more complicated.

Dave Worley's idea could be done IMO if each tile of the station was considered as a block, except the trains would enter any free tile even if the remaining space is too sort for it to fit, blocking the station entrance and creating a jam...

cmoiromain wrote:I believe that he wants to make it possible for two trains to enter the same platform from two side, but also to just drive through the station. With your layout this is not possible. Or else you need two different types of platforms but it makes the whole station more complicated.

Dave Worley's idea could be done IMO if each tile of the station was considered as a block, except the trains would enter any free tile even if the remaining space is too sort for it to fit, blocking the station entrance and creating a jam...

I was under the impression that under YAPP the train knew it's length? Or maybe not, I don't know.

But yes, you're right - there are so many terminii platforms required that a station that might usually be a four platform station becomes a ten platform one, and so on.

EDIT: That said, if you had a "standard length" of trains, you could easily make sure that stations were twice as big as that, or you could have waypoints to dictate where certain length trains should go - you can order longer trains through one waypoint/station, and shorter trains through the other.

Rubidium wrote:

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?

and if noAI consume 10% CPU more, will you refuse to merge it into the trunk ? I think no, and it's ok for me (I guess it will use more than 10% btw)
people want faster playing ? ok, lets them begin to use smaller map first ? no ?

if paying 10% for having this great feature that a lot of us are waiting for, for me it's ok.

fabca2 wrote:

Rubidium wrote:

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?

and if noAI consume 10% CPU more, will you refuse to merge it into the trunk ? I think no, and it's ok for me (I guess it will use more than 10% btw)
people want faster playing ? ok, lets them begin to use smaller map first ? no ?

if paying 10% for having this great feature that a lot of us are waiting for, for me it's ok.

Ofcourse with some advanced AIs NoAI will consume more CPU, but the big difference is that NoAI won't take any CPU as long as you don't start an AI. Apparently this patch does. And *that* is a big disadvantage.

fabca2 wrote:and if noAI consume 10% CPU more, will you refuse to merge it into the trunk ? I think no, and it's ok for me (I guess it will use more than 10% btw)
people want faster playing ? ok, lets them begin to use smaller map first ? no ?

If NoAI without running any AIs consumes 10% more CPU than trunk without AIs NoAI will not be merged.

I don't care if YAPP takes 1000% more CPU when you start actually using YAPP, i.e. building YAPP signals. My main problem is that the YAPP patch introduces 10% more CPU when the signals are not used.

It's like paying 10% more for cellular bill when the cellular company starts implementing a new network with more features (4G?), even when you do not intend to use the features. When someone else wants to use those new features and has to pay 50% more I don't care, as long as I don't have to pay 10% extra when I do not use it.

What if YAPP was YAPO (Yet Another Patch Option )? Would it still consume CPU time while deactivated? Though I don't know if it is so simple to actually make it an option, since it changes quite much of existing code, doesn't it?

_Robbie_ wrote:What if YAPP was YAPO (Yet Another Patch Option )? Would it still consume CPU time while deactivated?

Yes. Every time YAPP code might be executed, you'd first have to check whether or not YAPP is on and that check would consume CPU time.

one check is probably less than all the checks yapp has to perform though... Or maybe the check could be done once, at the beginning, and depending on the result it either sends to the code that does normal signals or to the part that does the yapp code. But I don't know how the patch and the game work internally, so maybe my vision of things is a little utopic...

And isn't there already 3(?) pathfinders to choose from, they already must have handled these somehow.

Seems like trains unreserve paths they are still running (rather waiting) on them. See the attached savegame.

Small glitch:

YukonRob wrote:And isn't there already 3(?) pathfinders to choose from, they already must have handled these somehow.

yes, but yapp extends two of those to handle path reservations.

and DaleStan is right: yapp code is all around in them (and some other places) in little snippets, so making a patch option could actually make things worse.
also yapp extends gameplay by introdoucing new signals (which you don't use if you don't want to), and does not modify it, so a making it an option is rather pointless imho.

i hope Michi_cc can find and optimise the bottlenecks in the code to elimiate that pesky 10% (which is a lot) this maybe the hard, but i'm sure he's got some ideas