NewObjects specification

Discussions about the technical aspects of graphics development, including NewGRF tools and utilities.

Moderator: Graphics Moderators

Post Reply
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

NewObjects specification

Post by Rubidium »

I'm working a bit on getting newobjects into OpenTTD but there are a few things that bother me or that I have heard about bothered others. So I'd like some input on what changes to the current specifications are desirable and whether the current specification is actually desirable. As such I won't release/commit anything just yet as it is not finished in any way and the specifications might change in any case.

First of all I've heard that using the same callback ID for multiple features isn't something that is done anywhere else in the specifications, so I'd like to keep it that way. This would mean that callback 149 becomes some other, to be determined, callback. Besides that I propose "callback flags" so you can tell whether you want the callback to be called or not. In that case returning a failed callback would mean "disallow" as I'm not that certain that returning a sprite set would mean "any slopes are fine by me".
Talking about the current callback 149: I would like to pass YX to the low byte of variable 18 as the same format is used for variable 40 and property 0C.
This would furthermore allow objects to be on steep slopes, however allowing objects being on steep slopes means you have to disable drawing of foundations!

To object flags I want to add two flags: "can be built under bridge" (behaviour of owned land in OpenTTD) and "requires flat land, but not on foundations" (the current behaviour of lighthouses and transmitters).

Besides that tile animation seems to be totally neglected. I propose:
- animation frames and speed properties,
- the equivalent of callbacks 1A, 1B and 20 (decide following frame of animation, periodically start/stop animation, decide length of animation frame) plus bits in "callback masks".
Callback 1B equivalent would use triggers instead of a callback mask bit: upon construction, synchronised for all tiles (i.e. tileloop of the northern tile) and unsynchronised (normal tileloop). For these triggers to work the animation bit must be set!

For constructions I could imagine the equivalent of 1E (decide colour of building) plus a callback mask bit.

I'd also suggest some sort of method for NewGRFs providing a bit more of a description than just their name, i.e. callback 23/38 equivalent.

Variable 42 defines the construction year in a word, although theoretically it can be more than 65535 in OpenTTD. So it should be considered for "upgrading" to a dword. OpenTTD furthermore has a "resolution" of one day for the construction, i.e. it can as well return the exact date.

What should var 43 return as "c" when the structure is company owned?

What should be the related object of an object? I'm thinking about the town it is placed in (can change whenever the town is removed though!).

Should object removal costs be related to the build costs? What about specifying a factor for those as well?

Declare TRNS and LIGH default classes, with the default transmitter and lighthouse in there but only in the scenario-editor.

Via Lakie I've heard that the current fixed size rectangular objects are considered too restrictive. Ideas to overcome this issue are to use the system used by stations, i.e. dragging and configurable sizes, or the system used by industries, i.e. multiple tile layouts.
The problem with the station system would be to determine when individually built parts are part of the same object, i.e. when to join and when not to join. For stations this is relatively simply as they have an in-game unique identity (read: name), though objects don't currently have that. It is ofcourse possible to name them and then use the same joining mechanisms as used for stations. Question remains whether bits should be removable tile-by-tile like stations, or whether the whole structure has to go at once. Should pieces be able to overwrite other pieces by overbuilding? The "fixed rectangular objects" still remains, though adjoining will somewhat negate that problem.
The problem with the industry system is that you'd still be limited to the layouts designed by the developer and that dragging e.g. a pipeline remains impossible. It would, however, mean that non-rectangular objects can be constructed in one go and with multiple layouts per object lots of variants can be made.
Any of these suggestions would ofcourse null-ify my current suggestion.

So the question is, which approach is best for the NewGRF/OpenTTD/TTDP developers and for our users and what other properties, variables and callbacks would be needed?


Proposed specs, currently based on the TTDP implementation (will be updated whenever there are new/better ideas)

Code: Select all

