The terrain brush is definitely cool, but we've been using Tiled's automap feature to achieve a similar goal. If you load up one of the templates (ex. tiled/cave/cave_template.tmx), you'll notice there is an "automap" layer. From the available tilesets, there should be one called "set_rules". With the tiles here, you can paint into the automap layer and then run Map > AutoMap (shortcut: A). This will fill in the non-automap layers with the appropriate tiles (including collision). Our automapping rules also support variation where possible, like with the cave walls. Granted, I think we only used automapping because it predated the terrain brush (or was more stable at the time).
The Flare Tileset Definition Generator does indeed create the tilesetdefs in part 1 of your post. The reason they appear different is that the flare-game tilesets are single images, whereas the generator keeps the images separate (the part about Imagemagik being used in the generator is no longer true).
For packing, I use the 'flare/spritesheetpacker.py' script in this repo: https://github.com/dorkster/RectangleBinPack. The script has a --tileset option for processing Flare tilesetdefs.
Thanks for the thorough bug report! Though it is undesirable behavior in this case, it technically isn't a bug. Allow me to explain the flow based on the status of save_onload:
save_onload=true
Arrival map loads upon starting a new game
The cutscene event triggers.
The game is saved (for the first time) and then the game is unloaded to show the cutscene
When the cutscene ends, the game that was saved is then loaded.
The save file has the cutscene status set from when the event first triggered, so the event doesn't trigger again.
save_onload=false
Arrival map loads upon starting a new game.
The cutscene event triggers.
The game is unloaded to show the cutscene.
When the cutscene ends, there's no game to load (this is why the save file version is reported as 0.0). So the player is sent to the Arrival map by default.
No cutscene status is set, so the event triggers again.Hence the loop.
It is possible to fix this by adding 'save_game=true' to the cutscene event. That way the save will be triggered even if save_onload=false.
However, I think it's worth going a step further. I've added another property to misc.txt called 'save_oncutscene'. As the name implies, it globally controls saving the game when a cutscene is triggered. The default value is true to avoid "bugs" like this one, but modders can set it to false if they want to control game saves via events like in the above fix. The new property is available in v1.11.06.
Nice. You were a bit under-leveled for the Seagate fight, but still managed well. I usually try to be around level 4-5 there.
One of the reasons we keep the low level enemies when returning to old areas is to let the player see how much their character has improved. Maybe we could try mixing in some higher level enemies when those specific quests are active.
>Will this impact the lower end devices too badly?
It might, but users with really old hardware can just turn off parallax layers. If they're using the "sdl_hardware" renderer they might not even be able to load the texture if their video card doesn't support 4096x4096 textures. I had a machine with an Intel GMA950 that only supported 2048x2048. But at that point, Flare in general might be considered slow, even without parallax layers.
The terrain brush is definitely cool, but we've been using Tiled's automap feature to achieve a similar goal. If you load up one of the templates (ex. tiled/cave/cave_template.tmx), you'll notice there is an "automap" layer. From the available tilesets, there should be one called "set_rules". With the tiles here, you can paint into the automap layer and then run Map > AutoMap (shortcut: A). This will fill in the non-automap layers with the appropriate tiles (including collision). Our automapping rules also support variation where possible, like with the cave walls. Granted, I think we only used automapping because it predated the terrain brush (or was more stable at the time).
The Flare Tileset Definition Generator does indeed create the tilesetdefs in part 1 of your post. The reason they appear different is that the flare-game tilesets are single images, whereas the generator keeps the images separate (the part about Imagemagik being used in the generator is no longer true).
For packing, I use the 'flare/spritesheetpacker.py' script in this repo: https://github.com/dorkster/RectangleBinPack. The script has a --tileset option for processing Flare tilesetdefs.
The files in part 2 of your post are the actual map files exported from Tiled (via the Flare plugin). See this tutorial for enabling the plugin: https://github.com/flareteam/flare-engine/wiki/Creating-a-Map-in-Tiled
Thanks for the thorough bug report! Though it is undesirable behavior in this case, it technically isn't a bug. Allow me to explain the flow based on the status of save_onload:
save_onload=true
save_onload=false
It is possible to fix this by adding 'save_game=true' to the cutscene event. That way the save will be triggered even if save_onload=false.
However, I think it's worth going a step further. I've added another property to misc.txt called 'save_oncutscene'. As the name implies, it globally controls saving the game when a cutscene is triggered. The default value is true to avoid "bugs" like this one, but modders can set it to false if they want to control game saves via events like in the above fix. The new property is available in v1.11.06.
Thanks for the heads up. I posted a reply there, but it's awaiting mod approval.
It should be back up now.
Nice. You were a bit under-leveled for the Seagate fight, but still managed well. I usually try to be around level 4-5 there.
One of the reasons we keep the low level enemies when returning to old areas is to let the player see how much their character has improved. Maybe we could try mixing in some higher level enemies when those specific quests are active.
I messaged Clint about it. He mentioned upgrading the server to me back in June, so that might have something to do with it.
Today! However, this release is 99% engine updates with no new game content. I just haven't had the time to sit down and work on Flare stuff lately.
Nice. That's more variation than I was expecting!
Latest Windows build (v1.10.06): https://drive.google.com/open?id=1E7XyaPbL7AsMShA9WhMNUy2Z5Qg3V54G
>Will this impact the lower end devices too badly?
It might, but users with really old hardware can just turn off parallax layers. If they're using the "sdl_hardware" renderer they might not even be able to load the texture if their video card doesn't support 4096x4096 textures. I had a machine with an Intel GMA950 that only supported 2048x2048. But at that point, Flare in general might be considered slow, even without parallax layers.
Pages