You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After lot's of tests of making long RVs on current BB size I came to the need of having completely new functionality for vehicles - assembling sprites (problem can't be solved by vehicle parts because of the current sprite sorter)
This functionality already exists for houses and industry tiles, so it should not be invented from zero, but requires to find a way to use existing code (if possible, may be makeing new code would be easier)
So. Wiki says:
Since 2.0.1 alpha 55 vcs 3, houses and industry tiles support an extended syntax as well, which looks as follows:
* 02 07/09 [ ( ) | ( 80)]...
where
-- for sprites sharing their bounding box with the previous sprite
xpixeloffset B x offset from the top left corner of the previous sprite
ypixeloffset B y offset from the top left corner of the previous sprite
80 B a literal 80h byte to distinguish from new-bounding-box definitions
For vehicles, the data looks as follows:
* 02 <loadtypes...>
where
loadtypes - The sprite sets to use for the states of load. Each entry is a WORD value in little endian format, and refers to the most recent action 1 sets. For example, action 1 sets 4, 5 and 7 would be encoded as 04 00, 05 00 and 07 00, respectively. Note the additional 00 which is needed because it must be a word value here.
The first entries of these are used when not loading. There have to be num-loadtypes of these. After this follow the sets to use while loading/unloading, and there must be num-loadingtype of those.
I would like to ask to provide the possibility to use sprites, defined like house tile sprites (with sprites over sprites), instead of sprite sets for vehicles for loadtypes.
Specifying bounding boxes for vehicles won't happen.
Composing vehicles from multiple sprites should be ok when based on static action2s. I.e. all sprites are defined in one action2 and not by evaluating the action3-2 chain multiple times. Same holds for offsets.
Action2 Format: No idea. It has to deal with loading/driving, loading state, and now also with offsets and multiple sets.
that's why I wrote the part for "sprites sharing their bounding box with the previous sprite"
Static? It should depend on location and curvature info. Is it static?
See the GRF in the post. As you can see, the difference between 8 sets of cabins is offset. It depends on location and curvature info. Hope you understand, what do I try to acheive.
George opened the ticket and wrote:
Reported version: trunk
Operating system: All
This issue was imported from FlySpray: https://bugs.openttd.org/task/3303
The text was updated successfully, but these errors were encountered: