Transport Tycoon Forums

The patchdevs (includeing me) think useing one GRF will reduce the support cost for TTDPatch A LOT, we can even warn the user if the grf isn't there.

If a feature isn't enabled the data is unused. (A grf doesn't enable switches)

A completly different point, you merge signals with dbsetxl, you moved from a single canals file (I wait since ages for it) to a include one in newshipsxl

So why we shouldn't do the same?


PS: I told Josef it would be wise to make files always lowest priority with some way, this resulted in the idea to make any grfid FFFFFFF file (blue ones) to always have lowest priority even if you put it at the end of the newgrf config... (If people have something against it please tell us now)

-edit-
The DBSetXL isn't anymore the only big set out there, so people aswell need to load signals, that means they need to atleast 10 grfs today. Don't get me wrong, I still play only with the DBSetXL because it simple rocks but I think there is a point to merge them (even if you put all the necessary stuff in your grfs to reduce the grf count to say 5 files)

michael blunck wrote:I see the benefits but IMO there are some drawbacks as well. Many people are using custom .grfs for elrails, foundations, signals, .... There may be even scenarios which need a special handling of its components like AlpineClimate, etc.

Since they're action 5's with GRFID=FFFFFFFF, any grf with a regular GRFID will override them, no matter whether they come before or after it in the cfg. I will also now extend this special handling to action 3 and action A, so the presence of this grf file will not stop any other grf file from working properly, no matter where in newgrf.cfg it is placed.

Josef, I understood that you wanted to have all these .grfs into one file (for downloading) but not into one single .grf?

Sorry, then I've not been clear. The main reasons I wanted to have these in a single grf file is a) less clutter in the GRF Status Window and b) easier to check if it's present and complete, and give an appropriate error message if not, and c) easier to give instructions on how to install missing graphics (instead of "I'm missing tram tracks" -> "download tramtrk.grf", "I'm missing canals" -> "download canals.grf" etc. there's only one possible answer for all of these).

I whole-heartedly agree with this, I've noticed quite a few people registering just to ask "how do I get tram tracks to show up" or "my electrified rails look the same as normal rails". If this GRF is released, these questions would hopefully become a thing of the past.

No. They´ll ask the same question as before but instead of "install tramtrk.grf in ttdpatch.cfg" the answer would change to "install newgrf.grf in ttdpatch.cfg".

The patchdevs (includeing me) think useing one GRF will reduce the support cost for TTDPatch A LOT,

Well, from my experience it´s a misbelief to think that reducing 10 files to 1 would cut support cost to 1/10. Especially not if some of those files would not be needed all the time.

we can even warn the user if the grf isn't there.

That can be done as well for 10 files. Conceptually, it´d be even more stringent because patch feature and additional graphics file come in pairs, usually. See my post above: "electrifiedrailways on" (action05 type 05) needs the associated file "elrails.grf" (or a better name, doesn´t matter conceptually).

If a feature isn't enabled the data is unused. (A grf doesn't enable switches)

Yes, I know, but that wasn´t the original question. Yours is addressing the implementation. I always thought that TTDPatch would be based on a modular approach?

A completly different point, you merge signals with dbsetxl,

DBXL has a special sort of semaphores.

you moved from a single canals file (I wait since ages for it) to a include one in newshipsxl So why we shouldn't do the same?

Because it´s not the same. Do you remember that we had that "one-file-fits-all" concept (ages ago)? It was called "ttdpatch.grf" (only including signals back then) and still can be found in many newgrf.cfg files! Which raises another point: I bet that the new file will be added to the existing "elrails.grf", "trkfound.grf", etc., pp. instead of replacing them.

PS: I told Josef it would be wise to make files always lowest priority with some way, this resulted in the idea to make any grfid FFFFFFF file (blue ones) to always have lowest priority even if you put it at the end of the newgrf config...

Yes, that´s a good idea but has been discussed before.

-edit-
The DBSetXL isn't anymore the only big set out there, so people aswell need to load signals, that means they need to atleast 10 grfs today.

I don´t understand? I only wanted to point out that there are

