Page 3 of 3
Re: Heading for grf version 8
Posted: 03 Mar 2009 04:33
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
From the current discussions I suppose it is planned for coding by frosch. Michael already posted you his proposal.
Re: Heading for grf version 8
Posted: 03 Mar 2009 20:08
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.
Re: Heading for grf version 8
Posted: 04 Mar 2009 04:15
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 - ?
Re: Heading for grf version 8
Posted: 02 Jun 2009 12:41
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.
Re: Heading for grf version 8
Posted: 02 Jun 2009 21:03
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.
