Recent posts

#11

Bug Reports / Re: Elevated roads do not prev...

Last post by prissi - Yesterday at 12:06:05 PM

My idea was much simpler: to prevent the city from automatically building and renovating under bridges, elevated roads and similar structures, and to leave the rest up to the player.

Since there are bridges over entire valleys with villages, I think a general ban is not nice, and height related is better.

height_clearance = min(0, (pak_size/2 - ymin) / height_step))

Height zero is exactly at half height. Image coordinates are from top left. The smaller ymin, the more height needed. Hence the minus sign. Starting deeper than half height needs no clearance, and then one more per height_step. I agree that zero does not make sense, one should better calculate:
min_height_clearance = 1 + min(0, (pak_size/2 - ymin) / height_step))

With a flag in desc, multitile buildings shoudl be fine, since the desc is the same for all tiles.

Code Select Expand

say the word and I will work to your formula rather than invent my own.You prepared already a lot of the needed work. So maybe just go on? I am very busy this week at work, I fear, lots of text to write, which drains me and do not leave enough for programming.

#12

Bug Reports / Re: Elevated roads do not prev...

Last post by makie - Yesterday at 11:58:12 AM

if a different player real or AI could technically cut off growth by just building an elevated way or bridge next to a city.

Every railway and also all fences do this.

Some cityrules allow jump over one railway if there is station but if you build a double railway around the city then the city can't grow anymore.

This is nothing special to elevated highways.

#13

Bug Reports / Re: Elevated roads do not prev...

Last post by danivenk - Yesterday at 11:22:30 AM

My concern is the city itself, which simply and stupid builds anywhere as it expands—including underneath elevated highways.

What the player does is a different matter. To restrict the player in a single-player game, it makes only sense if it is absolutely necessary to avoid program crash, I think.

I get that, but even then that means if a different player real or AI could technically cut off growth by just building an elevated way or bridge next to a city. I'm just posing possible concerns with completely disallowing it. Hence why I myself am not sure if such a quick fix is the right option. That is why I think that either prissi's idea of introducing height into the objects or a way of estimating the height of a building based on how many tiles it covers in the drawing phase is the best option.
IMO of course

[What happens]

#14

Bug Reports / Trees show through elevated wa...

Last post by victor_18993 - Yesterday at 10:34:57 AM

Václav mentioned in topic 23991 that trees also appear under elevated ways. I looked into it, and the interesting part is that the engine already intends to prevent this.
simplan.cc even says so in its own comment — "clip horizontally to prevent trees etc shining trough bridges" — and obj_t::baum is handled explicitly. So this is not a missing feature. It is an existing case that currently does nothing.
What happens
The decision compares max_height with (htop - hmin), both expressed in height levels. However, max_height is calculated like this:

Code Select Expand

clip_h = rw/2 + (pak_height_conversion_factor * rw / 8);
 max_height = max(max_height, (area.h - area.y) / clip_h);
 if (max_height == 0) { /* display without clipping */ }clip_h is 96 for pak128 and 40 for pak64. One height level on screen is:

Code Select Expand

tile_raster_scale_y(TILE_HEIGHT_STEP, rw)That is 16 pixels in both paksets.
So the divisor is six times too large in pak128 and two and a half times too large in pak64. The integer division usually rounds to zero, and clipping is skipped entirely.
Prissi's height_clearance sketch in topic 23991 also divides by height_step for essentially the same pixels-to-levels conversion, which is the unit I am arguing for here.
Measured from the paksets
I read the image dimensions directly from the paksets:

• pak128: 550 tree images, median (h - y) of 46; only 16% exceed clip_h
• pak64: 380 tree images, median of 14; only 12.6% exceed clip_h

