NewObjects specification

[Rubidium]

Question to developers: from my understanding, a var60+x is more CPU-intensive as a var40+x, so that may be the reason to have info about the current tile in a var40+x but similar info about nearby tiles in a var60+x? Otherwise, we could combine terrain data info in just one var, where the current tile has a displacement of (0,0)?

Yes, the var60+x is more expensive but primarily due to it returning more information. The var60+x variables that I proposed all have the current tile at (0,0) displacement.

Meanwhile I've added support for autosloping as well. Seems only logical to have that if you have custom land slope checks as well.

[wallyweb]

On the subject of company ownership of an object ... I think this should be available. It is not a concern in the scenario editor as the item would show the 1cc blue and 2cc green until the scenario is called for a game. At that time, the player could rebuild the item and get his/her company colours if that player really felt a need to have them.

[Rubidium]

I've updated my implementation to the currently proposed specs (first post). Due to the changes described at the bottom of the first post over the current spec implemented by TTDPatch the current NewGRFs will not function 100% correctly; most importantly: the land slope check will not be executed. So please do not complain when those NewGRFs act oddly because they are built on incorrectly sloped ground.

As I'm myself not a NFO coder most of the new things haven't been (thoroughly) tested, but on the other hand much of the code is similar/the same for other things such as stations, houses and industries. I'd especially like some NewGRFs to test the water and animation related bits of the code.

You can find a number of precompiled binaries at http://devs.openttd.org/~rubidium/cf/he0eb1738/ and the diff can be found below. The binaries (and patch) are based on r20643.

For those that downloaded before 2010-08-27 23:30, there's a newer version.

[ChillCore]

Looking good Rubidium.

I have two small request if you do not mind ...
I have tested with the first version you have posted and I have not yet bumped my folder and updated to the new version but I noticed that the concerned code has not changed in the new version.

1. Please make the NewObjects gui preview resizable if possible. See attachment.
2. Please move TTW_SHOW_PLACE_OBJECT before TTW_BUTTONS_START in TerraformToolbarWidgets as you have done with ETTW_SHOW_PLACE_DESERT in the scenario editor.
If one declares buttons after TTW_SHOW_PLACE_OBJECT the game will crash upon selecting the last one.
As an alternative you could make a note that TTW_SHOW_PLACE_OBJECT has to remain last in the list perhaps?
Either solution would be fine and will most likely avoid confusion in the future.

Also the "Objectclass" string is drawn one or two pixels too high.


Could someone be so kind to point me to some NewObject GRFs to test ingame or are those to be created still?

[Rubidium]

1. Please make the NewObjects gui preview resizable if possible. See attachment.

Not needed. It will now take the height property and use that to determine how high the window should be. If an object does not fit in the preview, then the height property is incorrectly set.

2. Please move TTW_SHOW_PLACE_OBJECT before TTW_BUTTONS_START

Makes sense; consider it done.

Also the "Objectclass" string is drawn one or two pixels too high.

The margins of that string were totally incorrect.

Could someone be so kind to point me to some NewObject GRFs to test ingame or are those to be created still?

At this moment there are no such NewGRFs. I've got a slightly modified Lamoot tower (one that properly sets the object's height), but not sure whether I am allowed to release that. The rest of the currently existing NewGRFs are written against the old specs and therefor their land slope check fails and they are missing the height property. Nevertheless, the old ones will generally work except for the aforementioned things, i.e. you can place some things on incorrect slopes which causes some graphical glitches.

Finally, you're probably better off not adding this to your patch pack.

[Timmaexx]

Hi Rubidium,

thank you very much for this teaser! I found sth. confusing:

- In OpenTTD 1.0.3 I can build transmitters and lighthouses, even if no town has been found
- In your teaser I first have to build a town. Then I am able to build NewObjects

Greets,
Tim

EDIT: Both in Scenario Editor

[Rubidium]

In your teaser I first have to build a town. Then I am able to build NewObjects

It's the same in trunk as well. This to make all "objects" behave the same regardless of whether they are old style or not.

Although I could make the old-style objects not reference a town (besides statues as they already did), but that adds more special code and I'm not sure whether that's for better or for worse.

[FooBar]

I don't think the town requirement is a problem. In the end every scenario needs at least one town anyways, as without one industries are not possible either. The solution is simple: build towns first.

[Timmaexx]

In your teaser I first have to build a town. Then I am able to build NewObjects

It's the same in trunk as well. This to make all "objects" behave the same regardless of whether they are old style or not.

Sorry, I forgot to check it in current trunk!

I don't think the town requirement is a problem. In the end every scenario needs at least one town anyways, as without one industries are not possible either. The solution is simple: build towns first.

I've always built the Landscape incl. Lighthouses and Transmitters first! Now I know that I have to change my way...

[ChillCore]

1. Please make the NewObjects gui preview resizable if possible. See attachment.

Not needed. It will now take the height property and use that to determine how high the window should be. If an object does not fit in the preview, then the height property is incorrectly set.

