Transport Tycoon Forums

Thank you very much eddi

were did you look to find out this infor

reading and interpreting error messages correctly is one of the most elementary skills of a software developer.
also, checking the revision log for changes related to the suspected error cause, and grepping for the definition of the missing function are obvious (to me) things to do. takes a total of two to ten minutes...

i fort it might have been some thing like that but never thought what one it be and thank you once again and i should learn to look longer for myself befor asking for help or i never learn

At risk of being obnoxious, the word is "thought" not "fort" which is a defensive construction used in warfare... pet peeve of mine, sorry

I getting tired of trying to update this patchs i bringed it from r14563 to now at 16388 dose any one fanice takeing it the rest
hope your like to test it out

The patch is using Road and ship togiver so when there changed all the names i think i cant slove it

Unless it is safe to copy the hole of HandleBrokenRoadVeh in to the ship one but i have not got a clue how i am gonig to do that just yet

If any one wants a win 32 build i am more then happy to make one for you

ERROR

In file included from C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/pbs.cpp:8:
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/yapf/follow_track.hpp: In member function `bool CFollowTrackT<Ttr_type_, T90deg_turns_allowed_, Tmask_reserved_tracks>::Follow(TileIndex, Trackdir)':
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/yapf/follow_track.hpp:108: error: 'const union Vehicle::<anonymous>' has no member named 'road'
make[1]: *** [pbs.o] Error 1
make[1]: Leaving directory `/home/Alainspc/ottdsrc/trunk/objs/release'
make: *** [all] Error 2

UPDATED to R16389 but got stuck with chages in r16390 evern that the patch is no toching them files

I think its src/roadveh.h but i am not 100% i allso changed the code so ships and roac are apart so should be easyer to update

22 downloads but no coments on it or ideas on fixes

Hirundo wrote:Personally I consider this patch finished now. I'm not planning any new features or changes, although I will keep it updated to the trunk and fix any bugs that appear. Therefore I would like to ask to (one of) the devs; what is your opinion on this patch? Is it eligible for trunk inclusion? Does it need changes to functionality, code style or anything else? Answers to some or all of these questions would be very much appreciated.

I would like that one of the developers to answer Hirundo's request for an opinion on inclusion/code-style, etc. It has been nearly one year since his request for it.

By the way where are you Hirundo?

Inclusion isn't based on an "is it finished" - finished isn't the same as "suitable for trunk". The feature needs to add materially to gameplay, not ruin savegame compatability and various other bits and bobs. It also has to do enough to be worth it's code.

Eg a small patch with minor features is much more likely to get in than a large patch with the same feature, the devs don't want to tax people's machines with un-necessary things.

I can't comment on the liklihood for this particular case - simply because I'm not a dev, I know very little about the source code or this patch etc - but there are many reasons why something wouldn't be included; although I'd like to see it myself, that doesn't mean it's right for trunk,

As I said - I would like a developers opinion on the state of the patch, since Hirundo is gone and petern did show some interest in the patch beginning.

*cough* Although I'm not a dev either, I would not trunkify this patch in its current state if I were. It needs quite a lot of work to update and clean it and to split it into parts. Currently I lack the time to do so, leaving this patch in a dormant state.

My update to your patch is that ok to keep there or did you want me to removie it becuse i proble made it dirty in codeing words

Hirundo wrote:*cough* Although I'm not a dev either, I would not trunkify this patch in its current state if I were. It needs quite a lot of work to update and clean it and to split it into parts. Currently I lack the time to do so, leaving this patch in a dormant state.

Here he be!
I see - well - nice of you to clear that out. It's a nice patch idea-wise, so I hope you find time to clean it up.

Merged with trunk r17811.

Hirundo wrote:It needs quite a lot of work to update and clean it and to split it into parts.

You may also want to think about whether you would like to include my "no reliability decrease for stopped trains" patch into your patch, since my patch is a very simple patch. On the other hand, it may also be appropriate for me to include your patch into mine.

very simple patch are easyer to use myself add to much and the patch grows bigger and biger and out of control

Because this patch, in my opinion, make game a bit easier I have modified it a bit. I have added effect of mechanical failure - maximum speed of train is permanently reduced to 50% (more locos in train - less speed reduction). Reduction can be removed by visiting depot.

What do you think guys about my upgrade ?

EDIT: Fixed

There was small bug in last version. Fixed and merged with trunk.

bigos wrote:Because this patch, in my opinion, make game a bit easier I have modified it a bit. I have added effect of mechanical failure - maximum speed of train is permanently reduced to 50% (more locos in train - less speed reduction). Reduction can be removed by visiting depot.

What do you think guys about my upgrade ?

Although I haven't actually tested it yet, I like this idea. In fact, I suggested this feature myself some time ago in this post.

When you implement this, I consider it very important that a train that has once suffered a breakdown with permanent damage should consider itself as scheduled to service inside a depot, even if the scheduled service period has not expired yet. For example, a "service in depot" order should act like a "got to depot" order, in this case. Otherwise, the permanent damage will not get repaired until the scheduled service period expires. Has this already been taken into account by your patch?

I did not want to to make order service in depot because it can realy mess up in your routs. Such order will for example pass the station and will go to depot behind it - if its 1 way station then it will be lost or go to loading station... it can really screw game. For now its like you said. Broken until next service scheduled or forced by you (constructing tracks when train always go to depot). Other way to repair this is to use waypoints. You can create advanced orders list with conditional orders and when for example max speed is lower then half of maximum then go to depot and repair. I think its better way then forcing all trains to repair after mechanical failure. And you will have more fun with using waypoits
What do you think now?