Action 0 properties:
Nr. Size Description
08  D    Class ID
09  W    Text ID for class
0A  W    Text ID for object
0B  B    Climate availability
0C  B    Size (yx)
0D  B    Object build cost factor (sets object removal cost to same value, so has to go before prop 14)
0E  D    Introduction date
0F  D    End of life date
10  W    Object flags
           Bit Value Meaning
            0      1 Only available in sceneditor
            1      2 Irremovable, except with extra (powerful) dynamite
            2      4 Anything can remove (of same company)
            3      8 Allow construction on water (does not flood)
            4     16 Removal cost is income
            5     32 Do not show foundations
            6     64 Animation
            7    128 Only available during game play
            8    256 Allows 2cc colour mapping
            9    512 Disallows building on land
           10   1024 Draws water under tile
           11   2048 Allows bridge overhead taking the height of the building into account
           12   4096 Random bits in "next animation frame" callback
11 W     Animation information (station property 16)
12 B     Animation speed (station property 17)
13 W     Animation triggers (like station property 18)
           Bit Value Meaning
            0      1 Upon construction (whole object)
            1      2 Periodic tileloop (per tile)
            2      4 Every 256 ticks (whole object)
14 B     Object removal cost factor
15 W     Callback flags
           Bit Value Callback
            0      1 Custom slope check
            1      2 Decide next animation frame
            2      4 Decide animation speed
            3      8 Decide colour of building
            4     16 Display additional text in the build object window
            5     32 Decide autoslope
16 B     Height of building (measured from the highest point within a tile on a per tile basis)

Action 2 variables:
Nr. Size Description
40  D    Relative position, format 00yxYYXX
41  W    Tile information, format ss0t (ss = slope bits, t = terrain type)
42  D    Construction date (not year!)
43  W    Animation counter, format ccaa; cc = (random) colour, aa = animation state
44  B    Object founder information (like varact2industries A7)
45  D    Get town zone and Manhattan distance of closest town (like varact2industries 65, distance 
           from current tile)
46  D    Get square of Euclidean distance of closest town (like varact2industries 66, distance from 
           current tile)
60  W    Get object ID at offset (like varact2industries 60, offset from current tile) without FFxxh 
           though.
61  B    Get random bits at offset (like varact2industries 61, offset from current tile)
62  D    Land info of nearby tiles (like varact2industrytiles 60, offset from current tile)
63  W    Animation count of nearby tiles (return value of 43, offset from current tile)
64  D    Count of object, distance of closest instance (like varact2industries 67)


Callbacks:
Nr. Eq. Description
157 149 Land slope check, var 10 offset yx, var 18 slope data
158  1A Next animation frame, var 10 random bits if requested
159  1B Animation control, var 18 reason (bit number from property 13)
15A  20 Length of animation frame
15B  1E Building colour
15C  38 Show addition text in the build object window
15D  3C Allow/disallow autosloping

Related object: towns

Random bits:
8 per tile

Note: colour gets set once; when there's no owner a random colour, otherwise the company colour.
That's passed through the building colour and then stored.

Changes to the current TTDP spec:
- callback 149 -> callback 157, flag to enable it
- varact 42 from year -> date, word -> dword
- add properties 11-16
- add flags 11-12 to property 10
- add varact 44-46, 60-64
- add callback 158-15C
Edit (2010-08-24 20:55 UTC): add act2 vars 44-46,60-64
Edit (2010-08-25 15:45 UTC): add act0 prop 15, remove 2 bits from prop 10
Edit (2010-08-26 08:35 UTC): tweak prop 15, readd "allows bridge" bit, add autosloping
Last edited by Rubidium on 01 Sep 2010 19:43, edited 18 times in total.
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: NewObjects specification

Post by planetmaker »

I propose to add an additional variable: player number, similar to industry's variable A7 or vehicles variable 43. It'd allow for things like statues of company A are horses while those of company B are lions or alike.

One can also envision analogues to industry variables 60-68, especially 62.

EDIT: added some more variables ;-)
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: NewObjects specification

Post by wallyweb »

Howdy folks!

It's good to see some development for Newobjects on the OTTD side. 8)

Seeing as how the topics are related, I'm including this link to [TTDX] NewObjects GRF Coding Guide and I will add a link back to here from there. I'm really looking forward to changing that [TTDX] to [UNIV]. :D

