GMSMariaEngine64PathOopsIn the Open World version's Stage Editor, I noticed that if you save a level with a footpath, and then import that same level with Prefab, the footpath isn't being spawned again into the correct place. Its position keeps randomly being moved along the Y/Z axis. Is there any way this can be fixed?
I did some test with both prefabs and copypastes, and it works for me (including rotations, and copying a footpath + moving along an axis causing the copy to be parallel to the original), but I did notice a bug - if you don't press "enter" to finalize the path data before saving a prefab file it gets saved in an incomplete state. This might be what's happening here?
The only other things I can think of is if the origin coordinate calculation gets messed up when you load the prefab with the marker size larger than 1x1x1 or if there was some funky interaction with you having something in the copypaste buffer already when loading a prefab - does it behave as expected if you press "alt" to quick-reset the cursor before loading the prefab?
Yes I did make sure to finalize the path data before saving the prefab (otherwise the path objects don't get exported at all!)
When I press "alt" to reset the cursor, that doesn't do anything because when the prefab is loaded the cursor automatically gets rescaled to the size of the prefab. So somewhere in the prefab code the origin coordinate calculation for footpath objects is messed up. Copy/pastes seem to be working fine though, so I'm not sure what's causing this
Yeah, and the prefab system uses the copy/paste system internally so they should behave the same...
The only thing I can think of that could differ is how editor_arrayify_patternobject subtracts the editormarker's position from each point in the path when copying (to get relative distances that can be rotated), does that somehow act differently when loading a prefab because the marker could be anywhere perhaps? (instead of a place that includes the path's origin, which is guaranteed when copypasting)
Took a good look in the code and I'm pretty sure the culprit here is within the function "load_level_editor_prefab()".
If I comment out the section "Normalize stuff around (0,0,0)", the paths are now generated in the correct place alongside in relation to the rest of the geometry.
Granted, now the cursor marker's position and size is a bit wrong, but I think that should be an easy fix... 🤔
Ah... that code only adjusts the object's regular coordinates and not the individual points of the footpath, so they're desynchronized. I wonder if it messes with how the new points are calculated when the rotations are applied? editor_unarrayify_patternobject doesn't actually use the object coordinates at all (only the individual points, which are absolute values relative to the editormarker and thus ALSO not affected by the footpath object's coordinates) so I don't see how this would affect it, but I also haven't touched this stuff since march 2023 so my memory is quite fuzzy.
Either way, I think the better way to fix it would be to, after updating the coordinates, check if oldcoords[3] is obj_footpath, and if so oldcoords[14] is the number of points; 15,16,17 is the first point's x,y,z coordinates and so on - you'd go through each such trio of points in ret_pattern[c] (which is the updated version of oldcoords) and subtracting xmin, ymin and zmin.
Not 100% sure if I did this the right way based on what you said, but this ended up fixing it! Edit: removed the image because that code was wrong... but I adjusted it so that now the prefab paths are in the correct spot and the cursor marker retains the correct size and position. Thanks for the help!
Hello again (Not sure if I should start a new thread since this one's getting pretty long...)
So as I'm using the Maria64 engine, I'm trying to clean/organize it a bit so that it'll be easier for me to work with as I make my game. This project of mine will be my next Steam release so I plan on going all out with 3D animated character models, realistic water, lighting, etc...
Recently though I'm having trouble with the collision relating to cylinder blocks. As you can see in the video here, the first cylinder's collision works as expected, but with the 2nd one (that's closer to the edge of the level) my bird character is able to clip through half of that cylinder. So the collision shape for that one is only a semicylinder. I have no idea why this is happening (and I tried checking if this happens in the original OpenWorld project too, but I'm not using the Skelani system for my character so maybe that messed something up in relation to hitboxes/collision?) Do you know what could be causing this?
Hmmm... my gut instinct is that it might be placed on a boundary for the collision checking grid, and is erroneously only added to ONE of the cells (objects that overlap a boundary are supposed to be added to all cells they touch).
I would check this by copypasting the weird cylinder and placing it in a bunch of different positions (altering both X and Y) and seeing if they are also glitchy or will work as intended. In particular if you move it sideways along the axis it's "cut off" at, EVERY cylinder at those coordinates would have half of its collision data missing, and if you move it "into the level"-wards, only the overlapping section would be missing collision data.
(And if this is actually the case, the next step would be adding some debug messages in terrain_buffer_add to investigate further, to e.g. print the "key" and ensure it gets added to every cell you expect)
Relatedly, is this line where the collision is broken the zero of any coordinate? I just realized terrain_buffer_get_key is using the "div" operator (integer division) and if GM interprets "round down" as "round towards zero" (instead of "round towards negative infinity" which is the correct definition) both the collision grid cells directly adjacent to the zero of any axis will map to the same key.