- many custom .grfs out there for special TTDPatch features (mainly action5 based), and
- there are some vehicle sets which include own graphics to override default TTDpatch action5-based .grfs.

The reference to the DBXL was just an example.

Don't get me wrong, I still play only with the DBSetXL because it simple rocks but I think there is a point to merge them (even if you put all the necessary stuff in your grfs to reduce the grf count to say 5 files)

I really don´t understand.

regards
Michael

michael blunck wrote:

I whole-heartedly agree with this, I've noticed quite a few people registering just to ask "how do I get tram tracks to show up" or "my electrified rails look the same as normal rails". If this GRF is released, these questions would hopefully become a thing of the past.

No. They´ll ask the same question as before but instead of "install tramtrk.grf in ttdpatch.cfg" the answer would change to "install newgrf.grf in ttdpatch.cfg".

Yes, but there would be less of them.
Oh, and last time I looked, newgrfs went in newgrf.cfg.

michael blunck wrote:

[mb] Even if those switches are set, any other .grf with the same functionality could do the job, and there are many alternative .grfs out there, be it for foundations, catenary, or whatnot.

And if they are loaded after this one, they will override it completely and without problems.

You say it. But if they´re loaded before, the usual hassle begins. And mind you, I´ve seen too much messy newgrf.cfg files.

One fundamental grf, the first a newcomer downloads, the first they add to their newgrf(w).cfg -- far less likely to cause "grfs wrongly overiding because stuff is out of order and I(newbie) don't understand why" problems, than half a dozen separate grfs, surely?

[mb] From a user´s point of view this would be easy and straightforward, easier than having to "struggle" with parameters or facing "problems" with overriding .grfs.

I'll say it again, there are no "problems" with overriding grfs, and there is no "struggling" with parameters.

Well, ATM, there´s only one of those .grfs using parameters but nothing guarantees that this will remain in the future.

And if that happens (can you forsee any circumstances where it might?) PikkaBird gets more overtime. I don't see any problem.

Michael, I'm really not sure why you're so opposed to this integrated grf. In my view, the problem overriding other graphics is solved (has been solved for action 5 long ago, next nightly/beta will solve it for action 3/A as well), the parameters are not a problem since they're entirely optional, the section of the grf corresponding to inactive switches will be skipped so no precious sprites are wasted, and it can only simplify both installation and usage as well as support.

The only reasons to not do this that I can think of are

• People always have to download a large file instead of only a few small files that they really need. But 316 KB isn't really large, so I don't think this is much of a concern, and eventually most people will try out most features, even if only briefly so they have to download the files anyway.
• Memory usage, since the whole file would always be loaded instead of being able to remove the unneeded ones. Not really a problem either.
• The artists are against it. If that's the case, please say so and we can remove your graphics from the integrated file.

What other reason not to do it would there be?

michael blunck wrote:

I whole-heartedly agree with this, I've noticed quite a few people registering just to ask "how do I get tram tracks to show up" or "my electrified rails look the same as normal rails". If this GRF is released, these questions would hopefully become a thing of the past.

No. They´ll ask the same question as before but instead of "install tramtrk.grf in ttdpatch.cfg" the answer would change to "install newgrf.grf in ttdpatch.cfg".

But the fact that this also gives them all the other graphics will mean that a) if they ask for "tram tracks, canals and el.rails", we only need one answer and they only need to install one thing, and b) they aren't going to come back and ask "ok I've got canals now but what about el.rails" five minutes later.

The patchdevs (includeing me) think useing one GRF will reduce the support cost for TTDPatch A LOT,

Well, from my experience it´s a misbelief to think that reducing 10 files to 1 would cut support cost to 1/10. Especially not if some of those files would not be needed all the time.

Even if it's not reduced by 10:1 but only 2:1 it would be good. Less work for us, less work for the user.

we can even warn the user if the grf isn't there.

That can be done as well for 10 files.

Yes, but the patch can only show one red error message at a time. If all 10 files are missing, the user would find out about them one at a time or be told "some graphics are missing, go install them" which would be even less useful.

With a single file, it's also a lot more viable to have some kind of versioning system, where the patch notices if the grf is outdated and notifies the user accordingly.