I'm sure that you've been communicating with Lakie and/or Oskar about this. They've put a lot of work into Newobjects and developments/improvements are ongoing. From a coder/author point of view, it would be good to include as much similarity as possible between the two platforms, if only to make my life simpler. :wink: . Michael Blunck has also had considerable input/suggestions for the TTDX implementation.
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: NewObjects specification

Post by wallyweb »

OK! It"s a double post ... but it"s a detailed reply to Rubidium's post ...
Rubidium wrote:I'm working a bit on getting newobjects into OpenTTD but there are a few things that bother me or that I have heard about bothered others. So I'd like some input on what changes to the current specifications are desirable and whether the current specification is actually desirable. As such I won't release/commit anything just yet as it is not finished in any way and the specifications might change in any case.
Good.
First of all I've heard that using the same callback ID for multiple features isn't something that is done anywhere else in the specifications, so I'd like to keep it that way. This would mean that callback 149 becomes some other, to be determined, callback. Besides that I propose "callback flags" so you can tell whether you want the callback to be called or not. In that case returning a failed callback would mean "disallow" as I'm not that certain that returning a sprite set would mean "any slopes are fine by me".
Talking about the current callback 149: I would like to pass YX to the low byte of variable 18 as the same format is used for variable 40 and property 0C.
This would furthermore allow objects to be on steep slopes, however allowing objects being on steep slopes means you have to disable drawing of foundations!
I'm all for adding the ability to build on steep slopes,
CB149 is relatively easy to use so any changes should take ease of use into consieration.
To object flags I want to add two flags: "can be built under bridge" (behaviour of owned land in OpenTTD) and "requires flat land, but not on foundations" (the current behaviour of lighthouses and transmitters).
I'm not sure what you mean by this. The TTDX lighthouse and transmitters get foundations when not built on flat land. Currently, with similar items built as newobjects, one has the option of specifying to build on foundations. Build on flat land can be forced via CB149
Besides that tile animation seems to be totally neglected.
This is currently being addressed by Lakie. It definitely could use some work, but it is far from neglected.
I propose:
- animation frames and speed properties,
- the equivalent of callbacks 1A, 1B and 20 (decide following frame of animation, periodically start/stop animation, decide length of animation frame) plus bits in "callback masks".
Callback 1B equivalent would use triggers instead of a callback mask bit: upon construction, synchronised for all tiles (i.e. tileloop of the northern tile) and unsynchronised (normal tileloop). For these triggers to work the animation bit must be set!
YES!
For constructions I could imagine the equivalent of 1E (decide colour of building) plus a callback mask bit.
I'd also suggest some sort of method for NewGRFs providing a bit more of a description than just their name, i.e. callback 23/38 equivalent.

Variable 42 defines the construction year in a word, although theoretically it can be more than 65535 in OpenTTD. So it should be considered for "upgrading" to a dword. OpenTTD furthermore has a "resolution" of one day for the construction, i.e. it can as well return the exact date.
No argument here.
What should var 43 return as "c" when the structure is company owned?
It currently returns an industry colour specified by the nfo coder/author for Scenario Editor use. I question the need for this as objects are unproductive eye-candy, have no contribution to game play and are NOT industries, stations or town features.
What should be the related object of an object? I'm thinking about the town it is placed in (can change whenever the town is removed though!).
A newobject is not related to anything other than the player's desire to use them as he/she sees fit. Why change this?
Should object removal costs be related to the build costs? What about specifying a factor for those as well?
This is already covered as an Action 0 property is it not?
Declare TRNS and LIGH default classes, with the default transmitter and lighthouse in there but only in the scenario-editor.
Under TTDX, the default objects (transmitter, lighthouse, rocks) exist exactly as you described them without wasting valuable classes. Work is ongoing to provide a generic set of classes as a W3C style "recommendation". In other words, it is highly suggested to use them, but it is not mandatory. An author/coder can use their own classes if they feel a need. There will be more on this in the newobjects coding guide thread over the next week or two or three.
Via Lakie I've heard that the current fixed size rectangular objects are considered too restrictive. Ideas to overcome this issue are to use the system used by stations, i.e. dragging and configurable sizes, or the system used by industries, i.e. multiple tile layouts.
The problem with the station system would be to determine when individually built parts are part of the same object, i.e. when to join and when not to join. For stations this is relatively simply as they have an in-game unique identity (read: name), though objects don't currently have that. It is ofcourse possible to name them and then use the same joining mechanisms as used for stations. Question remains whether bits should be removable tile-by-tile like stations, or whether the whole structure has to go at once. Should pieces be able to overwrite other pieces by overbuilding? The "fixed rectangular objects" still remains, though adjoining will somewhat negate that problem.
The problem with the industry system is that you'd still be limited to the layouts designed by the developer and that dragging e.g. a pipeline remains impossible. It would, however, mean that non-rectangular objects can be constructed in one go and with multiple layouts per object lots of variants can be made.
Any of these suggestions would ofcourse null-ify my current suggestion.
Any improvement in this area would be greatly welcome. The ability to have non-object tiles for roads and tracks within the bounds of a newobject would be excellent.
So the question is, which approach is best for the NewGRF/OpenTTD/TTDP developers and for our users and what other properties, variables and callbacks would be needed?
Keep it all as simple and flexible as possible. Keep in mind that newobjects were originally conceived as a means to build TTDX's default objects while in a game and not just in the scenario editor. It grew from there into the current implementation. They make absolutely no contribution to game play. They merely exist to add interesting features to your scenario or game that are not available as town items (house etc.), industries or stations. If at all possible, drop the concept of related objects: towns.
User avatar
FooBar
Tycoon
Tycoon
Posts: 6553
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: NewObjects specification

