Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

I had a look in the codebase and yeah, the code has been completely removed so they're completely gone, they're not just disabled.

The reasoning for removing stuff I remember at least, I never was happy with how the code basically needed a completely separate copy of the behavior for each axis (applying to both rendering and collision). Rotating cylinder objects in a prefab/copypaste didn't work as expected either (since they would have a rotated size but still be cylindric along the original axis) and starting to need special behavior for rotating certain objects felt like such a kludge I just couldn't keep going anymore. And the collision code for tunnels especially always was a nightmare, they are paper-thin so for smaller tunnels it was easy to get stuck, and there was no good way to connect tunnels to a start point or a corner that LOOKED right (for making sewers etc) so I always felt like they were a total failure. For making tunnel areas I'd recommend using separate prisms for the floor and ceiling instead, they even can be cobbled together into smooth rounded corners.

There's no way to rotate things around other axes. A lot of stuff treats the vertical axis in a special way (since Game Maker doesn't have a Z axis natively) so a lot of code (especially the collision code) wouldn't know what to do with e.g. a prism protruding along the X axis instead of at the top.

(+1)

Thanks for the clarification. I'm definitely going to try to add some of those features back (like the moving platforms) since I'm going to be using this engine for my 3D platformer game! Also in regards to the terrain generation— using a customizable .PNG image is nice, but it would be neat if there was also an option to generate randomized terrain on the fly. You just give it the max Z height and select what biomes you want on a pop-up menu and it spits out some terrain. Just a suggestion!

Uh oh. I've encountered two more runtime errors in the Legacy version's stage editor. You might need to update it again...

This first one happens when clicking on the "Enemies" tab in the editor (I'm pretty sure this error is the same one as before, with the minus signs preceding scripts so it's an easy fix)

___________________________________________

############################################################################################

ERROR in action number 1

of Mouse Event for Glob Left Pressed for object obj_editoroverlay:

DoNeg :1: illegal reference use

 at gml_Object_obj_editoroverlay_Mouse_53 (line 20) -                         script_execute(-bev)

############################################################################################

gml_Object_obj_editoroverlay_Mouse_53 (line 20)



----

And then this second crash happens when placing a "Waterfall" object under the "Misc Props" tab in the editor:

___________________________________________

############################################################################################

ERROR in action number 1

of Alarm Event for alarm 0 for object obj_waterfall:

unable to convert string "" to number

 at gml_Object_obj_waterfall_Alarm_0 (line 4) -     terrain_height  = max(terrain_height,real(my_creation_arg))

############################################################################################

gml_Object_obj_waterfall_Alarm_0 (line 4)

(+1)

I'll get to it right away!

(+1)

The fix should be available now :)

GMSMariaEngine64PathOops

In 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?

(1 edit) (+1)

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?

(2 edits)

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 

(+1)

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... 🤔

(+1)

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.