Transport Tycoon Forums

Hi
I have little problem I thought Ill try Your new industries ver 0.10 on TTDPacth and I did get an error message (see picture). I'm using latest nightly! Older version what I once tried worked fine, but that one don't! Is it suppose to work or maybe not?

Hmm.. everything is supposed to work in TTDPatch too, not only OpenTTD, I'll give it a look. BTW, which version of newIndustries do you use?

Latest one whats posted here few page back! It was version 0.10 I think!

Edit: Yes it was that one

Hmm.. haven't got TTDPatch available just now (and cba to install it either atm/haven't got time either) but Idecoded that grf and sprite 377 is :/ :/ and So I have absolutely no idea what's going on :/ DaleStan?
And

I'm using latest nightly!

what is the revision (latest isn't a number )
And can you test if it works with older TTDPatch revisions? I guess that

Older version what I once tried worked fine, but that one don't!

is aboutthe grf not TTDPatch?
?

Code 1/0 means that a real sprite is encountered where a pseudosprite was expected.
The problem is this: Line 375 skips just the action A if the climate is not arctic. Not only the action A should be skipped, but the following 7 real sprites as well! Same problem exists on line 366 and 384.

Here's a bugfix release of version 0.10:

hehe, I knew I should have put it through renum too

Well that's embarrassing.

Since I made the same mistake on the headquarters grf, here is the fixed version: I've said it before and I'll say it again; It's a miracle anything I code works at all.

Sorry.

(In my defense, renum doesn't throw up any complaints. That's still no excuse for sloppy coding though)

Thank You works fine but seems like oil rig don't have right graphics some how?!?!

does it look like this?

FooBar wrote:does it look like this?

No, its an old one!

FooBar wrote:does it look like this?

Waitamoment... *lookingatthehelipad* - where are the blinking lights? Have I forgotten to add them in the final version?

buttercup wrote:In my defense, renum doesn't throw up any complaints.

Indeed. NFORenum won't catch that. It probably should, but it won't.

OpenTTD definitely should, though.

DaleStan wrote:OpenTTD definitely should, though.

No, it shouldn't. It should just ignore erroneous real sprites. I remember this from the wiki: "It's generally not an error to provide more real sprites, but it expenses sprite slots" or something like that. I can't remember if that's on the action 3, 5 or action A page. If it's not an error to provide more sprites in combination with those actions, it shouldn't be an error to provide real sprites without an action.

FooBar wrote:If it's not an error to provide more sprites in combination with those actions, it shouldn't be an error to provide real sprites without an action.

And, in the same way, it's not an error (In OpenTTD, anyway) to specify property 05 for stations (undefined, and therefore extraneous) so it shouldn't be an error to just have property 05 all by itself, without an action 0 header.
Or maybe more precisely, it's not an error to add extraneous bytes to the end of an action 0, (this is true in both games) so it shouldn't be an error to have those bytes existing all by themselves. Even if the first of those extraneous bytes is a 01, 05, 0A, 11, or 12.

Either way, I don't think your logic works.

Maybe we have different logics Mine is this:

An action is a (pseudo)sprite.
A real sprite is a (real)sprite.
So everything is sprites.
Some extraneous bytes are no sprite.

The game reads these sprites and knows what they are supposed to do. If the game encounters (and recognises!) some realsprites without an action defining what to do with those sprites, it could as well just ignore them without bothering the end user with errors and such. That's why we have debuggers, to check code against the book.


Take Windows for example. That's full of bugs, but still works (more or less). Should Windows report every bug to the end user and then abort? No. Running the windows code through a debugger should unveil each and every bug in the code. It's just that Microsoft doesn't have a debugger for it's code


I think the difference between Patch and Open is that Patch does include a grf debugger, and Open does not. Patch gives you an error indicating what's wrong. Open will just crash if a grf is really buggy, otherwise it will just ignore (parts of) the faulty grf.

FooBar wrote:An action is a (pseudo)sprite.
A real sprite is a (real)sprite.

OK, so let's try this one then.
It is not automatically an error to append this sprite: to the end of an action 5 block. Therefore that sprite should be ignored if it appears outside an action 5 block.

Or, if you prefer, this sprite: It's not automatically an error to append that to an action 5 block either. So it should be ignored when it isn't in an action 5 block.

I guess I'm still not understanding your logic.

FooBar wrote:Open will crash if a grf is buggy

and this is a feature?

DaleStan wrote:It is not automatically an error to append this sprite:

If that's a valid action 0 (I haven't checked), than yes. Otherwise no. The realsprites in the opengfx industries were also perfectly valid by themselves, but just not used.

DaleStan wrote:Therefore that sprite should be ignored if it appears outside an action 5 block.

No it shouldn't. You may provide extraneous real sprites, not pseudosprites.

I think that makes the difference then. The game knows that a real sprite can't be used without an action referencing it. A realsprite always needs an action referencing it in order to function, so if there's no reference, it could as well be skipped. An action 0 (or 8 for that matter) does not need something referencing it, so it should never be ignored.

