NewObjects specification

[michael blunck]

I asked about irregular layouts in the first post and if I recall correctly the "discussion" ended with: keep objects simple, i.e. no fancy industry layout mechanism for newobjects. [...]

Well, as I wrote:

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.

http://www.tt-forums.net/viewtopic.php?p=898881#p898881

From Wally´s post I did understand that there had been some agreement on introduction of "irregular objects" recently. In that case, I´d propose to stick to the way "layouts" are being specified in industries. If there´s no such agreement, I adhere to my former statement.

regards
Michael

[wallyweb]

... being able to place extensive objects by dragging

How would this address the ability to have one object that spans a road or rail or similarly, the ability to have an object in which tiles have been left clear for a future construction of a road or rail?

I´d propose to stick to the way "layouts" are being specified in industries.

As we need to develop a whole new spec/mechanism to give objects a layout and the time it takes for new specs to be properly tested

I assume from Rubidium's note that the effect would be similar to that with industries, the difference being that due to decisions made at the onset of the current newobject specification, the supporting code would have to be new and require original development which as Rubidium noted would require considerable ongoing testing. It's not a question of impossibility but rather one of time required and with this in mind, waiting for Rubidium to fulfill his commitment to the branching of OpenTTD 1.1 first is a small price to pay. The intervening time can be used to assemble and discuss a list of desirable features related to this proposal. My only desire is the ability to plot a transport corridor/route through an object thus avoiding the need to build two or more objects to achieve the same effect. Are there any other related features that should/could be added as well?

[frosch]

Maybe you want to further elaborate on what you consider industry-like layouts when talking about objects.

1) Industry layouts specify a number of tiles by their position and the tile ID. Including a special ID for only checking clear land. Objects do not have tile IDs, and it does not fit at all to add them at this point.

2) Industries have multiple layouts, which are usually chosen randomly, but can come with different placement restrictions. Objects have views, which are rotated kind of automatically. (x and y extends are swapped)

Also, wasn't there some requirement for dragable/resizeable objects?

[wallyweb]

Maybe you want to further elaborate on what you consider industry-like layouts when talking about objects.

Exactly what I had in mind when requesting this discussion.

1) Industry layouts specify a number of tiles by their position and the tile ID. Including a special ID for only checking clear land.

The part in bold is what interests me.

Objects do not have tile IDs, and it does not fit at all to add them at this point.

Which I assume is why Rubidium wants to focus on branching OpenTTD 1.1 before getting into this.

2) Industries have multiple layouts, which are usually chosen randomly, but can come with different placement restrictions.

At the moment I can't see a need for this but do other players have any thoughts as to whether this would be of advantage?

Objects have views, which are rotated kind of automatically. (x and y extends are swapped)

Hmm ... I thought alternate views were implemented via the menu (1,2 or 4 views) with each view having its own real sprite (needed for shadowing/shading effects).

Also, wasn't there some requirement for dragable/resizeable objects?

I believe that this is what Michael Blunck is looking for. Working with Dante123 on a newobject version of his fences, I can now see a use for this.

I agree that mimicking the Industry implementation at this stage would be problematic.
My analogy to Industries was with respect to the end result and not necessarily the method.

[Muzzly]

Don't we need a new webpage NewObjectsCrawler.tt-forums.net ?

[wallyweb]

Don't we need a new webpage NewObjectsCrawler.tt-forums.net ?

Wouldn't that be a duplication of GRFCrawler?

[Muzzly]

stupid question. I do not understand well. Can content of newObject file be mixed with content of "old"-newgrf file?
Like, can japan stations newgrf set and several newObjects be in one file ?

[Eddi]

why shouldn't it be?

[Muzzly]

why shouldn't it be?

I asume that you mean. "Yes newObjects and old-grf can be joined in one file".
Answer:
Because I don't think that functionality of newGfs should be mixed with eye-candy objects. NewGrf sets some restrictions.
Sample. Lets say HEQS set has some nice newObjects in it. I want to use them, but i do not want to have some sort of vehicle in my game because AI makes jam with this vehicle. I would prefer loading only newObjects part and skipping vehicles.

