Forest Objects

[Pyoro]

Next up in my series of useless GRFs ...

...this and similar forest tiles (the ones now in EmptyGRF will be removed obviously).

Anyways, while doing this I've noticed some things I somehow missed with the other ones so far:
a) tree sprites aren't "climate sensitive". I thought they worked like groundsprites, but they don't. In other words: you can have palm trees in temperate climate, no problem:

palms.png (19.5 KiB) Viewed 10577 times

b) there's this hide sprite feature I also didn't know about which you can use to still make them climate sensitive "manually" (in the code. It'll be "automatic" ingame). It's somewhat annoying to do, but doable. ^^

So. With some vague memory on 255 limit for NewObjects IDs (is this even true? I also seem to remember that something was changed there, but my m4d search skills failed me on the details...) and dealing with annoying NewObject menu cluster (it only ever gets worse!) I started thinking on this, but since that usually leads to nothing good I decided to just ask you guys instead.

Do we want to be able to build a pine tree forest in tropical climate? A jungle in arctic climate? (mind that someone might also play with Japanese landscape in arctic climate which leads to different results again ^^; ). Or is that unnecessary and would we rather have less menu cluster/less NewObject IDs used? Not saying that it has to be either or, but just a general tendency. Or maybe something different entirely.

Also, if there's otherwise some suggestion, now 's a good time to speak up ^^

[kamnet]

There's a total limit of 255 NewGRF sets, period. There is a limit of 65,000-something IDs (stations, vehicles, objects, waypoints, etc).

I would prefer to see one NewGRF that has a logical menu of related objects, but I'd like to see as many objects grouped together as possible, as makes sense. I don't want to see a menu selection with just two objects, I also don't really want to see one that tries to cram 24 of them together such as you see with Quast65's ISR/DWE set.

[Pyoro]

Right, now that I found that changelog alternative thing I see

@25835 [25835] 13 months frosch
-Change: Increase the total number of object types from 256 to 64000.

which I hope means it does what I hope...it does. Err. So that at least is no concern.

I would prefer to see one NewGRF that has a logical menu of related objects, but I'd like to see as many objects grouped together as possible, as makes sense.

It's a bit of an unsolvable issue, I'd say. Every NewObject GRF basically does it differently, some come with lots of categories, some with very few/none, some try for some middle ground, I guess. Stands to reason that people apparently have very different opinions on how this should be handled.

My personal thinking on this is that with this third around it'll be too chaotic to just throw them all into a "misc" category and that I'll probably go with one for each GRF unless there's some super-outlandish sub-category that makes lots of sense in some way or they get too big. Doubt that'll happen though. So it'd be 3 GRFs with 3 categories and something like 25-or-so objects, with 4 views each.

menu.png (27.75 KiB) Viewed 10507 times

IMO with the resizable NewObject menu it makes more sense to use less categories as, well, you can see all build options in one go and select them easily while categories will only tell you so much. And, well, I don't really want to have to think up categories like "Forests: Pine Trees" "Forests: Tropical Woods" or somesuch (not that it woodn't (ha!) make any sense).

[planetmaker]

If the used category labels were documented, they could be shared among different NewGRFs

http://newgrf-specs.tt-wiki.net/wiki/ObjectLabels

[Pyoro]

Good point, but mostly a theoretical concern right now as far as I'm aware. Don't think there's too many NewObjectGRFs yet that have overlapping themes. Well. MISC seems to be covered by the list anyways. Guess the other two would probably be FARM and FRST. Or somesuch.

I'll put updating that table down somewhere on my list, once everything else is done (and in case I forget: all opensource anyways, not like people can't check if they want to ^^).

[Eddy Arfik]

Considering that network games are limited to loading only 58 NewGRFs, I'd suggest even if using a few seperate categories to keep it all as one GRF if possible, you can have up to 255 object IDs per file, with each object having 4 views.

[Pyoro]

Mh, true. I don't have that limit very often on my radar since I never get anywhere near it. ^^;

I probably won't merge them though. First of all I don't like forcing anybody to cluster their NewObject menu with piles of objects they don't want, so reasonably splitting them makes sense for that (just 'cause you like sheep doesn't mean you like trees equally ). And secondly code organization isn't exactly a strength of mine and I think I'd horribly get lost if I wanted to change anything later on with all of them merged together ^^;



Talking about my mad coding skills - say I have an object sort of like this:

Code: Select all

   ground {
        sprite: 4164;
	}
	building {
		sprite: 1758;
		hide_sprite: (terrain_type == TILETYPE_SNOW);
	}
	building {
		sprite: 1814;
		hide_sprite: (terrain_type != TILETYPE_SNOW);
	}

Shows tree A while not on snow, and tree B while on snow. Works perfectly fine when built, but neither of the trees show up in the purchase menu (well, I guess it can't predict where I'm going to build them. Stupid thing ). Anyways, anyone having some advice or pointer somewhere on how to fix that?

[Transportman]

Shows tree A while not on snow, and tree B while on snow. Works perfectly fine when built, but neither of the trees show up in the purchase menu (well, I guess it can't predict where I'm going to build them. Stupid thing ). Anyways, anyone having some advice or pointer somewhere on how to fix that?

I guess you need a purchase callback in the graphics-block of the object. It can be a single sprite, but also a result from several switch-blocks using available variables (not all variables are available as the object does not exist yet).

[planetmaker]

in the purchase menu you don't have any ground defined. Easiest solution: define a separate layout for the purchase menu.
http://dev.openttdcoop.org/projects/ogf ... .pnml#L252

Alternatively: have a sprite shown when none of the ground variables return anything sensible

[Pyoro]

A'ight, that seems simple enough. Thanks

€: so what I did is basically make a _purchase duplicate for the spritelayouts in question, a switch so they show correctly for the views and use that as purchase graphics for the item. Which kinda seems like a lot of code for the problem to me - but then it's working, so, well, good enough for me I think ^^;

[Eddy Arfik]

code organization isn't exactly a strength of mine and I think I'd horribly get lost if I wanted to change anything later on with all of them merged together

A lot of the bigger projects here use templates to split each item into its own file and use preprocessing magic to combine it all together at compile time, it can make it a lot easier to change or add new items.

[Pyoro]

Since I'm getting nowhere anways I finally got around to quickly zip up the GRF and source. GPLv2 as always.

In any case, you can plant a few different type of forests with this and expand the FIRS tree farms, I think. Should work in all climates; might not make too much sense in Toyland, though. Some are climate / groundtype sensitive, others aren't; it's kinda been a struggle between "well, if I want a jungle in temperate, why should I get one?" and "doesn't really make much sense to have green trees in snow...". Nowhere near perfect or finished, for that matter, but it shouldn't crash any games or anything. ^^

[Pyoro]

Don't misunderstand me! Just because I could be bugged to spend a few minutes on this GRF doesn't mean I like it! Baka!


... well, trees not being snow-sensitive bothered me too much lately this evening, so the "normal" trees now change in winter. There's an obvious caveat: depending on which tree GRF etc you use it might actually change a leaf tree into some pine tree or whatever. Or might just not be wintry at all in some circumstances - I'm looking at you, Japanese trees. Unless you memorize the specifics of your trees I doubt it'll be very noticeable, but just sayin'. In case anyone does.

So a sloppy GRF gets marginally less sloppy. Or maybe actually more? Well. You decide.

Otherwise it's exactly the same. Code's a bit different, but everything's compatible and such.

forestobjects.7z

(8.7 KiB) Downloaded 436 times

forestobjects_source.7z

(9.53 KiB) Downloaded 320 times