Future of newcargos

[George]

Edit by Csaboka: This is a split from the One Climate Cargo Set thread.

And of course Foodprocessing Plants 'produce' waste which is old as fodder.... to the farms

That looks like fertilizer in ECS Agricultural vector

Sue him for steeling your vector .

No. I just don't want to have 2 very similar projects. Better to unite them or make very different.

May I ask a BIG question? What do we ALL want to get?
I suppose that we need one rather done project first in a sensible while rather than a hundred 1% complete projects soon? But may be I'm mistaken.

Just to explain what we are speaking about. I'm doing ECS vectors for two years. Only 3 from 9 are about 50% done. Michael Blunck is working a bit more and we saw only one small pre version. Hope everyone can count now, how much time would it take to create the whole set. You should also take in to account, that I drew only several industries, most industries are drawn by other artists. Just as comparison. LV4 took three years. The most finished project is German vehicles and it took more than a year already. And it is about a half of LV4. It proves, how much time do projects take.

So, what do I think. Now, according to the situation, we have these ways:
1) We put all the efforts of the coders and artists into one set and make subversions or extensions later
2) Many coders makes their own versions of cargo chains from public graphics (from artists who are not the coders, like Oz, Zimmlock, Lifeblood), like there were Tourists set and ECS town vector. Users have pain with sets compatibility
3) We invent some schema, where industries are standalone objects who adjust themselves to the cargo chains loaded (cargo chains are defined separately without industries). The user will get many entries in his newgrf.cfg

