Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Thu Nov 15, 2018 9:26 am

All times are UTC




Post new topic  Reply to topic  [ 205 posts ]  Go to page Previous 17 8 9 10 11 Next
Author Message
PostPosted: Sat Jun 09, 2018 1:26 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sun Jun 20, 2010 11:16 pm
Posts: 1254
i ve been silent since that patch came out but watched with interest, and i haven t tested it yet, so yes my comment won t be constructive at all, sorry for that :
- my mouth is watering since patch came out !

thanks for all the effort ! Now i return to silence


Top
   
PostPosted: Sat Jun 09, 2018 6:16 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Mar 31, 2007 2:23 pm
Posts: 4707
Location: Lost in Music
Karn wrote:
Maybe all we need is the current depot check and as a bonus check, if length of vehicle(s) changed. (Or capacity too, if any NewGRF does it without changing length)

Place to start looking is probably cb36 https://newgrf-specs.tt-wiki.net/wiki/C ... s_.2836.29
There are a few other callbacks too that change properties and/or need cache re-rolled (10, 11, 12 etc)

I'm wrong person to trust on this, but afaik changing certain properties can cause:
- game crashes
- network desyncs
- invalid cache
- behaviour that's hard to explain and confuses player

TL;DR it's an interesting patch, if limiting some newgrf behaviour is needed, might be worth doing :)

Probably easier discussed in :wink: irc https://wiki.openttd.org/IRC_channel

