Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Get more tile information (house var 62) #2081

Closed
DorpsGek opened this issue Jun 14, 2008 · 3 comments
Closed

Get more tile information (house var 62) #2081

DorpsGek opened this issue Jun 14, 2008 · 3 comments
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

George opened the ticket and wrote:

R13485M

with industry var 60 and house var 62 it is possible to get the class the tile.

Wiki:
Land info of nearby tiles (60)
The parameter of this variable is an offset from the position of the current tile. The low nibble contains the signed X offset (that is 0h=0, 1h=+1 ... 7h=+7, 8h=-8, 9h=-7 ... Fh=-1), the high nibble contains the Y offset. Therefore the parameter 00h accesses the current tile itself. The returned doubleword is in the format rczzbbss, where the meaning of the letters is:
c contains the landscape class of the tile. (only from alpha 72 and above)

But it is impossible to get more information about it.

TTD structure for class 2:
L5 bits 7..4 clear: road
* L5 bits 3..0: road layout: bit set = road piece present:
bit 0: NW piece
bit 1: SW piece
bit 2: SE piece
bit 3: NE piece
* L1: owner of the road
* L2 bits 0..2: 0 - on bare land, 1 - on grass, 2 - paved, 3 - with streetlights, 5 - tree-lined, 6 - on grass with road works, 7 - paved with road works
* L3 bit 15 set = on snow or desert
L5 bit 4 set, bits 7..5 clear: level crossing
* L5 bit 3: clear - road in the X direction, set - road in the Y direction (railway track always perpendicular)
* L5 bit 2: set if crossing lights are on
* L1: owner of the railway track
* L2 bits 0..2: 0 - on bare land, 1 - on grass, 2 or higher - paved
* L3 bits 0..7: owner of the road
* L3 bits 11..8: track type
* L3 bit 15 set = on snow or desert
L5 bit 5 set: road depot
* L5 bits 3..0 - direction: exit towards: 0 = NE, 1 = SE, 2 = SW, 3 = NW
* L1: owner of the depot
* L3 bit 15 set = on snow or desert (not displayed, but set internally)

It would be good to have a way to test this information (at least road directions). And even better to change it (i.e. add road part to specified direction for example)
This will allow houses to connect themselves to the roads and look much better in the city structure.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/2081
@DorpsGek
Copy link
Member Author

frosch wrote:

  1. Sorry, but we are not going to grant newgrfs access to the map array. The current map array is already very different from the old TTD array you posted. And the bits in it will be shuffled/removed/added again in the future.

  2. I have no clue, what additional info you need. If you want to make houses aware of roads, the already available landscape class should be enough.

  3. More detailed information is subject of the road, and will only - if at all - be available to some NewRoutes feature in far future.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2081#comment4302

@DorpsGek
Copy link
Member Author

George wrote:

I do not ask to access array directly. I want to manage only the visible instances. In this current case I want to have:

  1. a check for existing road (is there a NE, SE, SW, NW part of the road) (a tile offset is the parameter, parts array as the result)
  2. a callback to put road parts on the tile (to fix removed road) or to remove road part (to fix added road)
  3. if it is possible the callback from point 2), to also add/remove trees, farm fields.

For example, 1x1 petrol station will check if SE, SW or NW road part is available at 01 (SW tile) and NE, SE or SW road part is available at 10 (SE tile) to allow building of the station, and with callback it will generate NE road part at 01 (SW tile) and NW road part at 10 (SE tile). This way it will stay connected if road exists. Also it will remove SW road part at 0F (NE tile) and SE road part at F0 (NW tile). This way it will remove wrong ways to the station.
To decrease CPU usage, such callback may happen periodically (every 256 or even every 2048 ticks).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2081#comment4304

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

I asked independently for same feature once, for same reasons. But providing the roadbit data isn't a current goal for OpenTTD. Being able to manipulate road bit data is definitely rejected, it's inappropriate for industries/houses to do this, and can mess with player routes.

Flyspray clean up: more than 5 years old, and not obvious what should be done with this next, so closing. If this offends, discuss with andythenorth in irc. Thanks.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2081

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs enhancement labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek