Transport Tycoon Forums

I said this on IRC earlier and it is not meant to be an attack of sorts. I agree that Industry sets should conform to a global sceme but with UKRSI I kind of think it should stick to the same sceme/idea as the original industries as it is an enhancement to them.

Folks, I'm going to say it one, last time.

This is NOT a general ECS rambling thread, it is purely for discussion about the ECS and the UKRSI working together. We currently await comment from Pikka.

If I see any more OT in this thread, I'm flat out handing out a warning for it, I'm getting sick of cleaning it up.

OK. Time for a committed player's point of view and so it is that I shall wade into the fray.
I am neither artist nor coder.
I am a player who likes to assemble whimsical scenarios such as using all 90 available in-game industry slots and then making decisions as to which survives during the game.
I like to use all forms of transport ... rail, road, air and sea, often combining them to move a shipment from point A to point B.
TTDX in its default form was somewhat basic to my wants and desires. Along came the Patch and a whole new world opened up ... features, features and still more features! A TTDX addict's dream come true.
Next came the graphics. Then new industries. My grf folder has grown exponentially.
In true addict fashion, I want more. HAH! I WANT IT ALL!
And so we come to ECS. I watched as it was developed, contributing an occasional suggestion, critique or round of applause. I was intrigued by George's implementation with plug-ins (vectors), making for a truly customizable gaming experience. Others saw the benefits of new industries, and so Pikkabird offered his most excellent UKRSI. And this brings me to my next point.
UKRSI is not vectorized with plug-ins. I wish it were. I'd dearly love to be able to combine some of its features with others from elsewhere. That gravel pit really rocks. (no pun intended ... well perhaps just a little. ). Instead, I believe, and I may be mistaken in this, that UKRSI was designed by Pikka as a typical British industry set to compliment Pikka's UK rail set. There was no thought nor intent of its being used with anything else. Thankfully, it does work with some other transportation sets. I believe that WhiteHand is following this same path with his NSW set.
So, rather than those two sets being generic "all things to all men" sets, they speciallize in presenting transportation as it evolved in some very specific geographic regions. Obviously making them fully compatible with other sets, whether via ECS or otherwise, is not primary to their design, however, for a TTDX addict such as myself, it would be nice.
I think that is the direction that Michael Blunk is taking with his fine sets, which I find to be quite adaptable.

Conclusion: ECS is a standard fully described in the wiki. It is merely a framework for people to build upon. Hopefully, for compatibility's sake, they will remain true to the standard, but if they should chose to stray a bit, that is ok too, even though it would limit the player's choices and experience.

Raichase wrote:This is NOT a general ECS rambling thread, it is purely for discussion about the ECS and the UKRSI working together.

Or at least working separately, but correctly, with same vehicle set (which is even more important IMO).

good post the bit about UKRSI being a typical industry chain and the bit about it being specific and accurate are also what I feel about UKRSI.

wallyweb wrote:Instead, I believe, and I may be mistaken in this, that UKRSI was designed by Pikka as a typical British industry set to compliment Pikka's UK rail set. There was no thought nor intent of its being used with anything else. Thankfully, it does work with some other transportation sets.

That's point UKRSI may on may not work together with ECS, but if you use vehicle set which supports ECS, it should support at least UKRSI cargos with same labels if both ECS and UKRSI are coded properly as stays in Wiki.

George,

I was under the impression that "refined products" was the best match for Plastics - they're produced by the oil/chemical plant and go on to the factory.

I'm willing to change the cargo slots for gravel and clay, but it's not a priority for me right now, so it will have to wait until the next time I work on the UKRSI. Also, since there will always be some compatibility issues between newindustry grfs, I'm willing to make the UKRSI disable itself if ECS industries are active, if you could give me a list of GRFIDs or a partial GRFID for your industry sets.

George wrote:If gravel would be a type of sand (for example), than it would be transported in dump-trucks as a dark dirty yellow cargo. Not absolutely correct, but less ugly.

I don't really get how you want this to work. Do you want gravel to have the label SAND? That would be just plain wrong, it's not sand, it's gravel.

If you only want it to occupy the slot of sand, how would that help vehicle stets? If you use a cargo translation table, the slots don't matter. If you don't have GRVL in your translation table, you will just see an unknown cargo type no matter which slot it's in. If you don't use a translation table, are you just blindly assuming that ECS cargoes are loaded into the right slots?

In general, I don't like the idea of forcing everything into some ECS cargo type. Should gravel pretend that it's really sand just because gravel isn't in the "kosher" set of cargo types?