Is it an error to provide unused (but by themselves perfectly valid) Action 2's?

FooBar wrote:

DaleStan wrote:It is not automatically an error to append this sprite:

If that's a valid action 0, than yes. Otherwise no.

That is a valid action 0. It is also a valid recolor sprite. All recolor sprites are valid action 0s, basically by definition.

FooBar wrote:

DaleStan wrote:Therefore that sprite should be ignored if it appears outside an action 5 block.

No it shouldn't. You may provide extraneous real sprites, not pseudosprites.

And where does it say that, please? Only thing I can find merely says "sprites".
Action 5 data blocks may not contain more sprites than specified by the action 5. The action 5 may supply more sprites than required by the host, but the data block must contain exactly as many sprites as the header says it contains. No more and no less.

FooBar wrote:Is it an error to provide unused (but by themselves perfectly valid) Action 2's?

Used or unused, all sprites must be
1) Internally consistent. (An action 5 that is only two bytes long is automatically not valid.) and
2) Consistent with all preceding sprites. (An action 2 that references a CargoID or sprite set that has not been defined is not valid.)

This hold for all sprite types: Pseudos, Reals, Recolors, Includes, and Imports.
So, does the action 2 satisfy both conditions? If so, it is valid.
In the same way, the real sprite is only valid if it is 1) properly compressed, and 2) consistent with the preceding data-block header.

Well, I can make it say that, but that would be silly

DaleStan wrote:Action 5 data blocks may not contain more sprites than specified by the action 5. The action 5 may supply more sprites than required by the host, but the data block must contain exactly as many sprites as the header says it contains.

I agree to that, as that's exactly what it says on the action 5 page:

The number of sprites that follow.
Note that it is not generally an error to provide more sprites than required, but this does expend sprite slots unnecessarily.

DaleStan wrote:...
In the same way, the real sprite is only valid if it is 1) properly compressed, and 2) consistent with the preceding data-block header

I also agree to that. If it comes to code, it's faulty if it isn't written by the book.



When it comes to a code interpreter (like Open in this case), I think it's completely legal for such an interpreter to be smarter than the book. And that would be my logic then.
Let's go back to the old erroneous code: As a human I read there: "Well, if the climate is not arctic, then the game will skip the next line, which is an action A replacing some sprites, so if it skips that action A it ends up with a bunch of real sprites. Now that's wrong, some real sprites all by themselves. They shouldn't be there, let me fix that *counts number of lines* eight lines. Hey, eight in hex is easy, let me fix it right away. *changes 01 in 08* *hits ctrl+s*"

A code interpreter usually isn't as smart as a human, but it should know the rules from the book. It might as well know something on top of that. A good example to illustrate the opposite would be Internet Explorer: it knows something on top (how to deal with crappy frontpage code), but not the book (incomplete css support). If IE would know the whole book plus how to deal with crappy frontpage code, it would be the perfect browser as it can display every page out there correctly.

Now back to the example code above.
The way I see it, Open processes that fragment as follows:
375 recognises Action 7, should check var 83 *wanders of to get the value of var 83, returns*, picks first byte of var, compares to value 01, concludes it's not equal, skips next sprite
376 *doesn't even check what the sprite is about*
377 Doesn't recognise legal action; does not attempt to process, does not issue error, skips to next line
378-383 (same as previous line)
384 recognises action 7, might be valid, continue processing... etc.

To conclude this: I think we both agree that the code from the fragment above is not valid. It just isn't according to the specification. When it comes to the parser, I think it's fine if it tries to skip things it doesn't understand to see if there's something else it does understand.

Let's go back to the browser example one more time. It can be any browser now. According to w3c specification, a html document should start with the <html> tag (well, actually a doctype, but even google omits that). Now if a document doesn't start with <html> (i.e. invalid code), should the browser issue an error and terminate processing the page, or should it assume [0] a html document and continue processing to see if there's something that it does understand?

Now that's my logic. I don't have to be right, I just want you to understand my logic and maybe conclude that my way of thinking could be valid as well[1].



[0]The headers send by the server indicate a html document, so the browser knows it should use the html parser.
[1]At least I think it's valid.

FooBar wrote:Let's go back to the browser example one more time. It can be any browser now. According to w3c specification, a html document should start with the <html> tag (well, actually a doctype, but even google omits that). Now if a document doesn't start with <html> (i.e. invalid code), should the browser issue an error and terminate processing the page, or should it assume [0] a html document and continue processing to see if there's something that it does understand?

If you insist on using this analogy, I think it should be pointed out that web browsers being so forgiving of bad markup is partially, perhaps even mostly, responsible for the truly appalling state of standards-compliance of web pages. Do you really want to sentence GRF creators to the same hell as web developers have been living for the past 10 years?

From a programming perspective, the issue in question - extraneous sprites - should probably raise a warning (during compilation and/or interpretation), rather than an error or being ignored altogether.
If you permit mistakes without comment, people will not know that they've done anything wrong.