Post by FooBar »

wallyweb wrote:
What should be the related object of an object? I'm thinking about the town it is placed in (can change whenever the town is removed though!).
A newobject is not related to anything other than the player's desire to use them as he/she sees fit. Why change this?
That way an object can access certain information about the related object via type 82/86/8A (see http://wiki.ttdpatch.net/tiki-index.php ... nalAction2).
Having town as related object makes most sense I guess.
maquinista
Tycoon
Tycoon
Posts: 1828
Joined: 10 Jul 2006 00:43
Location: Spain

Re: NewObjects specification

Post by maquinista »

I suggest a variable to check if the surrounding tiles have the same object.

For example, I have a narrow river as object, and It could load a curve shape if there are two river tiles placed at 90º. Something like the rivers, but as a single object, and not allowing ships. Also, They should allow bridges over them.
Attachments
Example.
Example.
suggestion_narrow_rivers_as_objects.png (2.79 KiB) Viewed 12779 times
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
Kogut
Tycoon
Tycoon
Posts: 2493
Joined: 26 Aug 2009 06:33
Location: Poland

Re: NewObjects specification

Post by Kogut »

Or yet another option: is_bridging_allowed
Correct me If I am wrong - PM me if my English is bad
AIAI - AI for OpenTTD
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: NewObjects specification

Post by planetmaker »

Rubidium wrote: 11 2048 Allowed under bridges
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: NewObjects specification

Post by michael blunck »

Hi Remko,

just a quick note concerning your newobjects proposal.

First of, I´m all for a unification/generalisation of specifications for the various features (houses, industry tiles, stations, objects) as far it´s reasonable and profitable. IMO, there are already too many inconsistencies in the specifications, mainly resulting from historical development. Therefore, it makes sense to have a most proper specification for a new feature.


Just let me browse through your post:

- renaming CB149 for objects to some other number makes sense and has been already discussed between Lakie, Oskar, Wally and me, besides many of the other points you´re addressing here.

- adding an object flag for "requires flat land" (like with newhouses) makes sense too.

- w/r to tile animation, changing current behaviour to that of newhouses (i.e., include selection of animation frames and speed) has been found useful already. This includes the needed CBs and triggers, as mentioned in your proposal.

- w/r to the overall concept of "objects", I don´t find it useful to make them more or less like houses or industry (tiles). IIRC, that objects "idea" was developed from TTD´s original "objects" (light house, transmitter, ??) which explicitly omitted some of houses and industry (tile) information, which makes sense for me. OTOH, adding sophisticated animation and layouts would already move away from the original idea, approaching the concept of an industry, just w/o any cargo input/output. We should come to an agreement what an "object" should be in terms of the game.

I.e., some questions arise w/r to the concept:

- should objects have an owner?
- should objects have a "related" object (town)?
- should objects have construction stages?
- ...

- w/r to object class definitions, there has been much discussion, but the general opinion seems to be to have them user-defined (like stations) and as generic as possible.


Now, to the more problematic questions of object´s layout and way of construction.

As you point out, this has been discussed already but w/o any final decision. Both approaches (industries ./. stations) have advantages and drawbacks. In conclusion, I´d say that "objects are objects", i.e., unlike a station, an object composed from, say, a hydro-electric power plant and a water "pipeline", these should be handled as two different objects. Preparing different layouts for "combined objects" would result into a lot of extra (and mostly needless?) work, IMO. Granted, in this way non-convex and non-connected objects would be feasible, but being able to place extensive objects by dragging would be a far more user-friendly approach, IMO. There´s another factor speaking for an implementation similar to stations: placement of non-isotropic objects on slopes might be simplified by providing the user with (two) different views of an object (x- and y-direction) right from the GUI. O/c, best thing would be to have both methods, but this might be impossible.

W/r to the proposed specs, I´d like to add "land info of nearby tiles" (e.g., var62 houses, var 60/62 industrytiles), mainly to get information about nearby slopes. In addition, bit1 of industrytile var60 "tile has water on it; this flag is set for coasts as well" would be very useful.

regards
Michael
Image
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: NewObjects specification

Post by wallyweb »

FooBar wrote:That way an object can access certain information about the related object via type 82/86/8A (see http://wiki.ttdpatch.net/tiki-index.php ... nalAction2).
Having town as related object makes most sense I guess.
What information would a newobject need to access? They are merely eye-candy and have no usefull game function other than to decorate your game or scenario. Some authors may use them to preview a graphics layout before commiting the graphics to a town, industry or station, but until then, that newobject would remain merely something nice to look at.
michael blunck wrote:We should come to an agreement what an "object" should be in terms of the game.
Perhaps we could go back to where the whole project started 8) :
Newobjects - Thoughts and Suggestions
On Tue Nov 21, 2006 8:57 am :wink:
User avatar
Lord Aro
Tycoon
Tycoon
Posts: 2369
Joined: 25 Jun 2009 16:42
Location: Location, Location
Contact:

Re: NewObjects specification

Post by Lord Aro »

I thought of something else (sorry if this has already been discussed) :
should newobjects cost something?
AroAI - A really feeble attempt at an AI

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
User avatar
FooBar
Tycoon
Tycoon
Posts: 6553
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: NewObjects specification

Post by FooBar »

It doesn't hurt reading the whole topic before you suggest something ;)
Rubidium wrote:Should object removal costs be related to the build costs?
Hence building objects can cost money (if defined by the author).
wallyweb wrote:What information would a newobject need to access?
This information: http://wiki.ttdpatch.net/tiki-index.php ... ion2Cities
Note that you're not required to do anything with that information. Letting objects have towns as related object just reveals that particular information to the ones who wish to use it. In fact, you don't have to change anything in your NewObject grfs if the objects all of a sudden were to have a related object: for you it will function exactly the same as you're used to (contrary to some other suggestions ventilated here).
With towns as related object you can for instance let the graphics depend on the size of the town.
User avatar
Lord Aro
Tycoon
Tycoon
Posts: 2369
Joined: 25 Jun 2009 16:42
Location: Location, Location
Contact:

Re: NewObjects specification

Post by Lord Aro »

Must of missed that
Oops :oops:
*runs and hides*
AroAI - A really feeble attempt at an AI

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: NewObjects specification

Post by planetmaker »

wallyweb wrote:What information would a newobject need to access?
Name or ID, size, coordinates, population, town zone

It could for example be a shopping mall which extends as the town grows bigger (via animation), could be a park or statue which looks differently, depending upon where it is built; could a a statue which is unique for each town with a different look in towns (and can only be built once in the town).

I'm sure you can think of similar things :-)

EDIT: FooBar was faster; I was distracted while writing ;-)
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: NewObjects specification

