NewObjects specification

[wallyweb]

As I am a TTDX player, I'm not set up to code my work under OTTD.

OpenTTD and TTDPatch should behave the same as they implement the same specs. The changes made to the old spec can be found at the bottom of my first post. It's basically callback 147 that got changed. Should be relatively trivial to update; the latest NFORenum will actually catch that 147 isn't used for objects anymore. You need to set a bit in a callback flags property to enable it though.

Hmm ... We may have a problem Houston! I upgraded my patch to r2339. I added the new properties (11 +) to my code. I now get a fatal error loading the grf. Apparently TTDPatch hasn't been told about the new properties ... or I've botched something.
I've attached two zips containing files suitable for testing.
The first one, dam_2338, works as expected under TTDPatch, pre-upgrade.

dam_2338.zip

original nfo code, grf and png image

(21.49 KiB) Downloaded 183 times

The second one, dam_2339, fails in both pre and post upgrade with a fatal error in the properties section (Unknown property 11). Perhaps someone could try the grf in OTTD to see if the problem follows.

dam_2339.zip

added proerties 11 + to nfo and grf

(10.75 KiB) Downloaded 190 times

In both cases, the graphics feature animations which change approximately every 6 TTDX days.
DISCLAIMER The graphics are a work in progress and no claim is intended or made as to the quality of the artwork. It is highly recommended not to include these in a permanent newgrf file or repository as they will chage.

[Rubidium]

Okay, fiddling with it I've found a few issues with your code. See the attached diffs. I'm not sure about all changes, but some things are definitely wrong.

First: you define 15 properties, but say you define only 14 in the NFO (the fatal error).
The next thing is the object size, which *might* be incorrectly implemented in OpenTTD. I'll do some more research about that. Although my assumption is that it is implemented correctly in OpenTTD as later on (sprite 73) you're using offsets 00-04 and 10-14 which would imply 25 is the right one.
After that the object flags are incorrect if assuming the *s mean that you want to have that enabled. It's a bit big in the diff because I added 0s and 1s so I could easily make a string and run that through a binary->hexadecimal converter.
The fourth wrong thing seems to be the slope callback. The specification declares the slope bits to be 8..15, but you look at 0..7. Shifting the bits by 8 fixes the problem.
Finally you're checking for callback 149 whereas you should check for callback 157.