Similar topic about newgrf here

Don't we need a new webpage NewObjectsCrawler.tt-forums.net ?

Wouldn't that be a duplication of GRFCrawler?

Thanks to Eddi. Now i know that file content is mixed and can aswer your question. Yes GRFCrawler would be enough.

[wallyweb]

Because I don't think that functionality of newGfs should be mixed with eye-candy objects. NewGrf sets some restrictions.
Sample. Lets say HEQS set has some nice newObjects in it. I want to use them, but i do not want to have some sort of vehicle in my game because AI makes jam with this vehicle. I would prefer loading only newObjects part and skipping vehicles.

Similar topic about newgrf here

I think I see what you mean here. Yes, some sets are very comprehensive and seem to be made up of several grf files. It has not happened yet but I do know of a couple of comprehensive sets that are being developed. The authors, for their own reasons, have decided to combine their work into one big package. This is being done because the set will follow a very unique theme. There is nothing that one can do to force them to do otherwise. The best that I can suggest is that if you see something you like, ask the author if they would be willing to release that item as a stand-alone grf.

[Muzzly]

There is nothing that one can do to force them to do otherwise.

This is exactly what I most hate. Designer should just propose his point of view ( in sprites ), but does not force to use it.Player can choose to accept his point of view or not (use it or not). And if player sees it in different but a bit similar way, what then ? Then developer should "say a word" (in C language) and give the ability for player to choose only few part from "whole pack picture".

It feels like kind of war between those three parties.

There is nothing that one can do to force them to do otherwise

But there is always a way - split picture and create own package.

[wallyweb]

But there is always a way - split picture and create own package.

Yes ... This is very possible, but before doing this one must first verify the license and the copyright and even if it is GPL it is a good idea to discuss your intentions with the author first.

[michael blunck]

[...]

This is the sub-forum "NewGRF Technical Discussions", and the thread´s name is "NewObjects specification".

Please try to discuss your personal views about how newgrfs should be packaged in that other thread where you´re already discussing that point.

Thanks.

regards
Michael

[wallyweb]

When combining Action0 Objects Property 17 "Additional Views" with Property 15 Call Back Flag 15C "Show additional text in the build object window":
- In TTDPatch I can give each view it's own additional text.
- In OpenTTD only the first additional text is used (repeated).
Is this a bug or a pending work in progress?

additional_text_bug.png (10.15 KiB) Viewed 3748 times

[Lakie]

It does change in OpenTTD, but you have to wait for a window redraw (such as moving the window, etc).

~ Lakie

[wallyweb]

...wait for a window redraw (such as moving the window, etc)

Hmm ... Not working with r21615.

[Alberth]

Try r22231

Thanks for reporting.

[wallyweb]

Try r22231

Latest release in trunk is r22230, released on 2011-03-10 19:00 UTC.

Pending an inevitable release of r22231, I upped my ante to the currently available r22230 where although the GUI is prettier, the problem remains. Patience is a virtue so I shall be virtually patient.

EDIT: r22232 (which magically includes r22231 ) has done the trick and now that GUI Feature(ette)( )is a thing of beauty. Thank you frosch and Alberth.

[SAC]

Okey, this is very interesting indeed. The thing about adding "additional views I mean...

Surely, "additional" view is only a label for something that more precisly means that I'm able to add, for instance, four different buildings but using only one "object space"! Am I correct in this?

If so this is a great development as my biggest drawback all the time is - space...

[wallyweb]

Surely, "additional" view is only a label for something that more precisly means that I'm able to add, for instance, four different buildings but using only one "object space"! Am I correct in this?

Well the original intention was to allow for 2 or 4 orientations of an object, potentially expensive as it would require using additional objects just to get different perspectives. As it turns out a nice side effect is that the four sprites are treated as one object with only one label being required. Yes, now one can have 2 or 4 entirely different sprites per label, meaning that 2 or 4 unique items would be handled under one label as one object.