https://jacobspctuneup.tk/TuxBuilder/HTML5/

Editing the level reverts the changes as soon as the editor is exited.

TuxBuilder built from https://github.com/Alzter/TuxBuilder/commit/13d29c0d7e837a72e09939a8ef654b1013bd22cc.

Improved Mr.Bombs animations and changed the Control wrapper to a Node2D https://cdn.discordapp.com/attachments/396022213100437504/632560306748391455/bomb.mp4

When you try to put decimal inputs into the scroll or move speed boxes in the layer settings menu, the value is saved as round but the spinbox displays it as a rounded value.

This may be an issue with Godot itself, so I'm not sure if it's possible to fix.

Just sliding in general needs a lot of work to happen.

First we need sliding physics. I'd imagine them to act like Sonic's roll physics, you gain momentum by going downhill (which is increased by the steepness of the slope) and then can use that momentum to go up hills or ramps. It'd be cool to have Tux be able to slide up walls if he went up a ramp but it's not required.

Second we need slopes to exist. There should be multiple variations of smooth slopes to slide on and slopes should probably auto-tile. Maybe there should be a tool to place slopes?

Reverts Alzter/TuxBuilder#54 - While I'm not against having the images compressed I think they should be compressed when "compiling" the project (it should probably come as an executable with an accompanying data folder) and having existing assets compressed while not having new ones receive the same treatment's a bit inconsistent.

Expected behaviour: Enemy particles like snowballs/iceblocks being squished or stalactites hitting the ground render when the action happens

Actual behaviour: Enemy particles only render sometimes

If you place a ramp 2 blocks below a full tile as shown below, Tux will get stuck and the ceiling collision sound will play nonstop until you duck out of it.

Enemies clip through the floor when squished in a one block wide space, I think they're constantly building up y velocity when they're in a one block wide space

Steps to reproduce:

1. Start TuxBuilder
2. Go into edit mode by right-clicking
3. Go to Objects > Misc > Spawnpoint.
4. Click into the sector.

Results: Tux Builder crashes.

			get_tree().current_scene.get_node(str("Level/", object_dragged)).position = $SelectedTile.position

Expected result: Spawnpoint gets added to the game.

Hey I saw your post on the forum and thought I'd give you a hand. I'm not really a SuperTux fan, but I want to help as many open source games transfer to Godot as possible. I know this isn't much but I'll see if I can get other basic stuff in the game working if you want help.

Hey I saw your post on the forum and thought I'd give you a hand. I'm not really a SuperTux fan, but I'll gladly try and help as many open source games transfer to Godot as possible. I know this isn't much since it's just bringing over assets, but I'll see if I can get other basic stuff in the game working if you want help.

Hi, thank you for the Super Tux Builder(Godot) repo I can learn a lot from you. If u have free time a need a little help. Is there any fix so the tileset shows the whole texture of the single tile in the editor?

Again thank you for the repo it helps a lot for new users in godot.

When attempting to full screen the game, rather than scaling up, everything stays the same size. And that size on a high DPI display is almost impossible to see.

The simple solution(although not best long term) is to change the scaling options in the project settings to "Viewport".

My WIP ice crusher which is working quite well by now.

Things to do (some optional):

• [x] Make sure eye movement points directly to Tux and not away from them
• [ ] Spawn particles when the crusher hits the ground?
• [ ] Investigate whether it's possible to add the different sizes in one .tscn file
• [ ] Ice crusher is currently too big for the editor image. Resize editor images automatically.