So this is not unusual artwork in one pakset.
It is not a pakset opting out either. I checked the WAY nodes, and all 22 elevated ways in pak128 declare clip_below=1. The only exception is Suspended_Monorail_Track, which correctly uses 0.
Why the case is reachable
A way built at ground level replaces the tile and removes the tree with it.
An elevated way leaves the kartenboden untouched and creates a monorailboden above it, so the tree remains underneath. On an empty pak128 map, 12 trees under a ground road become 0, while 12 trees under an elevated way remain 12.
tree_builder.cc also has no overhead check, so trees can be planted underneath an existing deck.
The patch
The patch is nine lines in one file: divide by the height of one level.
That also gives max_height a consistent meaning: height in levels, which is the same unit used by the comparison. max_height == 0 then correctly describes an object shorter than one height level. That includes roughly half of pak64's trees, which should not need clipping.
The clipping line itself is derived from the upper ground's height and does not use max_height. This therefore cannot make the clipping more aggressive than intended; it only prevents the existing clipping path from being skipped.
Test suite: 201/201.
A question I could not answer, and deliberately did not patch
This improves the result considerably, but it does not remove every tree. In pak128, bridges go from being covered in trees to leaving two or three visible.
Those remaining cases come from the numerator. (area.h - area.y) is negative for 144 of the 550 tree images, which cannot represent a height.
If an object stands on the ground line, then y + h is that line and the visible overhang is simply h. By contrast, h - y becomes 2h - ground_line, which is negative for many medium-height objects.
Replacing the numerator with h reduces the remaining cases from 32% to 1.6%.
I deliberately left that out of the patch. The divisor is a clear unit mismatch that can be justified independently. The numerator is my interpretation of the original intention, and I would rather ask than tune it until the screenshots look right.
So the question is: was (area.h - area.y) really the intended value here?
Prissi, your height_clearance sketch derives the height from ymin rather than subtracting a y offset from the image height. If ymin is the correct way to determine how tall a building sprite is at load time, it may also be the correct way to determine the height of a tree at draw time. That would make the second part less speculative, but I did not want to change it based only on that assumption.
Two more things I could not establish:

• Whether the same issue affects buildings. I could not place a building beneath an elevated way, but the tool also refused on a control tile with nothing overhead, so that test failure was mine.
• Whether trees disappearing entirely, rather than being clipped at the deck line, is the intended behaviour. That depends on where the clipping line is placed, which this patch does not change.

[Multi-tile buildings.]

#15

Bug Reports / Re: Elevated roads do not prev...

Last post by victor_18993 - Yesterday at 10:22:55 AM

prissi, the height_clearance parameter looks right to me, and more useful than what I posted: it names the property on the building instead of deducing it at each call site, it covers bridges and future multi-level structures in one place, and the -1 auto-detection means paksets get it without editing a single dat. If you want it implemented I am happy to do it — say the word and I will work to your formula rather than invent my own.
One question about it:

Code Select Expand

height_clearance = min(0, (pak_size/2 - ymin) / height_step)This is always less than or equal to 0 as written. Did you mean max?
Two clarifications about the patch I attached earlier, because I think the thread is partly arguing against something it does not do.

Multi-tile buildings. makie, you are right that this needs checking, and it is why the patch adds two predicates rather than one: building_tile_desc_t::has_upper_storey() for a single tile, and a building_desc_t counterpart that asks it of every tile across layouts * size.x * size.y. Renovation uses the second, so it does not stop at (0,0).
The way builder still uses the per-tile one, which I believe is correct there since it walks the tiles the way actually crosses — but that is also the path where I would expect a (0,0)-only symptom to show. I have not reproduced what you saw, so if you can say which of the two it was, I will test it properly rather than guess.

Blocking the player. danivenk's objection is a real one, but it does not apply to this patch: the only behavioural change is inside renovate_city_building(). Nothing a player can do is refused that was not already refused before. That is deliberately makie's last post — the city, not the player.
And it forbids nothing even there. The flag goes into the candidate search beside the existing climate, size and exclusion filters, so the block keeps renovating and simply stops growing upwards once the pakset has nothing suitable left. The alternative — freezing those tiles — would leave a stripe of untouched buildings under every viaduct as the rest of the city modernises around them.
None of that is an argument against height_clearance, which subsumes it: my has_upper_storey() is just the -1 auto-detection collapsed to a single height level and hard-wired to elevated ways. I would rather have yours.

Separately, on Václav's point about trees: that one is a drawing bug with a cause of its own, and I have opened a thread for it rather than mix it in here. It is relevant to this discussion in one small way — the fix is a unit error in exactly the arithmetic being discussed, and it divides by the height step, same as your formula does.

#16

Bug Reports / Re: Elevated roads do not prev...

Last post by makie - Yesterday at 09:44:09 AM

Not sure if completely disallowing the build/renovating buildings under bridges is really desirable... That would mean that if the player does not have access to the public player they can't add buildings underneath the bridges/elevated ways.

My concern is the city itself, which simply and stupid builds anywhere as it expands—including underneath elevated highways.

What the player does is a different matter. To restrict the player in a single-player game, it makes only sense if it is absolutely necessary to avoid program crash, I think.

#17

Bug Reports / Re: Elevated roads do not prev...

Last post by danivenk - Yesterday at 09:32:46 AM

Not sure if completely disallowing the build/renovating buildings under bridges is really desirable... That would mean that if the player does not have access to the public player they can't add buildings underneath the bridges/elevated ways.

[the city]

#18

Bug Reports / Re: Elevated roads do not prev...

Last post by makie - Yesterday at 07:18:06 AM

So my idea would be:
Introduce a new parameter for buildings in dat files: "height_clearance"

I think the idea is good, though also a bit involved.
I would also like to point out that, for multi-tile houses, the check currently only covers tile (0,0), as it appears to me during testing. I didn't look at the program.

My idea was much simpler: to prevent the city from automatically building and renovating under bridges, elevated roads and similar structures, and to leave the rest up to the player.

#19

Bug Reports / Re: Elevated roads do not prev...

Last post by Yona-TYT - Yesterday at 03:42:52 AM

It sounds interesting; in fact, this was discussed years ago. Back then, the goal was for planes to recognize the height of buildings using a flag, as @prissi mentioned, to prevent them from aircraft through buildings like ghosts.

Of course, implementing this logic for planes could be difficult and complex, but it would be nice to have more realism in this context.

#20

Bug Reports / Re: Elevated roads do not prev...

Last post by prissi - Yesterday at 02:30:02 AM

There are even special building addons on the japanese wiki tailored to fit exactly under elevated roads. The only proper solution is a new flag for buildings for makeobj, like the underground flag, because even single height buildings could be way too high. (And pak128 Schwebebahn is another issue graphically ... )

As a compatibility measure, one could flag all old buildings on load time with this flag depending on their height. Then monorails could be constructed also over such buildings.

And in principle, the bridges should do the same test. Moreover, I have an unfinished patch for more than single level high elevated ways, like extended has as well. So a building height flag parameter is very useful.

So my idea would be:
Introduce a new parameter for buildings in dat files: "height_clearance" with a default of -1 (meaning not set, whcih is also the default for old versions)
On load time in hausbauer_t::register_desc
height_clearance == -1 => check tile image of (0,0) or right upper corner for height.
height_clearance=min(0,(pak_size/2-ymin)/height_step) and so on for heights higher than 1 add the offset of the lower tiles and just take the height directly. That would avoid most graphical errors and give most flexibility.

And apply this height clearance also to bridges during renovation because it should apply there too.

A little longer is the effort to change bridge builder and way builder for elevated way, which would be needed anyway for more freely constrcuted elevated ways. I would put this off for now, as such changes are very prone for errors and I would rather release something stbale soon.

Adding a new makeobj flag and checkign height of buidlings on load is quite stareight forward and you did most of the work already.