Transport Tycoon Forums

epsilon wrote:Hey,

I was once involved in developing a patch for slightly extending the existing industry chain. Could someone quickly fill me in on the status of this? Is it done? Will it be done? I'm a bit too lazy to search the posts from the last 10 months or so...

TIA

If it's abandoned and/or waiting to be done I might be willing to volunteer to help.

Born Acorn wrote:

epsilon wrote:Hey,

I was once involved in developing a patch for slightly extending the existing industry chain. Could someone quickly fill me in on the status of this? Is it done? Will it be done? I'm a bit too lazy to search the posts from the last 10 months or so...

TIA

If it's abandoned and/or waiting to be done I might be willing to volunteer to help.

It would be easier to implement the newgrf feature newindustries from TTDPatch, so people can use their own industry set etc, but with only a few working on newgrf, its progressing slowly.

Born Acorn wrote:I meant the design factor. If we were to implement a new industry system, it would require months of planning testing and balancing to make a good system. But with the newgrf newindustries, you choose your own set.

Korenn wrote:

Born Acorn wrote:It would be easier to implement the newgrf feature newindustries from TTDPatch, so people can use their own industry set etc, but with only a few working on newgrf, its progressing slowly.

I don't know if it would be easier... not in the long run probably.
It would probably be faster though.

DaleStan wrote:

Korenn wrote:

Born Acorn wrote:It would be easier to implement the newgrf feature newindustries from TTDPatch, so people can use their own industry set etc, but with only a few working on newgrf, its progressing slowly.

I don't know if it would be easier... not in the long run probably.
It would probably be faster though.

I'd say that it's harder in the short run but easier in the long run.

In one go, you can implement ECS, in all of its near-infinite configurations, Pikka's UK Renewal Industries, and every other industry and cargo set that will ever be thought up.

Korenn wrote:and then you're left with horrible spaghetti code that no-one can read, slowing down any further patches considerably.

Patchman wrote:It seems to me like there are really two options here:

1. Write a program that takes your "plain text" spec file and converts it to NFO, then use the already-(mostly-)working NFO support in OTTD and be done. [1]
2. Write a program that takes your "plain text" spec file and converts it to some other, yet-to-be-specified easily computer-readable format. Then start from scratch implementing this format (which for NFO took many, many months and won't be significantly faster no matter how nicely you design your new one), fixing bugs, redoing the specs because you find things you need to do that can't be done, restart coding yet again, fixing the limitations of specs. Deal with the headaches of supporting two incompatible formats internally (unless you want to drop support for all existing graphics). Repeat as necessary.

My point is, why not use a format that works, can do just about everything that needs to be done[2], that there are many people out there who know how it works, and that OTTD mostly supports already? Why bother making all the mistakes that TTDPatch made all over again in a new design?

I'm not saying NFO is perfect. It has warts, and some things aren't designed as cleverly or cleanly as they could've been (because it's a grown design that grew as artist's demands increased). However, it is very simple for doing simple things (you can make a new train with four or five lines of very simple "code". It can get very complex too, but only when complex things need to be done. You cannot remove the complexity without losing its power and sophistication. Any new design will need to be just as complex if it needs to be able to do what NFO can do[3].

If the hex-ness of NFO is the only thing that bothers you, then it's the only thing that needs fixing. This means either improving/fixing GRFMaker, or writing a "plain text"->NFO converter. A variation of the latter would need to be written even if you come up with your own format.

So why not NFO?

[1] Whether the graphics are 8bpp or 32bpp or 256bpp does not matter here. The way sprites are encoded in the file is irrelevant. NFO can work just as well no matter what type of sprites you have. [It doesn't even matter if you have 3D meshes and no sprites at all -- DaleStan]
[2] And can relatively easily be extended to support new things.
[3] For example Locomotion has a very simple format. As a result it can only do simple things. No repainting of wagons after N years to show a new historical livery. No showing of dirt as vehicles get older. No random variations in colours. No seasonal cargo acceptance/production of industries. No sophisticated animation control. No sophisticated station designs. No simple support for trainsets, other than defining a new vehicle ID for each loco and each wagon in each train set. Etc...

Born Acorn wrote:If we were to implement a new industry system, it would require months of planning testing and balancing to make a good system. But with the newgrf newindustries, you choose your own set.

So - what do you think about this? Should I take care of this matter with the graphics authors and implement some extensions or do we wait for newgrf support and leave this be?