[WIP] Trails

[cmoiromain]

well, since this is just eye candy, other people could draw other graphics and replace the grf the patch will be based on (andythenorth's one).

[lead@inbox]

Roujin, please, continue develop nice idea

[andythenorth]

This topic is dedicated for my patch that adds a third road type, a kind of dirt road only to be used by heavy trucks and maybe horse carriages. The idea came from andythenorth in this thread: http://www.tt-forums.net/viewtopic.php?f=32&t=37964

FYI, I've talked to Rubidium about the topic of new road types, and new road types won't be added in trunk until a rewrite of the system is done. So this will stay a patch of its own for now, with (sadly) only eyecandy-purposes

Zephyris has released a grf for futuristic urban monorails http://www.tt-forums.net/viewtopic.php?f=26&t=38413
That adds another dimension to the debate about more road types no?

[Roujin]

Well, it does look very nice

However with the current system we are too limited.
As I said Rubidium pointed out that some rewrite is needed before anything like a third road type (be it trails, or something like these urban suspended monorails) can hit trunk.

Currently, all three road types are combinable in any way. The rewrite that Rubidium had in mind would mean that then, only one road is freely combinable with one tram. The bits freed by this assumption are used to determine which road type and which tram type we have on that tile.
This would allow for more different types of roads and trams, but only one road type and one tram type on a given tile (which kinda makes sense though).

Well, I'd say go poke Rubidium to do this system rewrite , now that we have graphics for an additional road type and an additional tram type ^_^

btw. I'm not dead, just nearing exam time and got no time right now for patches and the like

[Zephyris]

I would support a full newGRF system for defining roadtype/tramway behaviour to make them fully user definable and flexible. I understand this is a very big project but could work very well. This would have to include some kind of method (bitmask of road type IDs) to define the permitted interaction between building different roadtypes (ie. normal road and tramways could be built over the same square but tramways and suspended monorails could not) and vehicles and road types (ie. like steam trams could travel over electrified and normal tramways but electrified trams could only travel over electrified tramways). It would probably also be simplest to have shared catenarys (eg. between tram and trollybuses)...

Ramble over; but I would love to have GRF definable road/rail types...

[Roujin]

Okay, here I am again.
Half of my tests for this semester are done, and it's still 6 days until the next one, so I thought I'd spend this day with some OpenTTD patching

Unfortunately, I was updating and working on an older version of this first, that hadn't the latest changes (snow- and desert awareness), without noticing it. Luckily, I was able to merge it together again
Now I've got it updated to current trunk and it uses the extra graphics for snow and desert.
A bug concerning articulated vehicles was exterminated (luckily I had Zephyris' awesome eGRVTS activated while testing, thus I noticed it ).
I've also rearranged your sprites, andythenorth (or, let grfcodec do it).
Here's the file:

trails.pcx

(45.19 KiB) Downloaded 132 times

Here are some screenshots:

trails_v0.2_desert.png (35.22 KiB) Viewed 4662 times

trails_v0.2_snow.png (43.08 KiB) Viewed 4658 times

ToDo:
- Stations (drivethrough for the time being, reusing the sprites from road, as tram does)
- forbid trail & road on same roadbit; make roads "overwrite" trails. (also forbid tram&trail?)
- fix some bugs with one way roads
- (maybe/far away) GRF definable if a road vehicle is able to go on trails
(currently, every vehicle that goes on roads is also allowed to go on trails)


I think that I should do the first two points on that list, before making a release.

[Roujin]

Here's another screenshot, showing the trails "in action"... or maybe rather showing Zephyris' awesome Horse Carriages from the eGRVTS in action?

trails_v0.2_carriages.png (79.51 KiB) Viewed 4663 times

edit: Oh and one thing about grf configurability... unlike previous things I've done (trafficlights), the sprites here will be combined into openttd(w).grf, defined as Action5 type16 (except the autotrail image & cursor, these are in openttdgui, like the other auto*-tools). So a newgrf could easily replace them to something else. Only problem would imo be to change the strings with "trails" (as some dev stated, strings in OpenTTD generally are replaceable, but there's no guarantee on their position, it might change inbetween versions).

[andythenorth]

Here's another screenshot, showing the trails "in action"... or maybe rather showing Zephyris' awesome Horse Carriages from the eGRVTS in action?

Looking good Roujin, thanks for doing this. Guess I'll have to figure out how to build OTTD on Mac OS X when you release the patch (That, and learn grf codec for the Heavy Equipment set).

cheers,

Andy

[Roujin]

Oh yes you should there are some good wiki articles about compiling here

I've done stations (drive-through only) now. As a bonus, I've made them (and tram stations) desert/snow aware (beforehand they would just have asphalted ground always), so now you can have a stop in the middle of the desert at a cheap dirt road, without it being suddenly asphalted. Road drivethrough stations still have asphalted ground.
Here are three new screenshots.

Grain is transported with horse carriages on a little trail from Narnville Farm...

trails_v0.3_cargo_1.png (71.3 KiB) Viewed 4357 times

... to Bendbourne Factory.

trails_v0.3_cargo_2.png (53.67 KiB) Viewed 4368 times

Only a little trail connects the two villages of Bundingworth Falls and Linnwell, providing them with a passenger horse carriage service.

trails_v0.3_passengers.png (130.21 KiB) Viewed 1140 times

Next on my list is the restriction for not having trails&road on the same roadbit.
Still not sure what to do about trams though. Any suggestions?

First of all, it could just be allowed (despite being hardly visible if the tram tracks are drawn over the trails).
If not, more questions are coming up:
What if I build trail over tram? Should it say "Error: tram tracks in the way"? Or should it automatically build road instead?
What if I build tram over trail? Should it say "Error: trail in the way"? Should it automatically replace the trail with road (for a cost) and then build tram over it?

Should I be able to overbuild a trail of another company with road? (Guess no, as I could then just delete it...)

[ostlandr]

Great work!

I think road should overwrite trail, since anyone can use roads. Now, what happens if you try to build road over a competitor's station on a trail? Could it be coded to simply upgrade that tile to road, but keep it owned by the competition? This would work if you want to upgrade a competitor's trails to roads- if you want to hand them the upgrade, go ahead, but you don't own the road.

Agreed that there should be restrictions on which vehicles can operate on trails. Smaller vehicles should be able to operate on trails, but not faster/articulated vehicles. Maybe a livery refit would allow vehicles such as tractor-trailers to operate on trails, but at a reduced speed (Ice Road Trucking, anyone? )
Allowing any vehicle that can operate on a trail to operate on road sounds simpler to implement. Theoretically, you could drive a mining truck on the interstate (mind the overhead if it's over 13' 6' high).

[andythenorth]

Agreed that there should be restrictions on which vehicles can operate on trails. Smaller vehicles should be able to operate on trails, but not faster/articulated vehicles.

In an ideal world, the 'simplest' thing (from a user perspective) would be to allow grfs to define different speed limits for vehicles on different road surfaces. This would also be relatively easy work for grf coders. From a game code perspective, it's probably a nightmare to implement.

In a non-ideal world, without a complete grf support framework for multiple road types, the easiest thing is to prevent road vehicles from using trails. Trail vehicles however could use roads.

An alternative is to simply allow all RVs to use trails, at 1/3 of normal speed.

Maybe a livery refit would allow vehicles such as tractor-trailers to operate on trails, but at a reduced speed (Ice Road Trucking, anyone?.

Ice road trucking was definitely part of the inspiration here Anyone prepared to give up enough of the their life to implementing 'fake' ice roads over water using bridges? :0

[andythenorth]

First of all, it could just be allowed (despite being hardly visible if the tram tracks are drawn over the trails).
If not, more questions are coming up:
What if I build trail over tram? Should it say "Error: tram tracks in the way"? Or should it automatically build road instead?

Just build road in both the cases you gave. It's easiest for the user. Error messages are cognitively expensive and not good for the game experience. The cost shouldn't be crippling and should be a non-issue unless they lay trail over a long run of tram tracks or vice-versa.

cheers,

Andy

[YukonRob]

I agree with going for simplicity and allowing all RV's on trails at a reduced speed and off-road vehicles on roads ONLY because this eliminates the problem of competitors upgrading your trails to roads, but off-road specific vehicles really should not be allowed on roads (not just height but more specifically weight and width but also in some cases speed, lack of safety features and damage due to tracked vehicles). An elegant solution would be to allow off-road vehicles to cross roads only (treat perpendicular roads as trails) which keeps it a little more true to life and removes the possibility of sabotage.
my2¢,
Rob

[andythenorth]

but off-road specific vehicles really should not be allowed on roads (not just height but more specifically weight and width but also in some cases speed, lack of safety features and damage due to tracked vehicles).
my2¢,
Rob

Fair point about tracked vehicles, but would spank some of the plans for the Heavy Equipment grf I am working on, especially for farm tractors and similar vehicles. Would also cause trouble with Zephyris' horses

The ideal solution is for the grf to define on a per-vehicle level what road type can be used. That's not going to happen in a short timescale unless trunk developers suddenly get very excited about multiple road types

[Comm Cody]

Wow I would like that. maybe make a new industrie. National park need passengers and produce passengers . that would go nice with this. Keep on working!

[Zephyris]

I was bored, and a man can dream, so here is my ideas on grf coding of new road and rail types...:

General:
: 2 new features:
:: 0A - newroute, rail-like
::: 5 default IDs:
:::: 00 - rail
:::: 01 - electrified rail
:::: 02 - monorail
:::: 03 - maglev
:::: FF - [special; catenary graphics]
:: 0B - newroute, road-like
::: 3 default IDs:
:::: 00 - road
:::: 01 - electrified tramway
:::: FF - [special; catenary graphics]

Action1:
: Two new sprite set sizes:
:: ?? (Rail-like route and GUI graphics)
:: ?? (Road-like route and GUI graphics)

Variational action2 variables:
: 0X - ? - Date
: 0X - D - Map X coordinate
: 0X - D - Map Y coordinate
: 0X - B - Distance from town centre
: 0X - B - Height difference from sea level

Action 3 behaviour:
: CargoIDs replaced with:
:: 00 - ground graphics
:: 01 - above ground (behind vehicles) graphics (GUI graphics ignored)
:: 02 - above ground (above vehicles) graphics (GUI graphics ignored)

Action 0 variables:
: 0X - D - construction base cost
: 0X - B - construction base cost multiplier
: 0X - D - upkeep base cost
: 0X - B - upkeep base cost multiplier
: 0X - D - Depot base cost
: 0X - B - Depot base cost multiplier

: 0X - B - track types these tracks may be build over [road-like newroutes only] (ie. shared track space)
:: Bitmask - bit = newroute ID *
: 0X - B - group ID for track replacement with by the replace tool [road-like newroutes only] ****
:: B = group ID
: 0X - B - vehicle types that do not interfere with the movement of these vehicles [road-like newroutes only] (ie. tracks at different levels which do not interact)
:: Bitmask - bit = newroute ID **

: 0X - B - miscelaneous
:: Bitmask:
::: 01 - Disable building of this route type (dummy route type)
::: 02 - Enable catenary for this route type
::: 04 - Disable building bridges for this route type
::: 08 - Disable building tunnels for this route type
::: 10 - Enable company colour for this route type
::: 20 - Enable second company colour for this route type

: 0X - B - miscelaneous [road-like newroutes only]
:: Bitmask:
::: 01 - Disable building of passenger stops (freight only)
::: 02 - Disable building of truck stops (passenger only)
::: 04 - Disable building of bay bus/truck stops
::: 08 - Vehicles may not overtake and only turn on half tiles and disable building of bay bus/truck stops (ie. tram-like)
::: 10 - Vehicles do not stop at and cannot be destroyed on level crossings (ie. raised track)

: 0X - B - speed limit (mph/3.2)
: 0X - B - traction type limit [rail-like newroutes only] (ie. cornering speed limit)

: 0X - B - speed reduction/increase factor
: 0X - B - traction type reduction/increase factor [rail-like newroutes only] (ie. cornering speed reduction)

: 0X - B - Default sound effect [rail-like newroutes only]
: 0X - B - Default traction type [rail-like newroutes only]
: 0X - B - Default visual effect [rail-like newroutes only]


Behaviours:
Catenary is shared (ie. always has the same graphics)
Convert track type is changed to convert to XXX track type
New graphics drawn over road/rail graphics (so no specialised bridge etc. graphics required)

Egs:
* road would take a value of 02h = 00000010b from setting bit 01 corresponding to newroute ID 01
tramways would take a value of 01h = 00000001b from setting bit 00 corresponding to newroute ID 00

** for a hypothetic raised monorail in newroute ID 02:
road would take a value of 04h = 00000100b from setting bit 02 corresponding to newroute ID 02
monorail would take a value of 01h = 00000001b from setting bit 00 corresponding to newroute ID 00

**** for a set of routes including; rough road, road, express road, tramways, electrified tramways
rough road, road and express road would take a value of 00, tramways and electrified tramways would take a value of 01

Vehicle action0 behaviour:
New variable:
: 0X - B - track types the vehicle is for ***

*** overrides property 19 (trains) and property 0C (road vehicles)

[DaleStan]

Zephyris, if you're going to design an NFO spec:

1) Specify all values exactly. No "0X".
2) Specify unused values.
3) Specify values in the correct ranges.
4) Associate these values with the correct names.

You have violated at least three of those rules, and if you have not violated all four, then one of your other violations is so egregious it should count for two.

[Zephyris]

I was bored, and a man can dream, ...

I don't think I said anywhere I was designing an NFO specification, I think I gave the distinct impression I was bored and rambling. It behooves you to avoid such egregious misinterpretation of the nuance of suggestions, especially in the capricious environment of an internet forum.

[Aegir]

Mind if I snigger a bit?

Also, onto more serious matters, I like the idea of some sort of table or something to define what track types will allow what class of vehicles to drive on them. Say for example, one guage of rail, with multiple variations. Heavy vehicles can only use one type, medium, can use the heavier rated rails, light can nip about on all three.

plzkthx.

[Zephyris]

The other idea I had there I particularly like is transport types which would not interfere with each others movement, allowing raised monorail for example, I don't know how feasible this would be though.