Heading for grf version 8

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

User avatar
George
Tycoon
Tycoon
Posts: 4364
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: Heading for grf version 8

Post by George »

DaleStan wrote:
George wrote:They are different vehicles. But they are not irrelevant, because they are are joined with CB 16.
Not until after the purchase action.
This is why, among other things, there were a lot of bugs related to capacity-in-purchase-list a while back.
George wrote:Dale, what are trying to achieve? To say ... That it is impossible in general? Me doubts.
Then you needs to produce code that proves otherwise. "Code" as in "C++" or "x86 assembly", not as in "NFO".
I do not have to produce any C++ code to doubt :roll:
From the current discussions I suppose it is planned for coding by frosch. Michael already posted you his proposal.
Image Image Image Image
frosch
OpenTTD Developer
OpenTTD Developer
Posts: 991
Joined: 20 Dec 2006 13:31
Location: Aschaffenburg

Re: Heading for grf version 8

Post by frosch »

Uhm, that is an old version, also it misses exploring the differences when using dualheader, wagonoverridden and articulated engines.
And as I said before: I decided against changing refittability by callback. (which was still part in that WIP concept)


Also, george: Wrt. your refit mask problem, the easiest solution seems to be supporting articulated parts with id >= 0x80. Everything else would IMO just be a waste of time, as it looks too complicated to be used when id >= 0x80 are available.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
User avatar
George
Tycoon
Tycoon
Posts: 4364
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: Heading for grf version 8

Post by George »

frosch wrote:Also, george: Wrt. your refit mask problem, the easiest solution seems to be supporting articulated parts with id >= 0x80. Everything else would IMO just be a waste of time, as it looks too complicated to be used when id >= 0x80 are available.
Fine, let's do it this way.
Also, what about XOR problem? To split it to + and - ?
Image Image Image Image
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Heading for grf version 8

Post by planetmaker »

I'd like to propose a versioning scheme for newgrfs. Currently versioning can only be done via the grfID - if it differs newgrfs are considered incompatible. But there are numerous cases (actually the vast majority) where the grfID is (and should) be retained: a bug fix release or adding some features to an existing newgrf, such that backward compatibility isn't broken. But if a save has to choose a newgrf from the grfID, and it finds several instances, but not the matching md5, it then should use the one with the highest minor version (same basically like for basegrfs).

This might be an extension of action 8 (not sure how well that might integrate there) or just a new action.
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5705
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: Heading for grf version 8

Post by andythenorth »

planetmaker wrote:I'd like to propose a versioning scheme for newgrfs.
Would be useful. Facing down this exact problem right now. Got a hard-to-replicate-consistently bug with saved games after a minor fix to HEQS. It's irritating, but not a show stopper. If I don't bump the filename, players can't keep the old grf around for save games (and I lose track of versions). If I bump the GrfID I break saved games, and I have to update documentation. :?
Post Reply

Return to “Graphics Development”

Who is online

Users browsing this forum: No registered users and 6 guests