Let us think first, then do, and not the contrary. (I really don't want to repeat the struggle with Whitehand about tourists. It was silly)

2mods:
May be to split this into a new topic and just put a link here? The name may look like "Future of newcargos". I do not think we need a poll. Just a place for opinions.



P.S. I'm starting to get bored again. Every time, instead of collaboration, we start to create many similar projects just to proudly call them MY PROJECT instead of OUR PROJECT. If this spirit would continue to be dominating, I'll think for leaving these forums again.

[Hyronymus]

Why do you always want to unite stuff, George . No offense but I really don't see a problem with ECS and OCCS existing next to each other. And of course these projects are similar: they both cover TTD industries. But they would do that without fertilizer being part of OCCS too as there are basic industries covered by both that remain even if you did take fertilizer out of OCCS.

I think the various vehicle sets have proven that it's not a problem to have multiple sets next to each other that "do the same". Also, it's their creator's call to determin which cargo set to work with in the end. I think we should give them an oppurtunity to choose.

[gmyx]

...

I'm of two opinions on this. On one hand, it's better to have one completed project rather than two separate incomplete projects.

However, this limits the user's choice - one system. And that to me is imposing an artificial limitation on the user.

I started this about a month ago when playing TTD I thought, wouldn't it be nice if the industries accepted passengers? It would make it more realistic. It quickly became: if I'm changing the industries, I might as well do other stuff at the same time. I soon arrived at the concept for this industry set.

Variety is one of the great things about TTDPatch. You don't have to use any GRF(except base) if you don't want to.

ECS is a good, extensive system that when completed will give users a very good challenge. But what if you want more choices? Yes, you can alter the installed vectors, but it's still ECS. You could use one of the other sets out there, and I'm presenting users with another option.

To sum it all up -> competition is good. My 2 cents.

[George]

Why do you always want to unite stuff, George .

Because I want to see things finished. I see that I can't do it alone. So, I try to make people unite and make it together. More people have more time to achieve the result, than a single person.

No offense but I really don't see a problem with ECS and OCCS existing next to each other.

I do not see too. But when they are both done! When they are in progress, I want one of them to be finish first, and only then to finish the second.

I think the various vehicle sets have proven

Proven? US set is not v1.0 yet, DB set is not v1.0 yet. And I do not speak about many other sets, which are much smaller, than those two! I see that train sets have proved that we need to unite our efforts, because splitting them into hundred projects killed them ALL! Do you know my big problem? I do not have one complete train set so it could relative easily be updated to support ECS! Not because ECS is unfinished. No, the schema was published in 2005 and was not changed for two years! But because there is NO FINISHED TRAIN SET. Completely finished, that means the only task would be only to add new cargo graphics and AI management. THERE IS NO SUCH A SET! NO set in the course of TWO YEARS! And you say "various vehicle sets have proven" after that?

I do not know what else should I say to open people eyes
May be someone else will try?

To sum it all up -> competition is good. My 2 cents.

Competition is good ONLY when AT LEAST TWO competitors have ENOUGH RESOURCES to COMPLETE the project (achieve the finish line) during the SENSIBLE PERIOD OF TIME. In all the other cases competition is a form of suicide. I suppose your left lung does not compete with the right one? Right? Or may be your left leg compete with your right leg? No? Why? Because they are working for one result. Maye one of them would also bring the result. May be a better result ... But most probably you will die in the first case and fall in the second. Because one of them is not enough to complete the task. (Just make readers to think. Just a little. Hope someone can understand what I try to say. May be he will explain it all better, than me)


So, why do you want a competition here? What do you want to? You'll code Zimmlock's industries, I'll code Zimmlock's industries. That is double work. What is the profit? Why do you want it? What for? I understand when we have artists' competition, but competition of coders is a form of madness. We already had it in the past. But we do not learn. We want it again. [sarcasm] Fantastic! [/sarcasm]

[gmyx]

Why do you always want to unite stuff, George .

Because I want to see things finished. I see that I can't do it alone. So, I try to make people unite and make it together. More people have more time to achieve the result, than a single person.

Fair enough, many people can achieve a end result quicker than alone.

No offense but I really don't see a problem with ECS and OCCS existing next to each other.

I do not see too. But when they are both done! When they are in progress, I want one of them to be finish first, and only then to finish the second.

This would effectively kill any other projects since by your own argument, none are completed.

I think the various vehicle sets have proven

Proven? US set is not v1.0 yet, DB set is not v1.0 yet. And I do not speak about many other sets, which are much smaller, than those two! I see that train sets have proved that we need to unite our efforts, because splitting them into hundred projects killed them ALL! Do you know my big problem? I do not have one complete train set so it could relative easily be updated to support ECS! Not because ECS is unfinished. No, the schema was published in 2005 and was not changed for two years! But because there is NO FINISHED TRAIN SET. Completely finished, that means the only task would be only to add new cargo graphics and AI management. THERE IS NO SUCH A SET! NO set in the course of TWO YEARS! And you say "various vehicle sets have proven" after that?

I do not know what else should I say to open people eyes
May be someone else will try?

Many projects have usable GRFs. Numbering doesn't mean much other than to say updated version. Some projects have been below v1 for ever but yet continue to expand and improve above the original ideas. It's a "living" project that evolves over time.

To sum it all up -> competition is good. My 2 cents.

Competition is good ONLY when AT LEAST TWO competitors have ENOUGH RESOURCES to COMPLETE the project (achieve the finish line) during the SENSIBLE PERIOD OF TIME. In all the other cases competition is a form of suicide. I suppose your left lung does not compete with the right one? Right? Or may be your left leg compete with your right leg? No? Why? Because they are working for one result. Maye one of them would also bring the result. May be a better result ... But most probably you will die in the first case and fall in the second. Because one of them is not enough to complete the task. (Just make readers to think. Just a little. Hope someone can understand what I try to say. May be he will explain it all better, than me)

So, why do you want a competition here? What do you want to? You'll code Zimmlock's industries, I'll code Zimmlock's industries. That is double work. What is the profit? Why do you want it? What for? I understand when we have artists' competition, but competition of coders is a form of madness. We already had it in the past. But we do not learn. We want it again. [sarcasm] Fantastic! [/sarcasm]

[/quote]
I think you have mis-interpreted my intentions. I didn't mean compete in the traditional sense but rather feed-off of each others designs and end up with two good products. I only offered to code his industries because in his thread he said he was looking for coders and no one has stepped up to the plate. And I'm going to read 113 pages to see if someone else a long time ago has offered but forgot about it since he was asking again.

I don't want to start a war of words over this. I know this is a big undertaking on my part - my to do list has many items and seems to grow daily. And I certainly don't want any harm to come to ECS, which to me is kind of a pioneer of the industry sets.

[michael blunck]

May I remind you all of the fact that ECS (the "Extended Cargo System") does only establish a formal definition of cargoes to assure a maximum amount of compatibility for both new industry and vehicle sets?

The way it does this is by specifying cargo slots and bits for a fixed set of cargoes, both new and "original TTD". The implementation of appropriate industries for these cargoes OTOH will be a matter of a variety of individually created "industry sets" (e.g. George´s ECS vectors). Each of these sets may implement a different behaviour in terms of industry production and/or cargo parameterizing, but as long as they do stick to the ECS cargo definition scheme they´ll be compatible with every vehicle set which does in turn implement the ECS scheme.

So, IMO, what we may be in need for would be a multitude of industry sets (i.e. from different artists) which will be compatible to a maximum degree. But what we don´t need is another "competing" cargo scheme, especially not in those areas where we already have ECS, e.g. in temperate climate. Just the wish to change some of ECS´s cargo names doesn´t justify an incompatible setup.

regards
Michael

[Csaboka]

Many projects have usable GRFs. Numbering doesn't mean much other than to say updated version. Some projects have been below v1 for ever but yet continue to expand and improve above the original ideas. It's a "living" project that evolves over time.

I agree. Furthermore, I know about at least two train sets that have reached 1.0 already: UKRS and NARS. (And I'm not really following the Graphics subforum, so there must be more.) I think they could be made compatible with ECS with some small changes, plus adding new wagon graphics. They already support PBI (formerly UKRSI), so they must be fully newcargos-aware.

I do not see too. But when they are both done! When they are in progress, I want one of them to be finish first, and only then to finish the second.

The problem is that your ECS implementation is a really huge project. We can have a "small" industry set finished faster than an all-encompassing scheme like ECS. So why not have many smaller sets with more diversity? Why should the ECS project be the first to be finished, when a smaller set can give us a fully enjoyable game sooner?

When your ECS implementation will be finished, we will have one cargo scheme and one gameplay style (with a zillion cargoes and industries). Looking at the current way it is going, this will be a very realistic gameplay, requiring a lot of planning. Some people will like it because it adds difficulty, and some people (like me) will prefer the current simpler gameplay. Nevertheless, it will be "love it or leave it".

On the other hand, when we allow smaller sets to be developed, we can end up with different approaches that require different gameplay. There can be easier sets and harder sets, different cargoes, different cargo processing schemes etc. You can select the one that is the best for your taste, or use a different one in every new game and play the game a little differently every time. I'd even say that if a GRF author needs a cargo type that isn't in the ECS cargo list (like coke in Zimmlock's scheme), he should use it and break some part of ECS. The worst that can happen is that you'll have to supply your own wagons. Compatibility is nice, but shouldn't restrict the "artistic freedom" of the set author.

[michael blunck]

The problem is that your ECS implementation is a really huge project.

Even in George´s implementation you don´t need to use all cargoes and every industry. You may use only a couple or even one of its vectors.

I'd even say that if a GRF author needs a cargo type that isn't in the ECS cargo list [...] he should use it and break some part of ECS. The worst that can happen is that you'll have to supply your own wagons.

That may turn out to be hard in the actual implementation, though. Firstly, why should an industry set contain vehicles to be used in addition with other vehicle sets? And for (existing) buildings it´s impossible to "overwrite" their specific cargo acceptance rather than to introduce new ones. So, consequently, when introducing non-ECS cargoes to be used with ECS-compatible vehicle and building sets you´ll need extra vehicles and buildings with your custom industry set and you´ll have to find a way to make them work with those "host" sets - not an easy task if they´re using GRM.

regards
Michael

[Dave]

Perhaps there is some sort of "lost in translation" issue here. The implementation is merely of these cargo slots, correct?

They do NOT limit the artist/coder/GRF maker in their scope for different industries?

Maybe some people are taking issue at the way in which the cargo slots are named, insofar that they may feel constricted by said cargo names.

If I was aware of the fact that I could, actually, make a Coal Mine a Flobble Mine (I know this is ridiculous, but successfully argues my point and is hypothetical*) and produce "Flobble" instead of "Coal", to be taken to a Generator Station instead of a Power Station, and STILL be compatible with the ECS schema, my mind would be at ease a lot more.

As it is, I think some GRF creators feel somewhat constricted by the model, which in itself is VERY good but goes beyond (in my humble opinion) the usual constraints that TTD Patch GRF creators are used to.

(* - I felt this needed highlighting - my hypothetical examples usually turn into the core of any responsive argument.)

[wallyweb]

I was going to post a response to this topic earlier, when it was located in gmyx's thread. I'm glad I waited as there have been some interesting additions to the discussion.

First. it's good to see you back Mr.Blunck. I hope you had a nice summer. I'm still waiting for breakfast.

Next ... the topic ... various industry implementations. Yes gmyx and George, there is a future of new cargoes ... both of yours, and Michael's and PikkaBird's and Zimmlock's and DanMack's too and the smaller ones such as Whitehand's tourists as well. I speak as a representative of the goal of your diverse and collective efforts ... the end user.

My first exposure to additional industries was Csaboka's patch work that allowed for industries of one climate to be used in another. I was hooked. Then Michael added fish and breweries to the mix ... a very nasty thing to do to a player where Fish 'n Brew Pubs are all the rage in his town. My habit was reinforced. I could no longer return to the simple life of TTDX's simple industry structure. Then George's ECS implementation came along. Thank you George. You planted the knife into my heart. I can no longer design a simple scenario. In fact, it now takes me longer to design one than to play it. PikkaBird went his own way with UKRSI (Now converted to a modular structure building upon a base group of industries ... still needs fish 'n chips though) which gave me some flexibility in choice of scenario design ... as in "Am I in a George mood or am I in a Pikka mood?". Of future consideration, we have all seen the early graphics for DanMack' Canadian Industries and Zimmlock's stuff. I will use them all, each in their own unique implementations. As for mixing things up a bit, I have successfully used WhiteHand's tourist set in all my scenarios. I have even been able to use George's castle with Pikkabird's set. Search the forum for pipelines.

Now, the question of vehicle sets (Planes, Trains, RV's and Ships) and how well they fit with a particular Industry Set. Wyle E. Coyote's Serbian set is excellent. Michael's sets are a work in progress, I think. Am I correct, Michael? Pikka's UK stuff works well with Pikka's industries, but I think that is all he wants for now. I understand that DanMack's forthcoming Canadian Set revision will have parameters to accommodate different industry styles. NARS v1 seems to work ok across the board. NARS v2 remains to be seen. I am not familiar with the progress of the Czech stuff, nor the Swiss, Japan and the others. RV's all seem to be a work in progress although Zephyris' ervs is showing a lot of progress (Articulated Trucks need refit work).

George, it looks like a lot of confusion, but please believe me when I say that as a player, I couldn't be more pleased with all the choices. It is what keeps me interested in this game. Don't worry about incompatibilities. Either their authors will sort them out or they will be quickly abandoned to the Windows Trash bin and we won't have to worry about them.

Gentlemen, and Ladies too (SAC, Where are you when we need you? ), your efforts are truly remarkable and I for one appreciate them. I celebrate the variety you force me to chose from. You may be steering different courses, but as long as your efforts work, I'll use them. If not, I'll slap you with a trout.

Thank you.

[gmyx]

When I think of ECS, I think of George's implementation and the schema. I don't think of ECS as a list of cargoes. I remember the threads at the time ECS was being thought out, but didn't care much since I was not interested in coding at the time and it seemed more like a very specific implementation. ECS seemed to me to be cargoes, labels and industries all in one.

Now, where there is overlap with ECS labels, I will use them. When there isn't and there aren't close aproximations, well I'm forced to create one. I have not found a central list of all labels used in all current industry sets, maybe my search is ineffective...

Maybe ECS should be re-though to include many more labels (I know what issues that causes) and not worry about the schema. For example, include as many cargoes than make sense without getting anal and also not limiting our selves to the limit of 32 cargoes since the labels have more room. Then industry sets can pick from that long list and use those and not be stuck with "the 32".

Other ideas have come since and more will come in the future. We should not be artificially limiting others that don't agree with the current ECS schema and decide to live with the possibility of limited vehicle set support.

I am a proponent of variety and, yes there already is a lot of variety with ECS, PBI , Canadian Industries (I hope they snow in there ) and others.

[George]

This would effectively kill any other projects since by your own argument, none are completed.

Except the first public (open) one.

Many projects have usable GRFs.

A grf with a single train is usable too. But it is not a train set, regardless the name and version. Hope you agree with that

Numbering doesn't mean much other than to say updated version. Some projects have been below v1 for ever but yet continue to expand and improve above the original ideas. It's a "living" project that evolves over time.

We can use any numbering system we want, but that does not change the general situation. The most complete sets are DB set and US set, right? Are there other sets as complete as those two? May be I've missed something new? Their versions speak for themselves. (LV4 is more likely to be called 0.4, but it does not change anything)

I think you have mis-interpreted my intentions. I didn't mean compete in the traditional sense but rather feed-off of each others designs and end up with two good products. I only offered to code his industries because in his thread he said he was looking for coders and no one has stepped up to the plate.

We discussed coding his industries over two months ago. They are in my todo list. I just need to finish Oz ones first.

Maybe ECS should be re-though to include many more labels (I know what issues that causes) and not worry about the schema. For example, include as many cargoes than make sense without getting anal and also not limiting our selves to the limit of 32 cargoes since the labels have more room. Then industry sets can pick from that long list and use those and not be stuck with "the 32".

Please look better
ECS implementation already HAS more than 32 labels. As you can see in ECS vectors schemas, there are so called "mods", what replace vectors one with the other. The most known is Pikka's mod for ECS Construction vector that replaces LIME, CEMENT, BRICKS with GRAVEL and CLAY.

[michael blunck]

[on ECS]

The implementation is merely of these cargo slots, correct?

Well, ECS isn´t an implementation at all, it´s a specification/definition. It defines a set of cargoes and specifies cargo slots and bits to them. It doesn´t define industries OTOH, nor does it specify the way they interact (e.g. supply fertilizer to farms to boost their output, etc.) These are just mechanisms inside industry sets and as such are left to the developer of those sets.

The main reason for this limitation is that ECS was developed primarily as an interface for vehicle sets, it´s not a framework for industry sets.

Concerning the wish for "more and different cargo", firstly, ECS cargoes have been carefully chosen with regards to

- importance of cargoes in the real world,
- usefulness in game and
- attractiveness in transportation.

E.g., with regards to "attractiveness", something like "sulphur" would be chosen over "electronics" because the first one would be visually attractive by being transported in open cars while "electronics" would be just indistinguishable "boxes" or even not visible at all, and in addition, the first one would enable more interesting ways of cargo transfer (e.g. animated cranes or other special transfer structures).

Secondly, you may also use the "cargo subtext mechanism". In general, ECS makes use of a comprehensive naming scheme. E.g., it uses "cereals" (CERE) rather than "grain" because the former includes grain crops, edible seeds, nuts, roots and tubers, which may be defined then by using e.g. "cereals (rye)" or "cereals (tapioka)". Same is possible with every other ECS cargo label, e.g. "beer" is defined as "food (beer)".

Thirdly, you may define a "mod" which would replace a whole "cargo vector". See George´s ECS implementation.

I have not found a central list of all labels used in all current industry sets [...]

It´s in the Wiki.

Maybe ECS should be re-though to include many more labels [...]

I don´t think so. We don´t need an "inflation" of labels, see my explanations above. The main reason for this is that ECS should act a clean interface for vehicle sets. E.g., my own DB Set implementation will support ECS only, but in no case each and every other "cargo scheme". This wouldn´t be possible. In addition, I´m still convinced that the current cargo definitions in ECS are sufficient. Many discussions had come up with the wish for different cargoes, only to end up in conclusion that it could well be implemented under the ECS umbrella. At least this is true for the temperate climate. I´m not so well-informed about arctic and tropic because I´m not too much interested in these climates and had left definition of ECS cargoes for them to other people.

We should not be artificially limiting others that don't agree with the current ECS schema and decide to live with the possibility of limited vehicle set support.

I have read statements like this from the beginning of the ECS discussion (ref. krtaylor) but IMO that´s only a void statement as long as there´s no sound proposal for a new cargo vector unable to be placed under ECS.


@wallyweb
Thanks for your encouraging words, as usual.

@moderators:
Shouldn´t the whole discussion moved into the usual ECS discussion thread?

regards
Michael

[Hyronymus]

This topic feels like a lot of bla bla . If gmyx wants to develop a different cargo framework then we should let him. What I see is the "ECS fanboys" (no unfriendlyness intended) are conquering arguments why one would want a different cargo framework. Maybe there is an overlap between OCCS and ECS but is that a bad thing? And maybe the labels in ECS aren't sufficient for other people, in that case you can either expand the ECS labels or start a new framework (with or without overlap).

[michael blunck]

@Hyronymus

Did you read my last post? Obviously not.

If gmyx wants to develop a different cargo framework then we should let him.

"We"? Everyone has the undisputable right to design/develop whatever he wants. And this right of him wasn´t disputed here in any way. However, the question remains if that´s a serious approach given that we already have a general extended cargo scheme which many vehicle sets implement.

If someone´s going to develop an incompatible cargo scheme o/c he has the right to do it, but he should also think about which vehicle and building sets would be compatible to it, or be prepared to develop these sets by himself as well.

Seriously, these are technical problems, it´s no "bla bla". I take it that this is your personal opinion and you´re not speaking on behalf of your moderatorship?

And maybe the labels in ECS aren't sufficient for other people, in that case you can either expand the ECS labels or start a new framework (with or without overlap).

Yes, you didn´t read my post.

regards
Michael

[wallyweb]

@moderators:
Shouldn´t the whole discussion moved into the usual ECS discussion thread?

Not necessarily. Although ECS is a significant part of this discussion, the potential and impact of other schemes seems to be the main focus of this topic. I think it would detract from the substance of the ECS thread.

[Hyronymus]

Why would my reply be aimed at just your post, Michael? Other people posted here too.

[Dave]

If someone´s going to develop an incompatible cargo scheme o/c he has the right to do it, but he should also think about which vehicle and building sets would be compatible to it, or be prepared to develop these sets by himself as well.

Personally I think that if a cargo scheme is compatible with at least some of the major sets it would be a viable alternative to ECS.

I take it your allegiance in terms of New Ships, DB Set, etc lies firmly with ECS?

[athanasios]

I think that if someone wants to create his own cargo set let him proceed if ECS bears limitations on his ideas.

What I would like to see is not a rival set but something fresh e.g. like the Mars mod for toyland or proposed future set on another planet.

Pikka has implemented some nice features in his sets. I suggest he cooperates with ECS team to include them there too. Why should you work in a separate set pikka? George is right. I am happy Michael will support ECS in his vehicle sets.

[Dave]

Pikka has implemented some nice features in his sets.

He has.

I suggest he cooperates with ECS team to include them there too.

This is what gets to me a bit. Co-operation is one thing, but why should Pikka suddenly start sharing all of his laborious fruits with the ECS team just because a few people want the same features in ECS? George is perfectly capable of implementing those features himself.

Why should you work in a separate set pikka?

Because unless you hadn't noticed, this place doesn't operate a "everyone do this" policy. People are entitled to develop whatever the hell they want - if it screws everything else up then fine; they need to produce the buildings, industries and cargo wagons to make it happen.

And besides, your argument is moot, because Pikka's industries comply with the ECS specification anyway, as I recall.

-EDIT-

And even if they didn't, that wouldn't give you a reason to start hounding him for them to do so. Pikka's industry* set worked perfectly well with several sets before he made them ECS compatible. The UKRSI worked with the UKRS, NARS, etc.

As I say, I don't think it is necessarily more productive to get every cargo set under the ECS umbrella.

* Or, rather, the cargos that are included in Pikka's industry set