Post by wallyweb »

FooBar wrote:With towns as related object you can for instance let the graphics depend on the size of the town.
planetmaker wrote:
wallyweb wrote:What information would a newobject need to access?
Name or ID, size, coordinates, population, town zone

It could for example be a shopping mall which extends as the town grows bigger (via animation), could be a park or statue which looks differently, depending upon where it is built; could a a statue which is unique for each town with a different look in towns (and can only be built once in the town).

I'm sure you can think of similar things :-)

EDIT: FooBar was faster; I was distracted while writing ;-)
Points well taken, gentlemen, and I am now sold on the concept. :D
Just to carry this on a bit ... would including more than one related object be possible? Some of the points you suggested could apply to industry proximity as well.
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: NewObjects specification

Post by Rubidium »

wallyweb wrote:
"requires flat land, but not on foundations" (the current behaviour of lighthouses and transmitters).
I'm not sure what you mean by this. The TTDX lighthouse and transmitters get foundations when not built on flat land.
In OpenTTD lighthouses and transmitters can't be built on foundations. As I'd like to implement them via the same specs and implementing a callback in C++ seems a bit far fetched.
wallyweb wrote:
What should var 43 return as "c"
I question the need for this as objects are unproductive eye-candy.
So objects shouldn't get company colours at all, just the colours "set" when constructing the object? Fine by me, although I didn't see a colour button in the TTDP screenshots.
wallyweb wrote:
Should object removal costs be related to the build costs? What about specifying a factor for those as well?
This is already covered as an Action 0 property is it not?
Currently there is no such object.
michael blunck wrote:- should objects have an owner?
- should objects have a "related" object (town)?
- should objects have construction stages?
- I'd say it should be possible that they have an owner. Just like the "objects" company-owned land, company statue and company HQ. Although having objects without an owner is fine as well. Maybe some flag for this?
- For parks or so I could imagine that a small town's park has other facilities than a park for a huge city, likewise that a park in the middle of a city has different characteristics than a park outside the city. So being able to get some information of the "closest" town seems like a good plan. Likewise company statues are (at least in OpenTTD) linked to towns, so if a statue gets removed a player can build a new one again.
- Construction stages seem like unneeded baggage to me. If you really need them you can always use animation stages.
michael blunck wrote:In conclusion, I´d say that "objects are objects"
Good, saves me a rewrite.
michael blunck wrote:But being able to place extensive objects by dragging would be a far more user-friendly approach, IMO.
Maybe a property to signal that it can be dragged in a particular direction: "not", "only x", "only y", "only x or y" (straight lines), "both x and y" (rectangles)?
michael blunck wrote:There´s another factor speaking for an implementation similar to stations: placement of non-isotropic objects on slopes might be simplified by providing the user with (two) different views of an object (x- and y-direction) right from the GUI.
OpenTTD's newairports has the ability to define "rotations", which would be just like an layout index, but without the layout and automagic calculations. So you set this property to 1, 2 or 4 rotations and then OpenTTD/TTDPatch transforms all data to/from the NewGRF to handle the rotation, i.e. it's transparent to the NewGRF.
So in effect you could provide up to 4 sprite( stack?)s per tile for (each from a different angle) and the rest of the NewGRF code stays exactly the same. This would mean, though, that if NewGRF looks at a tile to the north and it's rotated one step the translation will make that it actually looks to a tile in the east.
I don't have any idea how complex this would be in TTDPatch. If it's too complex it might be better to not do this at all.

