Transport Tycoon Forums

Posted: **03 Jun 2008 20:37**

oh, i can totally see the reason for the new problem:

the station specification was never bound to such limits, so the station sets have also never been designed with limits like that in mind.

on the other hand, trainsets were designed with a lot of limits [rules for livery override, prevention of adding freight wagons to ICE trains]. but these relied on the fact that all vehicles possibly in use are known to the grf designer. this basic fact is just broken away, and the grf designers do not (yet) have enough possibilities (or time) to adjust to the shifted requirements [other grfs interfering in ways never imagined before]

Posted: **03 Jun 2008 20:44**

eddi wrote:trainsets were designed with a lot of limits [rules for livery override, prevention of adding freight wagons to ICE trains]. but these relied on the fact that all vehicles possibly in use are known to the grf designer. this basic fact is just broken away, and the grf designers do not (yet) have enough possibilities (or time) to adjust to the shifted requirements [other grfs interfering in ways never imagined before]

Exactly that´s why I wrote that TTDPatch had the same problem years ago and thus GRM had been introduced.

regards
Michael

Posted: **03 Jun 2008 20:51**

michael blunck wrote:Meanwhile, there have been some good proposals by OzTransLtd and by richk67 (in the CanSet thread), but OTOH, I must say that I don´t find parts of Richard´s and most of Peter´s contributions of any help ATM.

I am not against any particular suggestion so far, I just have not had time to take a proper consideration on them, and how they could/would be implemented.

So yes, so far I've only stated what is (that is, from my point of view), not what will or could be.

"ATM" suggests there is a critical problem in a release which needs sorting out immediately, which is not the case here. Any additions will come at the pace they come.

Posted: **03 Jun 2008 20:57**

michael blunck wrote:Exactly that´s why I wrote that TTDPatch had the same problem years ago and thus GRM had been introduced.

From a technical point of view, GRM is designed to stop (cooperative) sets from reusing IDs, stomping on each other, creating messed up statistics and such like. Of course, GRM can be used to reserve every available slot, and thus stop another (cooperative) set loading, even if you only used one, but I don't see that as its design goal.

The engine pool guarantees (without any other intervention, or bugs) that no IDs will clash, so in that regard it is the 'ultimate' way of reaching GRM's design goal.

(Of course, I was not there when GRM was designed, so this is indeed just from my reading of the specification and my opinion.)

Note that none of this comment is intended to indicate any negativity toward the suggestions that have been given.

Posted: **03 Jun 2008 21:17**

richk67 wrote:The demands for limitations on the feature come across as dictats from the elite.

Sort of like the dictats from the elite that say that I *will* accept certain features in OpenTTD, regardless of whether I want them or not?

Guess what. The "elite" are the ones doing all the work. If you don't like how they are doing their work, then produce a comparable work that you do like. Sort of like I do with TTDPatch.

Posted: **03 Jun 2008 21:52**

Draakon wrote:Where is this new action or callback documented that disallows a certain set to be used with others sets? AKA like CanSet uses.

*cough* KHKMH... *cough* *cough* *cough*

Posted: **03 Jun 2008 22:46**

Draakon wrote:
Draakon wrote:Where is this new action or callback documented that disallows a certain set to be used with others sets? AKA like CanSet uses.
*cough* KHKMH... *cough* *cough* *cough*

The reason you haven't got an answer to this question is that it's based on a false premise. There is no new action or callback.

Posted: **04 Jun 2008 04:52**

belugas wrote:... the notion of an engine pool patch is not something that happened out of nowhere? ...

I wasn't aware of it, because I don't follow everything that is discussed in the forum. It takes a lot of time. As far as OpenTTD goes, on a daily basis, I read the changelog and try to figure out what's new in the wiki. If there just were a note on top of a changed page for a few days, saying what has been changed.

rick67 wrote: ... OzTransLtd´s comprehensive posts are often phrased as a dictation of what MUST be there ...

I don't dictate anything ... I give suggestions, may be a bit too technical sometimes, compared to existing features too. It would be entirely up to Open Devs how and when they implement a suggestion, if at all ... the end result counts.

Eddi wrote: ... someone mentioned livery overrides. i think that is a real nightmare feature to build a set around ...

It is complex, but quite manageable. In the CanSet, that is the backbone; the behaviour of wagons depends on the engine, i.e. the engine company (CNR, CPR ...) or engine type (e.g. push-pull). Wagon overrides is not just the livery; the wagon length (of some of them) differs by company, plus a lot more tiny little things (everybody seems to like so much). They are all determined via an engine wagon override action-3 to start with. If the engine is not a Canadian one, the wagons won't function as intended, they are lost totally. And if a player wants to attach a wagon from another set, the Canadian engine doesn't know how to handle the situation.

You are welcome to make improvements ... I like your ideas, but let's stay focused with what we have at the moment.

Rubidium wrote: ... vehicle sets vs station sets ...

That is like comparing apples with oranges; stations, road vehicles, planes and ships are the apples and trains are the oranges. There is no problem with the apples, they are all individuals that get along quite nicely. However, the oranges need proper railtracks and not all oranges like all track systems, then they are connected with each other in many different ways, not all oranges like other oranges. It is the trains we have problems with not the apples.

And no, we do not enforce anything in regard to industries, stations, cities and roads. In fact we do everything to allow a variety of different ones to be used. From a North American point of view, if you want to play with ttrs3 and its road system you can do that and we make it possible that you can do that. You can play with ECS industries, we do support those too; sometimes with great difficulties and a lot of time, I may add.

Draakon wrote: ... Where is this new action or callback documented that disallows a certain set to be used with others sets? ...

I'm not quite sure, what you mean and what your level of expertise is in regard to NFO coding.

But, coders can use an action-E to deactivate a set; can be their own set or another one. How that can be done is documented clearly in the wiki.

BTW, it doesn't say I should leave sets, I have not created alone. I did get the message nevertheless loud and clear; that part will be changed; the CanSet will deactivate itself only (if it finds other train sets) UNLESS we can find a solution.

Posted: **04 Jun 2008 05:26**

OzTransLtd wrote:That is like comparing apples with oranges; stations, road vehicles, planes and ships are the apples and trains are the oranges. There is no problem with the apples, they are all individuals that get along quite nicely. However, the oranges need proper railtracks and not all oranges like all track systems, then they are connected with each other in many different ways, not all oranges like other oranges. It is the trains we have problems with not the apples.

Developer creates. Player plays what developer creates. Player chooses what oranges to use. Different players have different opinions about using these oranges with those oranges and if they fit or not.

Posted: **04 Jun 2008 06:17**

Draakon wrote: Developer creates. Player plays what developer creates. Player chooses what oranges to use. Different players have different opinions about using these oranges with those oranges and if they fit or not.

You still didn´t get it, did you?

OzTransLtd wrote: That is like comparing apples with oranges; stations, road vehicles, planes and ships are the apples and trains are the oranges. There is no problem with the apples, they are all individuals that get along quite nicely. However, the oranges need proper railtracks and not all oranges like all track systems, then they are connected with each other in many different ways, not all oranges like other oranges.

OzTransLtd wrote: the behaviour of wagons depends on the engine, i.e. the engine company (CNR, CPR ...) or engine type (e.g. push-pull). Wagon overrides is not just the livery; the wagon length (of some of them) differs by company, plus a lot more tiny little things (everybody seems to like so much). They are all determined via an engine wagon override action-3 to start with. If the engine is not a Canadian one, the wagons won't function as intended, they are lost totally. And if a player wants to attach a wagon from another set, the Canadian engine doesn't know how to handle the situation.

See also:

TTDPatch FAQ wrote: Q: Why are vehicles in fixed sets? I want to combine my own trains!

A: A (train) vehicle set isn´t just a simple collection of single vehicles. Instead, it represents the historical development of a specific region, a country or a single railway company. To do so, a set implements various interdependencies between its constituent locomotives and coaches/wagons (LiveryChanges, WagonOverride, ...) which requires to have all vehicles in one handy .grf file.

http://wiki.ttdpatch.net/tiki-index.php ... own_trains_].

This was written years ago but is still valid, this time before the background of OTTD´s multipool feature.

Draakon wrote: Developer creates. Player plays what developer creates. Player chooses what oranges to use. Different players have different opinions about using these oranges with those oranges and if they fit or not.

One more ignorant post like this and you´ll get plonked.

regards
Michael

Posted: **04 Jun 2008 06:47**

However, the oranges need proper railtracks and not all oranges like all track systems, then they are connected with each other in many different ways, not all oranges like other oranges.

That's called realism, which exists on real word. In (O)TTD(P) case, there is none. Which mean in the game, a random train just can run on a random custom track.

Posted: **04 Jun 2008 07:00**

But MAYBE. Some new thing [0] could be introduced that if it is set, then the grfs aren't compatible, but are loadable together. It means if I try to attach Canadian wagon to Deutche Bahn train, it says "incompatible blah blah".. Now if it would be more advanced, there might be some thing like MB suggesdted about friend or foe grfs.. Let's say I have US set and NARS and UKRS and want to combine a train. If NARS has given US set a friendly status, then I can attach NARS wagons to US engines, but not vice versa. To attach US wagons to NARS set, then US set has to give NARS a friendly status too.. And currently UKRS couldn't be combuned with either. But trains with only UKRS components would be nicely possible.

In addition it would need a sorting system, which I already mentioned somewhere. And no status given = "foe"..

[0] Some flag or property or such, I really don't know and I don't want to repeat Draakon's mistake

And the grfs would be defined by GRFID and maybe ultimately it could pick GRFID AND trainID, so certain wagons are NOT attachable.

The main point is that certain sets could be able to be used in one game without mixing the sets.. I believe OzTransLtd wanted that, that Canadian Set would be unmixed with others, but that doesn't deny us to use other sets at the same time

If only the economical changes would be per GRF basis too ;P

Draakon: No they can't.. Ever wondered why are there some narrow gauge sets there too?

Posted: **04 Jun 2008 07:14**

LordAzamath wrote:Draakon: No they can't.. Ever wondered why are there some narrow gauge sets there too?

Every electrical train can run on every electrical track, no matter what track set has been loaded. Same for normal trains (steam, diesel), monorails and maglev.

Posted: **04 Jun 2008 07:16**

No they can't. All monorail and maglev trains are electrical too, but still they need their own tracks. And for every set loaded.. Do you really want EVERY set author to release their gauge set too? Now imo that wouyld be kinda extreme

Posted: **04 Jun 2008 07:19**

OzTransLtd wrote:
Rubidium wrote: ... vehicle sets vs station sets ...
That is like comparing apples with oranges; stations, road vehicles, planes and ships are the apples and trains are the oranges. There is no problem with the apples, they are all individuals that get along quite nicely. However, the oranges need proper railtracks and not all oranges like all track systems, then they are connected with each other in many different ways, not all oranges like other oranges. It is the trains we have problems with not the apples.

In my opinion stations are less like road vehicles, planes and ships than you say them to be. Where RVs, planes and ships cannot be connected to eachother and such, station can contain parts from different sets similarly to trains.
I've made a simple example to prove my point that the issue isn't merely for trains but also for (at least) stations. I furthermore know that with vehicles it might get a bit more complex than with stations, but the same base principles to make vehicle/station sets compatible/incompatible with eachother in a single vehicle/station should hold for both.
My intentions with this are to get a generic system that can be used for both vehicles and station (don't connect with stationparts from other set, etc.), but possibly also for industries (disallowing PBI when ECS industry are loaded).

Posted: **04 Jun 2008 07:21**

LordAzamath wrote:No they can't. All monorail and maglev trains are electrical too, but still they need their own tracks. And for every set loaded.. Do you really want EVERY set author to release their gauge set too? Now imo that wouyld be kinda extreme

Did i say so? No, and i didn't say that monorail can run on maglev track.

Posted: **04 Jun 2008 07:27**

Rubidium wrote:My intentions with this are to get a generic system that can be used ... possibly also for industries (disallowing PBI when ECS industry are loaded).

Isn't that why we have Actions 7, 9, and E?

Posted: **04 Jun 2008 07:28**

Every electrical train can run on every electrical track, no matter what track set has been loaded.

as I said, maglevs and monorails are electrical too.

Posted: **04 Jun 2008 08:10**

DaleStan wrote:
Rubidium wrote:My intentions with this are to get a generic system that can be used ... possibly also for industries (disallowing PBI when ECS industry are loaded).
Isn't that why we have Actions 7, 9, and E?

Just wondering how I can code: allow only NewGRFs with GRF ID x, y and z to build industries when I am enabled. Updating your NewGRF each time someone else releases a NewGRF that does introduce industries seems quite hard to maintain and determining another NewGRF introduces new industries is not possible to do in nfo at the moment either (I could at least not find any ways to do so efficiently).

Posted: **04 Jun 2008 10:03**

Draakon wrote:
Draakon wrote:Where is this new action or callback documented that disallows a certain set to be used with others sets? AKA like CanSet uses.
*cough* KHKMH... *cough* *cough* *cough*

BTW, I decided to look out where it was documented.. And found.. Action 7/9 variable 85
http://wiki.ttdpatch.net/tiki-index.php ... PatchFlags

Flag 78:

Code: Select all

78	dynamicengines (OpenTTD, since r12924)

Basically Action7/9 are actions which conditionally skip sprites and variable 85 bases the condition on whether some flags are set or not. (Not the best English, but I hope you can understand)
I believe canset uses that?

Transport Tycoon Forums

Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)