In second batch I'm tackling the animation problem. There are basically two parts to this. First of all you need to actually enable the animation on the tiles you want to have animation (via callback 159). As I don't know which tiles exactly I just mark all tiles for animation. These are sprites 60 and 61 plus a modification to sprite 75. If you change that the animation still doesn't work but that is due to the fact that you shift the result of variable 43 by 6. With the first 8 bits being the animation frame and your maximum animation frame being 3 that will always return 0. When I change the 6 to a 0 I'm getting animation!
Finally you talk about animation speed 6*27ms=42ms in the properties. This should be something like (2**6)*27ms=64*27ms=1728ms (or in OpenTTD's case 1920ms, yes our ticks are 3ms longer).

Furthermore I'd like to ask you a small favour. Could you add

Code: Select all

    1 * 16	 14 "C" "INFO" "B" "PALS" \w1 "W" 00 00

before your action 8. That way you'll tell OpenTTD that it uses the Windows palette and I don't have to press "toggle palette" (as I'm using the original DOS graphics).

Attached as well is a version that works for OpenTTD. I've elongated the animation speed to ~6 days (more like almost 7) as you described in your previous post. It also contains the Action14 bit I was talking about before.

[wallyweb]

...

Thank you. Much appreciated. I had found a couple of the errors you mentioned while I was at home, but you found a few more items for me to work on and I thank you for this. I'll be sure to add the OTTD palette code as well. Should I make it a part of my template for regular inclusion?
I've downloaded the files you attached and I'll look at them when I return home. (No internet access at home is such a bother). Thanks again.

[planetmaker]

I'll be sure to add the OTTD palette code as well. Should I make it a part of my template for regular inclusion?:D

If you draw always using the windoze palette, then it will be helpful to always include that, yes, as it ensures that automatically the correct palette will be chosen; it will make your newgrf incompatible with earlier TTDP versions (EDIT correct conclusion:) which will disable the GRF, if an action14 is found.

[wallyweb]

A while ago I started a discussion on Object Class labels over here.

It now would seem that this is a more appropriate topic to continue this discussion.

I do not feel that the labels should be set in stone. A "recommendation" would seem more appropriate.

1. There is a limit on the number of objects, currently 255.
2. It is possible to have a label for each object. This would make for a very ungainly menu.
3. A labeling system allows a coder/author to make their works much more user friendly.
4. To keep the numbers more manageable, the classes should be as generic as possible.
5. While being generic, assigning objects to a label should be intuitive.
6. Assuming that there will be special circumstances where a coder/author needs to deviate from the norm, the classes/labels should not be mandatory, but rather be a "Recommendation" (Along the lines of W3C) with the coders/authors being encouraged to support user friendlyness.

Here are my current proposals for a "Recommendation" for Action0 - Property 08:

TTDX - TTDX's default copywritten objects - lighthouse, communication tower, rocks, land (temperate, arctic, tropical), headquarters ... - Could be a candidate for inclusion in ttdpbase(w).grf
OTTD - OTTD's default OpenGFX objects - lighthouse, communication tower, rocks, land (temperate, arctic, tropical), headquarters ...
STRU - Stuctures - multitile engineered objects that don't quite fit in as industries, houses or stations - dams etc.
INFR - Infrastructure - lightpoles, communication towers, transmission towers, road signs ...
BLDG - Buildings - would normally be accomodated by industries, houses or stations but the author feels there are limiting circumstances (George and Andythenorth have used up all the industry slots) (Michael wants a chalet atop Mont Blanc) ...
NATR - Natural objects - caves, coral reefs, swamps ...
PARK - Public communal areas - Parks, statues ... would normally be accomodated by towns or industries (tourist stuff ...) but the author feels there are limiting circumstances.
ARTF - Artifacts - shipwrecks ... - they really don't fit under any of the above
TEST - Developer - For the author who wants to test/develop a graphic before commiting/coding it to another <feature>
MISC - Miscellaneous - For the author who is unable to accommodate his/her object under any of the previous labels.

[Lakie]

Personally, the TTDX and OTTD tags are effectively the same, and are only separated by graphics (which in OpenTTD can be toggled anyway).
Also I do not believe rocks and land (snow, desert, etc.) are truly objects, the latter affects gameplay and objects imitating them could confuse users in multiplayer games (OpenTTD).

Also, I'm not sure of where this idea of there being a hard limit of 255 object types keeps surfacing from, it is a soft limit of 400 in TTDPatch (with any one grf being able to define up to roughly 256*).
* Assuming that the system doesn't allow extended byte, if it does, it could be the full 400.

~ Lakie

[SAC]

Also, I'm not sure of where this idea of there being a hard limit of 255 object types keeps surfacing from, it is a soft limit of 400 in TTDPatch (with any one grf being able to define up to roughly 256*).
* Assuming that the system doesn't allow extended byte, if it does, it could be the full 400.

~ Lakie

Hmm, interesting! This would be great to know for sure...

[FooBar]

Maybe DFLT for the default lighthouse and transmitter (in both games)?

[eis_os]

Didn't I wrote in my initial specs the default labels for lighthouses and transmitters
And adding TTDP or OTTD is totally wrong. It's the category an object is in, not a compatibility flag.

TTDPatch should successfully handle 400 active objects, you can see 100 Classes...
(255 entries per Class is a gui limit and can't changed, currently TTDPatch seems to support only 100 entries)

You can't have more then 256 objects per grf (no extended byte support there),
400 objects per grf would be the hard limit anyway, as we can only handle 400 textids per local GRF.

Sum up:
400 active objects in all newgrfs
only 100 classes
only 100 entries
not more then 256 grfs for TTDPatch.

Note: Every sprite counts, you will hit the sprite count earlier then the newobjects implicit id limit.

[michael blunck]

[object "labels"]

From a technical point of view, "labels" for newobjects are rather useless, unlike cargo labels. Only function they could serve now is to group object entries into the same (sub-) menu (of the GUI). Now, I didn´t see that behaviour accepted for new stations, why should it be accepted by authors designing newgrfs for objects?

regards
Michael

[FooBar]

This "label" is actually a class, pretty much the same as station classes. So no difference there, thank you.

Didn't I wrote in my initial specs the default labels for lighthouses and transmitters

The specs state that there are no default labels

Unlike station classes, there is currently no default yet, planned are TRNS for transmitters and LTHS for lighthouses.

[eis_os]

This "label" is actually a class, pretty much the same as station classes. So no difference there, thank you.

Didn't I wrote in my initial specs the default labels for lighthouses and transmitters

The specs state that there are no default labels

Unlike station classes, there is currently no default yet, planned are TRNS for transmitters and LTHS for lighthouses.

grr...


"TEST" is a a epic fail too, we get a ton test grfs then...

Note: Currently all new variables will return zero in TTDPatch as far as I see in code...

[FooBar]

grr...

Might I suggest you going ahead and making the classes TRNS and LTHS actually default then (in the spec)? That way you don't have to be annoyed by people (like me initially) that think something else would be better as default

Maybe also add MISC as a default class and be done with that. I don't think there's a need for a full comprehensive list of default labels. Stations don't have that, Railtypes (labels in this case, not classes) don't have that either and for stations that worked out fine and I'm sure that will work out fine for Objects and Railtypes as well. As soon as a grf developer needs a new class, he or she can invent one. Keeping a list of previously-defined classes with a short description might be useful: as soon as one needs a new class an new class is invented and added to the list. All future authors can then pick a class from the list or define a new one if there's no suitable class available.
This way, the "recommendation" will evolve naturally without having to think of all possibilities now.

[wallyweb]

I have noted all the comments. My first response addresses my TTDX and OTTD suggestions. If you check the original development thread for newobjects, you will see that my concern was the inability to build the default TTDX objects (Lighthouse, Transmitter, Rocks, etc.) while in a game. They were only available in the scenario editor. Because they are protected under the original TTDX copyright, I thought it prudent that they should get their own class. The OTTD suggestion was as a courtesy to the OTTD players who might want something similar, even though they are not bound by TTDX's copyright.

My next concern is that of a rather long and cumbersome menu. That is why I suggested "Recommendations". As Michael pointed out, they are merely a means "to group object entries into the same (sub-) menu (of the GUI)". A good word for this would be "organization".

"TEST" is a a epic fail too, we get a ton test grfs then...

We shouldn't if the coder/author keeps to the spirit of "test" and reserves them for his/her own use and does not release them. Actually, this one could be eliminated. The author/coder can figure out for themselves what to do for their development projects.

And now a question ... Most newobjects will probably be coded as individual grf's. I can see a player assembling a rather large group of these grf's. How does one handle it if each one of those grf's has it's own class label? Wouldn't it be better to give the author/coder the option of a rather generic guideline to follow?

And why all this comparison with how stations do it? These are not stations.

Newobjects was supposed to be something simple for the player to use to dress up his game. They were not intended for competitive server games. Caveat Emptor on that one. Hopefully we can keep newobjects to their original simple intention.

[wallyweb]

And now my reply to rubidium's most hepful comments:

Okay, fiddling with it I've found a few issues with your code. See the attached diffs. I'm not sure about all changes, but some things are definitely wrong.

First: you define 15 properties, but say you define only 14 in the NFO (the fatal error).

- Fixed

The next thing is the object size, which *might* be incorrectly implemented in OpenTTD. I'll do some more research about that. Although my assumption is that it is implemented correctly in OpenTTD as later on (sprite 73) you're using offsets 00-04 and 10-14 which would imply 25 is the right one.

- Fixed ... 25 is right. 2338 was correct, 2339 was wrong.

After that the object flags are incorrect if assuming the *s mean that you want to have that enabled. It's a bit big in the diff because I added 0s and 1s so I could easily make a string and run that through a binary->hexadecimal converter.

- Fixed - I had the wrong value for bit 11 ... It should have been 2048, not 2028.

The fourth wrong thing seems to be the slope callback. The specification declares the slope bits to be 8..15, but you look at 0..7. Shifting the bits by 8 fixes the problem.

- Fixed - But the CB157 specs read:
"Please note that for Objects only the low byte of variable 18 is valid (Offset from north tile (origin), stored as YX)"
"bit numbers 0..7 - offset of current tile on the platform, 0 is the northmost tile"

Finally you're checking for callback 149 whereas you should check for callback 157.

- Fixed

In second batch I'm tackling the animation problem. There are basically two parts to this. First of all you need to actually enable the animation on the tiles you want to have animation (via callback 159). As I don't know which tiles exactly I just mark all tiles for animation. These are sprites 60 and 61 plus a modification to sprite 75. If you change that the animation still doesn't work but that is due to the fact that you shift the result of variable 43 by 6. With the first 8 bits being the animation frame and your maximum animation frame being 3 that will always return 0. When I change the 6 to a 0 I'm getting animation!

Finally you talk about animation speed 6*27ms=42ms in the properties. This should be something like (2**6)*27ms=64*27ms=1728ms (or in OpenTTD's case 1920ms, yes our ticks are 3ms longer).

Under TTDPatch r2339:
- dam_2338.grf loads ok but it continues to not support building on slopes.
- dam_2339.grf passes NFORenum without issue but when starting a TTDPatch game,
TTDPatch r2339 produces the following error:
""File "newgrf\dam_2339.grf" has invalid sprite #3 (code 6/36)""
NewGraphicsSpecs Sprite Errors says that code 6 means the given property number in action 0 is invalid and points to the byte in the sprite that follows the one which triggered the error. 36 is property 11.

Furthermore I'd like to ask you a small favour. Could you add

Code: Select all

    1 * 16	 14 "C" "INFO" "B" "PALS" \w1 "W" 00 00

before your action 8. That way you'll tell OpenTTD that it uses the Windows palette and I don't have to press "toggle palette" (as I'm using the original DOS graphics).

- Done

Attached as well is a version that works for OpenTTD. I've elongated the animation speed to ~6 days (more like almost 7) as you described in your previous post. It also contains the Action14 bit I was talking about before.

It also fails under TDPatchr2339, as noted above.

dam_2338.grf does not reference Action 0 properties after property 10. This was intentional so as to test for backwards compatibility for newobject grf's that pre-exist r2339. All that was required was to change CB149 references to CB157. Unfortunately, it will need to reference Action 0 property 15 for this to work.

dam_2339.grf does include reference to the new Action 0 properties. Unfortunately, TTDPatch r2339 does not seem to know about them and returns a fatal error when starting a game.

Conclusion: TTDPatch coders should stay with r2338 until this is resoleved.

The diffs and your grf add the following code:

Code: Select all

61 * 10	 02 0F 2C 81 1A 00 FE 00 1F 80
// Action 2 - Return to graphics
   62 * 17	 02 0F 2D 85 0C 00 FF FF 01 2C 00 59 01 59 01 1E 00

This is in addition to:

Code: Select all

// Action 2 - Return to graphics - CB157
   75 * 17	 02 0F 2B 85 0C 00 FF FF 01 2A 00 57 01 57 01 1F 00

This appears to be redundant. Under the previoud specs, this was not needed. Is it now required?

[Rubidium]

But the CB157 specs read:

But you're using variable 41 in the place where you need to shift. The bit that uses CB157/splits on tile location is okay.

NewGraphicsSpecs Sprite Errors says that code 6 means the given property number in action 0 is invalid and points to the byte in the sprite that follows the one which triggered the error. 36 is property 11.

That sounds like a small error somewhere; the "how many properties does this feature have" variable seems to be not updated.

This was intentional so as to test for backwards compatibility for newobject grf's that pre-exist r2339.

You might be able to jump over it with an Action 7 or 9.

This appears to be redundant. Under the previoud specs, this was not needed. Is it now required?

I copied the sprite that distinguished between graphics and callback in the purchase "chain", so I copied the comment as well. In any case the sprite 61 is part of normal "chain" and it picks out callback 159 (the start/stop animation callback), which in sprite 60 tells to start the animation (returning of FE). As I'm not good in NFO it's probably a nasty hack, but it works for me. Without those two sprites to actually start the animation there is no animation.

[Lakie]

Forgive the late reply,

I have been working on the TTDPatch version of this all (albeit quite slowly). The majority of the animation and vars are now complete (but mostly untested).
I was planning to start proper testing the various bits of code now, and riddle out most of the major bugs.
I'll look into the added properties being rejected by TTDPatch.

Just a few small queries to Rubidium;
- Currently my code adds all tiles of an object (with the animation flag) to the animation system, and then calls the trigger for construction.
(The idea being that one didn't have to do anything to enable animation but could choose which tiles to turn it off on if they liked).

- Roughly how many lines should I allow for as added text on the GUI.
(I'm unsure if TTDPatch has a system to measure string width/height for it to be automated).

~ Lakie

[Rubidium]

Currently my code adds all tiles of an object (with the animation flag) to the animation system, and then calls the trigger for construction.

Interesting... seems like industry tiles and houses behave that way. I modelled this part after stations though. I'd be fine with it either way, so what's the concensus here about that?

Roughly how many lines should I allow for as added text on the GUI.

Good question again. OpenTTD "just" doesn't care as it'll resize the window if it needs to, though that might be considerably harder for TTDPatch. So again, what do the actual users (i.e. NewGRF developers) think of this?

[eis_os]

NewGraphicsSpecs Sprite Errors says that code 6 means the given property number in action 0 is invalid and points to the byte in the sprite that follows the one which triggered the error. 36 is property 11.

That sounds like a small error somewhere; the "how many properties does this feature have" variable seems to be not updated.

For Action0 TTDPatch shouldn't have a a feature size anymore, as action0 is created on the fly via preprocessor...

Lakie;
TTDPatch can limit the textsize, see the GRF Status window how to do that.

[michael blunck]

With regards to newobjects specification, shouldn´t we get rid of the version codes in the Wiki´s object properties and flags tables? Only version code "c" seems to be correctly identified, all others are a mystery to the reader.

In addition, usage of them in both tables seem to be inconsistent ("b" in properties should be read "d", as in flags). I´d vote for a clean start with the newobjects feature and a removal of those codes.

If not, the proper TTDPatch/OTTD versions should be added.

The specifications of NewObjects? are available since OpenTTD r20670 in TTDP since r2340

In the actual context, this is nonsense, because the newobjects feature in TTDPatch is already available since <r1300, though not in the current form.

Insofar, this is supporting my above proposal for removing the above mentioned version codes:

- either the newobject feature is available since r20670/r2340 with all prior version codes and references of earlier TTDPatch version removed,

- or it is available in TTDPatch since r12xx with the different versions properly defined.

regards
Michael