So as summary: up to now most is just additions to the varact2 variables and properties and a callback ID change + mask + change of parameter... but no major reworks of the specs.

P.S. I could use some NewObjects GRFs that play with the different water related parts, so I can implement and test that as well.
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: NewObjects specification

Post by eis_os »

Lighthouses and transmitters on slopes are activated long time ago in TTDPatch, I haven't seen any complain about that. maybe OTTD should simply follow?

Build under bridges:
Objects are tiles, while for OTTD it may be possible, TTDPatch bridges are tiles. Both can't be combined. So allowed under bridges is void for TTDPatch
Generally I would think it would be better to have a callback, returning the object height in tile height blocks. This way at least OTTD can determine if this is a big object and deny bridges if it would be in the way. (I mean here height levels, not true TTD coordinates) This could be a shared callback and extended for other newgrf tile types.
Imho, newgrf lacks a way to tell this right currently...

I guess a flag "has no owner" isn't good enough, water tiles should be owned by water, the question is should town own an object as well?
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: NewObjects specification

Post by michael blunck »

eis_os wrote: [...] the question is should town own an object aswell?
I already pointed out where the "newobjects" idea started from, i.e. TTD landscape objects like transmitters, lighthouses, rocks, ..., which are just eye-candy and have no game-related functionality (except from being mere obstacles), and don´t have any owner.