PS: I told Josef it would be wise to make files always lowest priority with some way, this resulted in the idea to make any grfid FFFFFFF file (blue ones) to always have lowest priority even if you put it at the end of the newgrf config...

Yes, that´s a good idea but has been discussed before.

For action 5... not for action 3/A, which now implement this as well.

I don´t understand? I only wanted to point out that there are

- many custom .grfs out there for special TTDPatch features (mainly action5 based), and
- there are some vehicle sets which include own graphics to override default TTDpatch action5-based .grfs.

I don't however see how that's relevant to this discussion. These grfs will continue to work as before, no matter whether the patch graphics are in one single file or distributed over a dozen files.

Which reminds me, does this new file uses Action5 for canals? As this code is long dead (not used anymore) and switched to Action321 system, the file doesn't need to carry Action5 canal sprite anymore...

-edit-
And the 0C code comments can be removed aswell

Patchman wrote:

michael blunck wrote:

I whole-heartedly agree with this, I've noticed quite a few people registering just to ask "how do I get tram tracks to show up" or "my electrified rails look the same as normal rails". If this GRF is released, these questions would hopefully become a thing of the past.

No. They´ll ask the same question as before but instead of "install tramtrk.grf in ttdpatch.cfg" the answer would change to "install newgrf.grf in ttdpatch.cfg".

But the fact that this also gives them all the other graphics will mean that a) if they ask for "tram tracks, canals and el.rails", we only need one answer and they only need to install one thing, and b) they aren't going to come back and ask "ok I've got canals now but what about el.rails" five minutes later.

My point exactly.

Michael, I'm really not sure why you're so opposed to this integrated grf. [...]

Josef, I´m in no way "opposed" to it, at least not "so". I´ve only raised some proper questions which led to some further improvements, which is a good thing, IMO.

I will also now extend this special handling to action 3 and action A, so the presence of this grf file will not stop any other grf file from working properly, no matter where in newgrf.cfg it is placed.

That´s a good thing and it´ll remove most of the problems I was thinking of. The other good argument I´ve heard from you is that having only one file would give "less clutter in the GRF Status Window". (Although I´ve seen newgrf.cfgs holding more than 100 .grfs )

Anyhow, I still think that in principal the more modular, flexible, efficient, and user-friendly solution would be to have a set of individual and properly defined files than having one large single file addressing entirely different tasks - but due to TTDPatch´s limitations (e.g. error message handling) it could well be that this cannot be implemented as easily.

The artists are against it. If that's the case, please say so and we can remove your graphics from the integrated file.

That´s not the reason. I gave you allowance to "integrate them" into one large downloadable file and this holds as well for that new "unified" .grf approach.

@eis_os

Which reminds me, does this new file uses Action5 for canals?

I already told you that canals in NewShips XL don´t use action05s.

And the 0C code comments can be removed aswell

I don´t use this, you may talk to George, though.

regards
Michael

Some of the grf's I coded do use 0C (so the other person could try to maintain it), so I'm against removing 0C...

~ Lakie

Action 0C should not (must not?) be removed from the newgrf spec. On the other hand, no action Cs should appear in any release GRFs.

The latter is what I thought was being discussed.

Maybe an option could be added to grfcodec / nforenum then to not process / comment out ActionC for full releases?
[edit] ok, well why shouldn't they be in a released grf?

~ Lakie

I don't really like that idea, because it can break counted action 7/9 jumps.

...And because it would require that (if grfcodec stripped the 0C's) grfcodec change sprite 0, something that I'd rather leave in nforenum's camp.

I left the action 0Cs in the canal block (which is from George, AFAIK) because I was too lazy to remove them. It's a straight copy and paste from the grf on the patch website, so they do use actions 2 and 3.

I will ask Josef on IRC if there's anything else needs to be changed in the file.

Who said that 0C should be removed from the specs?!!? I only said that the <patch>.grf doesn't need to have them to reduce even more the size of the file. Hopefully thats now clear...

dos version is fine

I was sure that was what you said, Oskar, but it sounded to me like there might be some confusion, so I attempted to clarify.