I see, I was wondering why it did not work as I expected from reading the code. But I understand now.

2. Please move TTW_SHOW_PLACE_OBJECT before TTW_BUTTONS_START

Makes sense; consider it done.

Thank you.

Also the "Objectclass" string is drawn one or two pixels too high.

The margins of that string were totally incorrect.

OK.

Could someone be so kind to point me to some NewObject GRFs to test ingame or are those to be created still?

At this moment there are no such NewGRFs. I've got a slightly modified Lamoot tower (one that properly sets the object's height), but not sure whether I am allowed to release that. The rest of the currently existing NewGRFs are written against the old specs and therefor their land slope check fails and they are missing the height property. Nevertheless, the old ones will generally work except for the aforementioned things, i.e. you can place some things on incorrect slopes which causes some graphical glitches.

I understand you not posting the grf.
I wanted to test the overbuilding Objects option but I can wait a bit to do so.
The ingame placement of already existing NewObjects works fine, except for what is mentioned already.

Finally, you're probably better off not adding this to your patch pack.

I did not intend to post the source from the above screenshot.
I was just testing in separate folder to check for possible conflicts with future/current trunk.
Thank you anyway for the heads up.

[Gremnon]

Do my eyes decieve me? Is that Newobjects now available in trunk?

[Rubidium]

Do my eyes decieve me? Is that Newobjects now available in trunk?

Yup, and Lakie is working on updating TTDPatch to work with the slightly updated specs.

For those interested, the following changed w.r.t. the old specs:
- callback 149 is not callback 157 and needs to be enabled with a bit in property 15
- variable 42 returns the date instead of the year

The rest are additions and don't really require changes to current NewGRFs. In any case, can't stress this enough: the building callback of the old newobject NewGRFs isn't called anymore, so you can build them in more places than the NewGRF would did allow.

[Gremnon]

Then congrats to all involved for bringing NewObjects to OpenTTD. One more thing players of both can take enjoy!

[Lakie]

I've submitted a patch which should address most of the changes to the old spec (r2339).

I'm still working on the other components of the new specification such as:
- Adding the new animation system (whilst proving the ability to use the current one if the new one is left unset / touched),
- adding var45, var46 and the new var60s (current ones are place holders),
- Implementing callback 15B (object colour) into the drawing routines,
- Changing the UI to show extra lines and adjust the preview 'view' by the object height property (similar to OpenTTD).

Additional tasks I've got planned / working on:
- Attempt to find and fix the issue with drawnofoundations and processtileaction2,
- Rearranging the object storage structure to accommodate the above changes,
- A clean user friendly (i.e. transparent) method of converting the original structure to the new structure.
- Restructuring how some vars work based on the new structure layout.

~ Lakie

[michael blunck]

I've submitted a patch which should address most of the changes to the old spec [...]

Nice to hear. I´ll take a look soon.

- Adding the new animation system (whilst proving the ability to use the current one if the new one is left unset / touched),
[...]
- A clean user friendly (i.e. transparent) method of converting the original structure to the new structure.

I don´t think it´s necessary to keep the "original" scheme, because there are virtually no newobjects newgrfs released as of today, except some "demonstration" or "test" ones. I don´t think it would be beneficial in any way. Just let´s have a clean restart with the new scheme. There's no hurry, drawing needs time.

Just my 2cc.

Question to developers: any news/thoughts about the proposed UI functions (dragging? more views?)

regards
Michael

[Donoteat]

Can these newobjects be coded to accept and/or produce cargo?

I've been working on a Washington DC scenario, and it would be ideal for me to be able create a "Capitol Building" or "Pentagon" or "Federal Triangle" NewObject that accepts and produces a lot of passengers and mail.
I imagine that it could also be done with industries, but that might cause incompatibilities with other industry sets...

[FooBar]

Virtually all industry sets feature and will feature passengers and mail. So as long as there's free industry slots, your proposed industries will work fine as add-on to those sets.

Alternatively, you could implement your buildings as House, as essentially that's what they are. I don't think that allows custom placement of those buildings, so it might not be the best alternative.

[Rubidium]

Question to developers: any news/thoughts about the proposed UI functions (dragging? more views?)

Not yet at least. I like the idea, just haven't found the time to check things w.r.t. the airport tiles which do something similar.

[wallyweb]

Hi Rubidium,

Thank you for taking this on and a job well done.
As I am a TTDX player, I'm not set up to code my work under OTTD. I will take a look at Lakie's TTDX work and see how I make out. Meanwhile, my current releases are available to an OTTD NFO coder who would like to try to bring them up to the new spec for testing purposes.

[Rubidium]

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.

In any case, the only (somewhat) OpenTTD specific part is the "allows bridge overhead" bit which should not be a problem to not set. The building height does not matter that much, unless your structure is really high or allows a bridge overhead. E.g. for the Lamoot tower I had to set it to 16 or 17 (decimal!) to show properly (read completely) in the preview window. I have heard that Lakie had interest in using that value as well for determining the size of the build window.