OTOH, some people here seem to regard newobjetcs as a replacement for houses in towns, which they´re not, IMO. It´s true that buildings only have a max size of 2*2, and newobjects offer larger dimensions, but this alone seems not to be a sufficient justification to regard them in this way, IMO.

Even equipped with detailed animation capabilities now, I still see newobjects mainly acting as landscape details, but not as town buildings. Those landscape objects (rocks, water, shipwrecks, retaining walls, cliffs, waterfalls, ...) still don´t need any ownership nor company recolouring. For other newobjects (infrastructure) this might be useful, though.

Question is, whether arranging newobjects with town ownership would have any side effects? Or adding a flag as Remko suggested?

regards
Michael
Image
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3603
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: NewObjects specification

Post by eis_os »

A Side affect: Town rating could be checked and then deny removing :-) Still wouldn't be a town building...
Last edited by eis_os on 25 Aug 2010 09:00, edited 1 time in total.
Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: NewObjects specification

Post by Rubidium »

eis_os wrote:Lighthouses and transmitters on slopes are activated long time ago in TTDPatch, I haven't seen any complain about that. maybe OTTD should simply follow?
I think the argument for not allowing slopes has to do with the transmitter. Its support wires extend out of the tile and they shouldn't end mid-air.
eis_os wrote:Objects are tiles, while for OTTD it may be possible, TTDPatch bridges are tiles. Both can't be combined. So allowed under bridges is void for TTDPatch
That's perfectly fine. The objects allowing bridges doesn't mean TTDPatch has to support that.
eis_os wrote:Generally I would think it would be better to have a callback, returning the object height in tile height blocks.
I've seen some work by peter1138 about this for stations, but never seen it come to something finished. For industries and stations there is still space on our map array add bridge support; actually even for houses, but for some reason 5 bits are reserved for triggers and only 2 are used. So adding it to houses would mean that only one trigger bit can be added before OpenTTD's map array can't handle it anymore.
Regardless of the callback, it is tricky to have a callback for existing stuff, i.e. the owned land. Although I can easily move the flag to bit 16 (and the requires level land to bit 17). That way they stay out of the NewGRF specification and I can still use those flags in my code. Another way would be to define that if the callback fails (or is missing) and the "has bridge check callback" is set means that it is allowed to build a bridge regardless of height. Any other return would give a minumum height of the bridge with 0x7FFF as "no bridge allowed". It would be called without actually built objects when testing for bridges during construction of the object and with a built object when building a bridge, but I reckon that shouldn't give much trouble. Or are those "no object yet" callbacks (per definition) ran from the purchase "cargo" action2 entry and the "with object" callbacks from the "cargo 0" action2 entry?
eis_os wrote:I guess a flag "has no owner" isn't good enough, water tiles should be owned by water, the question is should town own an object aswell?
An oil rig is owned by water as well?
michael blunck wrote:Question is, whether arranging newobjects with town ownership would have any side effects?
I'm not giving towns ownership of newobjects, I'm merely linking them to the closest town. Same as stations and industries are linked to towns, but not owned by towns. So in this case I'm looking at them from the station/industry perspective, not the house perspective.
The only side effect this has is that it is needed to have at least one town in the scenario editor before placing objects, and that removing the last town removes all objects. But the same applies here for industries (and town houses), except that objects will be reassigned to the closest town (if there isn't one anymore, they'll be removed as described before) if the town the were linked to gets removed.
eis_os wrote:A Side affect: Town rating could be checked and then deny removing :-)
But it won't be able to influence the town's ratings, and it requires a "can remove" callback to be implemented.
Post Reply

Return to “NewGRF Technical Discussions”

Who is online

Users browsing this forum: No registered users and 3 guests