I think there is no need to force new cargos to ECS scheme, if gravel is GRVL, that's new cargo, but if lumber uses wood products label WDPR which allready has its definition for ECS, then it must be coded like wood products.
Good thing is that Pikka said he'll fix those irregularities.

Wile E. Coyote wrote:I think there is no need to force new cargos to ECS scheme, if gravel is GRVL, that's new cargo, but if lumber uses wood products label WDPR which allready has its definition for ECS, then it must be coded like wood products.
Good thing is that Pikka said he'll fix those irregularities.

Well, I don't really want to make it a bulk cargo, so I might give it a new label...

Of course, do what you think it's best for your set , we can see if we could be able to make support in other sets.

PikkaBird wrote:I was under the impression that "refined products" was the best match for Plastics - they're produced by the oil/chemical plant and go on to the factory.

Possible solution. That's why I had it is a point for discussion. I have to think about it some more

PikkaBird wrote:I'm willing to change the cargo slots for gravel and clay, but it's not a priority for me right now, so it will have to wait until the next time I work on the UKRSI.

That is Ok. How do you look at idea to split your UKRSI into vectors?

PikkaBird wrote:Also, since there will always be some compatibility issues between newindustry grfs, I'm willing to make the UKRSI disable itself if ECS industries are active, if you could give me a list of GRFIDs or a partial GRFID for your industry sets.

This list is public on my site, but I'm strongly against this idea. Contrary, I'd suggest to make them more compatible. I'm ready to spend some of my time into it.



Or it is possible to solve the situation it in the other way:
You, Pikka, could give me permission to create the ECS vector (I suppose construction vector) from UKRSI industries (the new ones). That will allow a user to use your industries and some of the ECS vectors in the same game.



2 Josef and Csaboka: (mods, move it to suggestion section please)
I'd like to ask for GRF packages again. A package is a file, that consist of a group of GRFs inside it, that is only one enrty in newgrf.cfg, but a group of files in newgrf widow (and in game). The parameters of this file should be given to all the files in a package. I suppose that isn't hard technically, but may lead to some confusions, of cause.

Csaboka wrote:

George wrote:If gravel would be a type of sand (for example), than it would be transported in dump-trucks as a dark dirty yellow cargo. Not absolutely correct, but less ugly.

I don't really get how you want this to work. Do you want gravel to have the label SAND? That would be just plain wrong, it's not sand, it's gravel.

I mean it should use ID 11! (sand). And if it looks similar to sand than it should have label SAND too! Because it's specific behaviour is hold by it's special industry and it knows, that it is. The cargo label does not define the name, so it can be named as you wish.

Csaboka wrote:If you only want it to occupy the slot of sand, how would that help vehicle stets? If you use a cargo translation table, the slots don't matter. If you don't have GRVL in your translation table, you will just see an unknown cargo type no matter which slot it's in.

This is not absolutely correct. Vehicle set CAN check both the labels and slots and even classes too! In fact they do that not (LV4 uses labels and classes). But they CAN do it. It is technically possible

Csaboka wrote:In general, I don't like the idea of forcing everything into some ECS cargo type. Should gravel pretend that it's really sand just because gravel isn't in the "kosher" set of cargo types?

The main idea, that was in mind when ECS specification was created, was that we define cargo groups, not cargo itself. Under one label several cargoes may exists. For example, a label food could be milk, chips or sweets in different implementations, but could be supported by vehicles sets in the same way. The same way as cereals can be grain, wheat or maize.

I don know in what topic should it be posted best, but let me describe how I see collaboration between industry sets.
If two sets have independent cargoes, they should coexist unless there are enough slots (37 for industries, may be less for cargoes, because of the way they are stored, but if they have about 75% of slots used, they should be ok to be used in most cases)

If two sets have similar cargoes, they should share them. Example - ECS Wood vector and UKRSI. ECS Wood industries are disegned to work with wood products, but if it would happen, that lumber overwrites wood products, than it should be used instead. I hope Josef would do alternative translation tables someday, so it would make it much easier to hold it.

If two sets have cargoes that are rather different in support, but similar in general, industries should loose this cargo. For example, some set would define cars instead if vehicles/machinery (label CARS), ECS Wood forest would accept nothing instead of vehicles.

George wrote:That is Ok. How do you look at idea to split your UKRSI into vectors?

I don't really have any interest in splitting the UKRSI into seperate grf files. I may also add more cargos and industries in the future, which will presumably cause even more problems with ECS.

This list is public on my site, but I'm strongly against this idea. Contrary, I'd suggest to make them more compatible. I'm ready to spend some of my time into it.

