Larger events V2#3589
Conversation
Looks like I forgot to update the CMakeLists.txt when I uploaded the new files. My bad. This should hopefully resolve the build error.
This tweaks the code to detect the size of a sprite that has "$" in the filename and if it's above 48 pixels wide begins to add additional tiles to the left and right of the event which have the same collision data as the Event, meaning a larger sprite that occupies three map tiles will actually occupy three tiles worth of space. Events can be triggered from this larger area as well.
New version throws out the calculation logic and just lets the user tell the program how many tiles to occupy using specific strings in the filename: {_#} for the x-plane and {!_#} for the y-plane, where # is the number of tiles to occupy.
For example, $dragon{_3}{!2} would cover an area of 3 x 2 normal tiles.
You can also use even numbers adding a "L" or "R" to put the extra 16 x 16 tile on your preferred side (otherwise it rounds down to the nearest odd number.) You can also use "-" or "+" to tell the game to put all the collision boxes on the left (-) or right (+) side. For the y-plane trigger string, you can add "^" (or nothing), "=" or "v" to tell the system to load all the additional hitboxes above, split evenly or below the event, and add "U" or "D" to tell it where to put the offset tile if using an even number of tiles and the "=" tag.
So as an example: $dragon{_4R}{!3=} will cover one additional tile to the left of the event, two to the right, one above and one below.
Another example: $dragon{_3-}{!6=U} will cover two tiles to the left of the event, two below the event and three above.
The system now also correctly places the player when boarding and unboarding larger vehicles and activating events if the player is using a larger sprite themselves. It now runs independently of the larger sprite code and "$" trigger, so you can use this for normal 24x32 pixel sprites if you so choose.
|
While the idea sounds good I'm unhappy with the implementation. You still have your editor incorrectly configured: Wrong type of whitespace. Another issue I see is that the new collision code runs for everything. Not just "large events". This is bad for performance. Their should be a branch for "normal events" vs. "large events". But the major flaw I see is your (AI) rewrite of "CheckOrMakeWayEx". This is one - how i like to call it - high risk function: I evolved over the years to handle all the (weird) collision behaviour in RPG_RT. You cannot just completely reinvent the function. It requires careful consideration and testing among lots of games. Besides changing the structure of the functions you also rewrote the comments. Your AI even confidently added a fix to our code: But is this really a fix? Imo that was their intentional, otherwise a game would have hit that edge-case. Sorry but this is too much AI Slop for me and it's not my job to figure out whether that function still does what it's supposed to do. |
|
Thanks for the feedback. I'll see what I can do to clean up CheckOrMakeWayEx and deal with the white space and get a new version figured out. |
2 participants
V2 - New trigger, Y axis, vehicles and player
New version throws out the calculation logic and just lets the user tell the program how many tiles to occupy using specific strings in the filename: {_#} for the x-plane and {!#} for the y-plane, where # is the number of tiles to occupy.
For example, $dragon{_3}{!2} would cover an area of 3 x 2 normal tiles.
You can also use even numbers adding a "L" or "R" to put the extra 16 x 16 tile on your preferred side (otherwise it rounds down to the nearest odd number.) You can also use "-" or "+" to tell the game to put all the collision boxes on the left (-) or right (+) side. For the y-plane trigger string, you can add "^" (or nothing), "=" or "v" to tell the system to load all the additional hitboxes above, split evenly or below the event, and add "U" or "D" to tell it where to put the offset tile if using an even number of tiles and the "=" tag.
So as an example: $dragon{_4R}{!3=} will cover one additional tile to the left of the event, two to the right, one above and one below.
Another example: $dragon{_3-}{!6=U} will cover two tiles to the left of the event, two below the event and three above.
The system now also correctly places the player when boarding and unboarding larger vehicles and activating events if the player is using a larger sprite themselves. It now runs independently of the larger sprite code and "$" trigger, so you can use this for normal 24x32 pixel sprites if you so choose.