_________________
FIRS Industry Replacement Set (Released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (Finished)
Squid Ate FISH (ships) (Released) | CHIPS Has Improved Players' Stations (Finished)
Iron Horse (trains, released) | Termite (tracks for Iron Horse, released) | Busy Bee (game script, released)

Road Hog (road vehicles, released)


Top
   
PostPosted: Sat Jun 09, 2018 7:02 am 
Offline
Tycoon
Tycoon

Joined: Wed Apr 27, 2005 7:09 am
Posts: 5237
Changing length by CB (36) should be rather rare, in contrast to capacity change. I´ve done a quick look in DBXL, and there are 55 occurencies of capacity changes (by CB 36):

- using same passenger cars over different generations (remodeling)
- having/refitting passenger cars for differing comfort levels (cargo aging)
- freight cars with fixed volume but different loading weights for cargoes based on stowing factors

None of them depending on the engine, but rather on date/age, on refit cycle (var F2), or on cargo type.

regards
Michael

_________________
Image


Top
   
PostPosted: Sat Jun 09, 2018 8:19 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
Seems OpenTTD already counts with those problems. We got ConsistChanged() method and ValidateTrains(). They both deal with cache and check everything needed. They handle decoupling in depot, which is same thing except the vehicle length change, which doesn't need to be forbidden in depot. But we even have flags for that for ConsistChanged().

I think only issue is vehicle length that needs to be checked. Capacity shouldn't matter, as it is allowed to change both in depot and during autorefit.

So using depot's ValidateTrains() and checking CB 36 and 11 for length change should be enough, otherwise only graphical glitch is possible with weird NewGRF.


Top
   
PostPosted: Sat Jun 09, 2018 3:44 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1194
michael blunck wrote:
Changing length by CB (36) should be rather rare, in contrast to capacity change. I´ve done a quick look in DBXL, and there are 55 occurencies of capacity changes (by CB 36):

- using same passenger cars over different generations (remodeling)
- having/refitting passenger cars for differing comfort levels (cargo aging)
- freight cars with fixed volume but different loading weights for cargoes based on stowing factors

None of them depending on the engine, but rather on date/age, on refit cycle (var F2), or on cargo type.

I also use CB36 a lot. I change wagon length according to the leading engine in order to have multiple version of the same vehicle type without cluttering the purchase list; I also do it for the user's convenience.

One case is for railcar trailers; I've got different types, each matching to a specific railcar model. Of course, each trailer type has its own length. I think it's more convenient for the player to have one generic slot for "Railcar Trailer" in the purchase list, which can automatically adapt to the railcar it's attached to, rather than having to choose among 5 or 6 different types of trailers, each of which can be attached only to certain engines?
Another case is for mail wagons, all of which share the same ID and automatically match the style of the passenger coaches in the consist: I do this by checking the engine. Again, would you rather have multiple IDs for mail wagons, so that every time you'd have to choose the matching type to add to the consist? :roll:


Top
   
PostPosted: Sat Jun 09, 2018 3:59 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Mar 31, 2007 2:23 pm
Posts: 4707
Location: Lost in Music
Snail wrote:
Again, would you rather have multiple IDs for mail wagons, so that every time you'd have to choose the matching type to add to the consist? :roll:

It's not really a critique of your newgrf design choice Snail ;) . The better question is, how would you support this behaviour with shunting, given that vehicle length absolutely *cannot* change outside a depot?

_________________
FIRS Industry Replacement Set (Released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (Finished)
Squid Ate FISH (ships) (Released) | CHIPS Has Improved Players' Stations (Finished)
Iron Horse (trains, released) | Termite (tracks for Iron Horse, released) | Busy Bee (game script, released)

Road Hog (road vehicles, released)


Top
   
PostPosted: Sat Jun 09, 2018 6:02 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 7198
an alternative to the manual "detach" nodes to be set by the players would be that upon shunting, the vehicle gets a "shadow" link to the original vehicle that it left the depot with. with that, it could be ensured that the callbacks always refer to the same vehicle, but it may cause issues if the vehicles are sold separately

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Sat Jun 09, 2018 7:20 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1194
andythenorth wrote:
It's not really a critique of your newgrf design choice Snail ;)

No offense taken, we just have totally opposite ideas. You don't mind having a long purchase list, while I find it fine to use CB36 to change a vehicle's properties.
The fact we think each other's approach is silly is irrelevant :D we just need to find a solution for both.

Eddi wrote:
an alternative to the manual "detach" nodes to be set by the players would be that upon shunting, the vehicle gets a "shadow" link to the original vehicle that it left the depot with. with that, it could be ensured that the callbacks always refer to the same vehicle


I think this would be a very good solution indeed.

I would actually propose something similar, but maybe with a wider scope: it would be great if we had a function that not only returns the engine a wagon is currently attached to (as we have now), but also the engine it left the depot with, i.e. some sort of "original" engine. Such information could be cached and updated each single time the wagon leaves a depot.
Then, upon shunting, we would check the ID of the new shunting engine, and only allow shunting if the latter is compatible with the "original" engine.
This would solve most compatibility problems I can think about...


Top
   
PostPosted: Sat Jun 09, 2018 11:42 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 7198
Snail wrote:
it would be great if we had a function that not only returns the engine a wagon is currently attached to (as we have now), but also the engine it left the depot with, i.e. some sort of "original" engine. Such information could be cached and updated each single time the wagon leaves a depot.

that needs some addition to the NewGRF system where a vehicle can have multiple "PARENT" references. i think frosch had a proposal about that a few years back.

anyway, during a discussion on IRC, a proposition came up:
during a shunting operation, the following 3 checks are made:
  1. CB36 and all related callbacks are run, and if "dangerous" changes (like length) occur, the shunting operation is forbidden
  2. the wagon-attach-callback is run as if it were in a depot, and if it fails, the shunting operation is forbidden
  3. if the engine uses wagon overrride, the shunting operation is forbidden
if the shunting operation is forbidden, the order fails, everything is reset to the original state, and the player gets a message about invalid orders. then the next order is executed.

this should catch all the worst cases, without outright forbidding shunting on all existing NewGRFs. then, some advanced tools might be needed for NewGRF authors to affect the way shunting works (like disallowing shunting in the middle of an EMU), which can be used to improve future NewGRFs

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Sun Jun 10, 2018 1:14 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1194
Eddi wrote:
that needs some addition to the NewGRF system where a vehicle can have multiple "PARENT" references. i think frosch had a proposal about that a few years back.

Yep, that would be quite helpful...

Eddi wrote:
if the engine uses wagon overrride, the shunting operation is forbidden

There's more to it than wagon override... Recoloring and graphics can also be changed according to the leading engine. I think we should check for them as well.


Top
   
PostPosted: Sun Jun 10, 2018 1:47 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 7198
Snail wrote:
Recoloring and graphics can also be changed according to the leading engine. I think we should check for them as well.

yes, but it's not really game-breaking, so we could live with old GRFs being slightly wonky in this case. New GRFs should get the proper tools to specifically deny shunting if they want to rely on such things

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Sun Jun 10, 2018 3:04 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
There were some unexpected crashing bugs in 0.3. They should be gone now. I'm not aware of any game crashes atm.
I made something about NewGRF decoupling, it shouldn't corrupt game now.
Here is 0.4

Edit: binaries are in development thread


Last edited by Karn on Thu Jun 14, 2018 2:00 pm, edited 1 time in total.

Top
   
PostPosted: Sun Jun 10, 2018 3:54 pm 
Offline
Tycoon
Tycoon

Joined: Wed Apr 27, 2005 7:09 am
Posts: 5237
Eddi wrote:
if the engine uses wagon over[r]ride, the shunting operation is forbidden

Why should it? To avoid "unpleasant" livery changes? Or to safely reset property modifications?

Apart from simply changing the looks of wagons when being attached to certain engines, IMO the more important feature of "wagon override" is ignoring or resetting speed limits for trains (i.e. its locomotive) imposed by attached wagons.

E.g.,

Code:
makevehicle(_E19,
   link(ref(6), MENU)
   default(ref(8))
   override(_PDISTLONG, ref(F_AUM))    // passenger long-dist LONG
   override(_PDIST, ref(F_))       // remove speed limit of 140 km/h
   override(_MDIST, ref(FP_))      // remove speed limit of 120 km/h
   override(_SPW, ref(SPW_))       // remove speed limit of 140 km/h
)

resets speed limits imposed on the E19 locomotive by certain long-distance coaches, mail vans, and dining-cars in a much more flexible and code-efficient way than doing the same thing explicitly by running CB36 for each of said coaches/vans/cars (and for different engines).

IMO, performing a shunting operation on such a train shouldn´t do any harm, rather than reset the original speed limiting effect for decoupled wagons when being attached to a different engine.

regards
Michael

_________________
Image


Top
   
PostPosted: Mon Jun 11, 2018 11:05 am 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 7198
the issue i have with "wagon override" is that it has too many side effects.

anyway, one thing that is probably going to cause trouble for shunting is "powered wagons"

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Mon Jun 11, 2018 11:52 am 
Offline
Tycoon
Tycoon

Joined: Wed Apr 27, 2005 7:09 am
Posts: 5237
Eddi wrote:
[...] one thing that is probably going to cause trouble for shunting is "powered wagons"

IIRC, I´ve never used that feature (MUs can be better modeled by articulated vehicles). Would be interesting to see which train sets are using it.

regards
Michael

_________________
Image


Top
   
PostPosted: Mon Jun 11, 2018 12:11 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Jan 18, 2014 6:10 pm
Posts: 1083
Maybe this patch should provide settings, if livery override is accepted for shunting or not?

_________________
My experimental openTTD server: 149.156.194.203:3979 non-standard client, now testing: JGRPP http://tiny.pl/ggnch
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension.
Addicted to freeciv longturn.


Top
   
PostPosted: Mon Jun 11, 2018 1:47 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
I don't see point in wasting programming time on limiting anything. As long, as the game doesn't corrupt, there are no more limits needed. We have restrictive limits that apply in the depot. Same limits apply outside the depot, so I don't see point in making new special rules that adds nothing to gameplay or overall fun. Why is red box that tells user that he can't do something requested so much?


Top
   
PostPosted: Mon Jun 11, 2018 1:58 pm 
Offline
Transport Coordinator
Transport Coordinator
User avatar

Joined: Wed Jan 08, 2003 11:09 pm
Posts: 381
Location: Denmark
So perhaps instead, when a train attempts to couple to a different one, if any callbacks result in a risky/impossible change (e.g. wagon length) then just reject the coupling and cancel the order?
It will probably give strange-looking results that a bunch of cars suddenly change design but at least it shouldn't entirely prevent players from using any existing NewGRF.


Top
   
PostPosted: Mon Jun 11, 2018 2:05 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
That's already implemented. I'm not sure if without bugs. Some testing would be nice to see, if weird results are possible.


Top
   
PostPosted: Mon Jun 11, 2018 4:58 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Nov 03, 2017 6:57 pm
Posts: 1619
Location: Courbevoie, near Paris, France
Honestly Karn, yet you're almost doing a revolution in OpenTTD with your patch. When people want, they have. ;)

_________________
NewGRFs by Tony Pixel :
North American Passenger Railroads
Not Enough Subways


My screenshots


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 205 posts ]  Go to page Previous 17 8 9 10 11 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.