Well, since 100% compatibility is unlikely to be possible, I'm not sure I am. I'll go as far as I can, but I still maintain the policy that my industry sets are not guaranteed to work with other sets not specially designed to be compatible.

Or it is possible to solve the situation it in the other way:
You, Pikka, could give me permission to create the ECS vector (I suppose construction vector) from UKRSI industries (the new ones).

Sure. As long as credit is given, feel free to make a more ECS-friendly variant of part or all of the UKRSI, if that's what you want to do.

George wrote:This is not absolutely correct. Vehicle set CAN check both the labels and slots and even classes too! In fact they do that not (LV4 uses labels and classes). But they CAN do it. It is technically possible

You're right. However, it would be nicer to keep the used cargo slots as an implementation detail, something vehicle sets don't need to care about. I don't really like the idea of using them for inter-GRF communication. (Your solution basically means that by using slot X, the GRF is saying "this cargo is similar to ECS cargo X". But what should happen to cargoes that aren't similar to any ECS cargo type? What if an industry GRF wants to define both gravel and sand, for example? It can't have both in the same slot.)

George wrote:The main idea, that was in mind when ECS specification was created, was that we define cargo groups, not cargo itself. Under one label several cargoes may exists. For example, a label food could be milk, chips or sweets in different implementations, but could be supported by vehicles sets in the same way. The same way as cereals can be grain, wheat or maize.

There's an important difference between your examples and the gravel problem. Milk is a kind of food. Maize is a cereal. Gravel, however, is not a kind of sand. For example, I don't think they make glass from gravel, while they can from sand.

Even if we accept the "gravel=sand" equation, you surely can't say that clay is a kind of limestone... So, if something doesn't fit to the ECS categories, it's easier to just admit it. ECS-compatible vehicle sets won't support UKRSI fully (unless they're coded specifically for UKRSI, of course), but you can still go back to UKRS if you don't like this.

Also, there doesn't seem to be an easy way for ECS to live together with an industry set that defines some non-ECS cargo types. (By non-ECS, I mean things that don't fit any of the ECS categories, for example nuclear waste.) Since ECS uses all cargo slots, the only thing you can decide is what vector to be incompatible with. I can understand if a GRF author decides not to be compatible with ECS at all, except for using ECS cargo labels where appropriate. This makes ECS-aware vehicle sets work as much as possible, but doesn't limit the possibilities of the author.

PikkaBird wrote:

Or it is possible to solve the situation it in the other way:
You, Pikka, could give me permission to create the ECS vector (I suppose construction vector) from UKRSI industries (the new ones).

Sure. As long as credit is given, feel free to make a more ECS-friendly variant of part or all of the UKRSI, if that's what you want to do.

Have a look. Correct me if I'm wrong. One is the set how it is now, and the other is how it can be a vector. What do you think?

Csaboka wrote:Since ECS uses all cargo slots, the only thing you can decide is what vector to be incompatible with.

Absolutely correct solution. Machinery vector and Machinery vector for tropic illustrates it.
Also the suggestion about the Construction vector mod from UKRSI is the same idea.

Okay. So all you want me to do is change the cargo slots to the same as ECS sand and limestone?

PikkaBird wrote:Okay. So all you want me to do is change the cargo slots to the same as ECS sand and limestone?

According to the late discussion, slots of limestone and cement should be used for clay and gravel.
As for Plastic, it is possible to use refined products or dyes. As far as I can understand your plastic, it may be dyes. If yes, than that's enough. If your plastic is something different, than dyes, refined products may fit better. If none of this fits well, we could use bricks slot instead (and remove this part of the chain in the construction vector). Let me know what did you intended

Gravel is not really needed to make bricks. Clay is enough.

WIKIPEDIA wrote: Brick is an artificial stone made by forming clay into rectangular blocks which are hardened, either by burning in a kiln or sometimes, in warm countries, by sun-drying.
...
Clay is the most common material, with modern clay bricks formed in one of three processes - soft mud, dry press, or wire cut.

The soft mud method is the most common, as it is the most economical. It starts with the raw clay preferably in a mix with 25-30% sand to reduce shrinkage...

OK. WIKIPEDIA continues and discusses about stone, cement, etc. But for these the term brick is very loose and in many languages they have different name. E. g. cement bricks (cement, sand, gravel) in my country are called "cementstones" and these do not require a factory, people can make them on the building spot, as cement dries itsself. When people talk about bricks they have in mind the ones made from mud and burned or in previous eras left to dry in the sun.

Conclusion: ~3/4 Clay, ~ 1/4 Sand, (Coal), (near water).