Let's go ahead and settle on variable/file naming conventions...

[DimensionWarped]

I'm seeing a fair few cases of variable and file names not following any kind of rigid rules, frequently in the same category of assets.

Sometimes we stick to camelCase, sometimes we use PascalCase, and sometimes we snake_case, and the situations for when and where are more or less random. This complaint is a little bikesheddy I know, but I'd like to go ahead and get this formalized before I start writing scripts. We can go back and correct what's already there later.

(for what it's worth, I have a habit of leaning towards snake_case since I'm mostly a C programmer these days, but obviously this isn't C and it may be way more appropriate to go with a modern language style naming convention. (PascalCase for major elements, camelCase for minor elements))

[Renhoex]

I've been using a lot of camelCase for the variable names, a lot of the file names are just like that because they were ported directly over like that from sonic worlds or just from what I was given.

You can tell which sprites were the ones I created based on that.

and I used the snake_case for function names to make them easier to identify.

[Renhoex]

Just a heads up I'll accept changes that don't fundamentally change how any of the mechanics or gimmicks work from the core unless it's a bug fix or slight changes to make it more accurate to the games.

Had a situation where someone tried submitting an update that changed how the bust-able walls worked to match sonic CD instead of adding/coding it in as a variation.

I just wanna make that clear because I don't want people to think I'll reject any pushes, I just want to keep the framework consistent.

[DimensionWarped]

I figure the assumption should be to make any content as Sonic 3K like as possible with exported variables being available in some cases to change behaviors as desired (or just alternate versions where that doesn't suffice).

[Renhoex]

yeah that's fine!

also forgot I use PascalCase for class based variables (mostly pre loaded entities)

[Renhoex]

also been thinking more on the moving hitbox thing, I think it's only needed if it's absolutely necessary because otherwise there can be some clipping issues, heck the sequence happens so fast I'm pretty sure it's just a visual thing and sonic's hitbox stays the same and static during the entire swing (like I think the sprites just get offset since the camera doesn't move)

I think the best way to test it out is to interact with the pole while placing an enemy in debug mode on the other side hurts the player when they're swinging around

[DimensionWarped]

Checked it out in MHZ1 and you appear to be correct. Enemies that were at my feet weren't causing damage.

Also in the process I noticed that spindashing into it made you be able to kill enemies that touched you while in the swinging animation while running into it made that event hurt you instead.

I suppose it isn't a shock that neither this gimmick nor the gimmick in FBZ that uses the same animation are located near enemies.

[DimensionWarped]

Hey, would you all mind if I got access to edit the wiki for this repo? And maybe project management too. I figure documenting how things work from the perspective of someone just coming into the engine could be useful and I also noticed that we have some projects that should be moved to the 'In Progress' section... and wouldn't mind adding my own projects to the list as well.

[Techokami]

I have sent you an invite to be a collaborator, since having extra help with documentation is never a bad thing