V0.5 Preparation thread

[acme_pjz]

Testing a level seems a bit broken. Nothing happens if you hit the exit (not even a message).

I think this is intentional; you don't want a "level finished" dialog breaks the level testing process...

There are a lot of render problems, too. The starting positions still render when you test a level. A broken fragile block leaves behind a trail of pixels. And a lot of other ugly things

I think these are also ... sort of ... intentional. You need to visualize the starting position and broken fragile block, etc. in level editor. The render code only checks that if current state is level editor, so in the test play they will be rendered as if it's in level editor.

- If you create a new level, then set goal recordings to 1 and the goal time to 10 seconds, then save, then set time to 0, then save again, then you playtest the level, you will notice the goal time is still 10 seconds.
- If there are multiple blocks overlapping, and you rightclick it, the block names might be too long for the context menu. For example, in German, the block name “Beweglicher Schattenblock” / “Bewegender Schattenblock” is too long. The context menu should be wider.

OK, I'll fix them before V0.5. The first one is definitely a bug.

It's weird there is no button at the bottom toolbar. I think if an additional button in the toolbar is added, then it will probably OK.

A button at the button toolbar opens top toolbar sounds a little bit weird, though Maybe there are better solutions?

Would be nice if the available keyboard shortcut is written in the tooltip

You mean the shortcut of some buttons (not all) in the bottom toolbar? Sounds reasonable, will be added in the next version.

Replace the checkboxes with radio buttons, i.e. circles with a black dot inside if selected.

There is a radio button texture but it looks ugly after testing, so I use the checkbox texture instead. Maybe replace it by a better one and we can change the code to use it.

The entries “Delete selected layer” and “Configure selected layer” don't work when you have selected the block layer. Either gray them out or hide them when the block layer is selected

Currently there are no code to dynamically add/remove items in the context menu. Gray them out sounds reasonable; I'll investigate it later.

- It's not clear that setting the goal time to 0 means there is no goal time (and the recording goal is ignored as well).
- Ideally, is should be possible to disable goal time and recordings goal with a checkbox individually. Forcing the user to remember “magic” values is not good.

I think add some texts to explain the magic values are OK since another two check boxes will occupy more spaces. Will add it in next version.

- In the scripting window, there should at least be some note or pointer to a manual of some kind, as this is not self-explanatory at all.

In fact we don't have a manual yet Currently we can only point to the ScriptAPI.md file.

The level format now appears to support layers. Apparently it is now “legal” to place normal blocks as scenery. They look EXACTLY like real blocks, except they act like empty space. I don't like this concept. It doesn't seem to be (ab-)used yet, but I can already see a future of low quality troll levels with many fake blocks, since they are in the background layer. This is a bad idea, trying to figure out which blocks are fake in a level would be just a chore and not fun at all.

I think the layer system is interesting, but it should not be trivially possible for such abuse. Using normal-looking blocks as scenery is just evil. Foreground and background layers should really only allow scenery blocks, not fake blocks that look like you can walk on.

At first only scenery blocks are allowed. Use the normal-looking blocks as scenery is added later as a partial solution of https://forum.freegamedev.net/viewtopic ... 334#p32924 :

One thing I would like to see is a solution for the borders of (small) levels.
Now we have multiple resolution support some levels of the Castle Rescue levelpack look a lot less nice.
A castle wall suddenly stopping. If we add support for a repeating part that stretches to the edge of the level it will still look good when the screen is larger than the level?

The way to determine whether a layer is foreground or background is weird. Why does the name matter at all? Also, apparently capitalization matters as well, which is even more confusing. This means the layer “g” is a foreground layer, but the layer “G” is a background layer. Can't this nonsense just be abstracted away from the user? Maybe by adding these “magic” letters automatically at the start of the layer name, but hiding them in the editor. I.e. layer “Alpha” is internally saved as “bAlpha” (background) or “fAlpha” (foreground).

IMHO current solutions is the easiest solution (although weird for users). Your suggestion is more user-friendly but it needs some GUI changes, e.g. when creating/renaming layers you need to choose either foreground or background layer besides the layer name, which adds one more step (and I think this will not make user more convenient). I'll reconsider your suggestion later.

This means you can make spikes invisible ... Any open space might hide spikes or the exit

No, make a block invisible means that it will not participate in game logic. That means that if spikes are invisible they will not hurt you anymore. In fact this is an ad-hoc simulation for add/remove blocks using script (currently we don't support add/remove blocks dynamically yet).

give them a completely different (fake) appearance

This is possible but it's not the intended usage of this feature. I think it's reasonable if the theme defined some special scenery texture (for example texture for bridges, fragile bridges, etc.) and if you want the blocks/fragile blocks looks like a bridge. I think we can't prevent the level makers making trolling levels if they want (it's already possible in V0.4 or older versions, for example hiding a spike behind a shadow block, or using shadow blocks to cover the whole map completely).

[acme_pjz]

Hello all,

I have fixed some bugs and implemented some minor improvements reported by Wuzzy:

{l Code}: {l Select All Code}

[x] The Programmer achievement should also count if you play a release candidate version
[x] Make the F3 key work in level completed screen
[x] ad-hoc fix the theme file for resizable teleporter, collectible, swapper, checkpoint, fragile, start position
[x] remove swap1000 achievement
[x] change tutorial level 15 target time since collision code has changed
[x] level finishing screen, the text at the top part of the screen is too close to each other, almost touching (for German)
[x] show loading when downloading the addons
[x] target time/recordings bug in level property screen
  set goal recordings to 1 and the goal time to 10 seconds, then save, then set time to 0, then save again, then you playtest the level, you will notice the goal time is still 10 seconds.
  *** target time = 0 means no target time
  target time < 0 means no target time and target recordings
  target recordings < 0 means no target recordings
[x] autosize block selection popup
[x] gray out some menu item which is unavailable

I'm still waiting for bug reports which can be fixed before V0.5, and more translations.

If everything goes well, I plan to release V0.5 at around Oct. 1.

[EDIT] I think I should postpone the release date to Oct. 6 or 7 since now we need to fix some more things

BTW, I already implemented some new features in V0.5.1 development branch, for example, framework for dynamically add/remove blocks .

[Wuzzy]

You need to visualize the starting position

I suggest to make the icons for the starting positions semi-transparent. If you test, it's a bit confusing to have two player characters visible in full opacity.

I think this is intentional; you don't want a "level finished" dialog breaks the level testing process...

Well, in that case, then at least write a simple non-modal “Level finished” pop-up in the bottom right corner, along with # of recordings and time, without stopping the level. This would be both lightweight and still communicates the critical info. You can safely reuse a string from the winning screen. Maybe later, could also write the finishing time/recordings as extra-popups on hitting the exit.

IMHO current solutions is the easiest solution (although weird for users). Your suggestion is more user-friendly but it needs some GUI changes, e.g. when creating/renaming layers you need to choose either foreground or background layer besides the layer name, which adds one more step (and I think this will not make user more convenient). I'll reconsider your suggestion later.

Well, I think background layers are more important than foreground layers, so the default selection should be background layer.
This weird alphabetical order (which is even weirder with capital letters) is much more confusing IMO.

A button at the button toolbar opens top toolbar sounds a little bit weird, though Maybe there are better solutions?

A simpler solution: If you click the “add block” button when it is already selected, you toggle the block toolbar on and off.

I have attached radio buttons.

You mean the shortcut of some buttons (not all) in the bottom toolbar?

Yes.

Currently we can only point to the ScriptAPI.md file.

Still better than nothing. Write something like “Open /path/to/ScriptAPI.md file in a text editor.”

Bugs related to the crate (pushable block):

- Crates sometimes render behind shadow blocks of all types. They should always render in front of shadow blocks, just like the player does. For better consistency
- Crates sometimes also render behind exits, swappers, checkpoints, collectibles, notice blocks, switches, teleporters
- Crates do not collide with spikes. I suggest they collide with them as if they were normal blocks. This would make crates useful to create a path over spikes.
- Crates are moved by conveyor belts, but they behave wrongly on moving blocks: On a left/right movement, the box stands still. On an upwards movement, the box glitches through the moving block and falls down. Only with an downwards movenent, the box goes down correctly
- Crates do not trigger floor buttons

Another bug: I have downloaded a few add-on level sets. But after restarting MaMS a couple of times (or after some time has passed), the add-on menu claims I have installed none of them. But I didn't delete any of them and still can play them normally. Trying to download them anyway gives me an error, that the directory ~/.local/share/meandmyshadow/levelpacks/<PACKNAME> already exists.
Strangely, sometimes the “installed” state is preserved, so this bug is not reliable. Sadly, I do not have reliable instructions for you to reproduce this bug.


PS: Where do I find the current developer version of MaMS? On Sourceforge it seems to be stuck at revision 687 from the year 2014, and I can not see any evidence of your bugfixes so far.

PPS: Another bug: If you select a completed level with no time/recording goal (getting gold automatically), then no medal is shown at the level icon at the bottom left corner.

PPPS: It is not possible to set a goal time >100s. Bad for large levels.

[acme_pjz]

I suggest to make the icons for the starting positions semi-transparent. If you test, it's a bit confusing to have two player characters visible in full opacity.

What do you think if we use a gray box with a player/shadow portrait inside it as the image of starting position? I remembered that we used such a picture before for some times. But I don't know the reason why it is replaced by the image which is identical to player/shadow now.

Well, in that case, then at least write a simple non-modal “Level finished” pop-up in the bottom right corner, along with # of recordings and time, without stopping the level. This would be both lightweight and still communicates the critical info. You can safely reuse a string from the winning screen. Maybe later, could also write the finishing time/recordings as extra-popups on hitting the exit.

Good idea

Well, I think background layers are more important than foreground layers, so the default selection should be background layer.
This weird alphabetical order (which is even weirder with capital letters) is much more confusing IMO.

I will implement this in the next version. For the V0.5 maybe we should ask them to always use "bg<NUMBER>" for background layer name and "fg<NUMBER>" for foreground layer name

A simpler solution: If you click the “add block” button when it is already selected, you toggle the block toolbar on and off.

Good idea:)

I have attached radio buttons.

Thanks

- Crates sometimes render behind shadow blocks of all types. They should always render in front of shadow blocks, just like the player does. For better consistency
- Crates sometimes also render behind exits, swappers, checkpoints, collectibles, notice blocks, switches, teleporters

Currently if you add a crate then add other objects, the newly added object will be in front of the crate. I think we can discuss if we should always render the crates in front of other blocks.

- Crates do not collide with spikes. I suggest they collide with them as if they were normal blocks. This would make crates useful to create a path over spikes.
- Crates do not trigger floor buttons

These will introduce game mechanics changes Maybe we should ask others for opinion first.

but they behave wrongly on moving blocks: On a left/right movement, the box stands still. On an upwards movement, the box glitches through the moving block and falls down. Only with an downwards movenent, the box goes down correctly

Unfortunately this is a bug and limitation of current collision system And this also depends the order you put them into level editor I already discussed with Edward_Lii in this thread (in the first page).

Another bug: I have downloaded a few add-on level sets. But after restarting MaMS a couple of times (or after some time has passed), the add-on menu claims I have installed none of them. But I didn't delete any of them and still can play them normally. Trying to download them anyway gives me an error, that the directory ~/.local/share/meandmyshadow/levelpacks/<PACKNAME> already exists.
Strangely, sometimes the “installed” state is preserved, so this bug is not reliable. Sadly, I do not have reliable instructions for you to reproduce this bug.

Oops, this bug sounds awful. I haven't seen this bug, though.

PPS: Another bug: If you select a completed level with no time/recording goal (getting gold automatically), then no medal is shown at the level icon at the bottom left corner.

I think this is fixed in the latest nightly build.

PS: Where do I find the current developer version of MaMS? On Sourceforge it seems to be stuck at revision 687 from the year 2014, and I can not see any evidence of your bugfixes so far.

Here https://github.com/acmepjz/meandmyshadow . I haven't setup the V0.5.1-dev nightly build yet, so you have to compile it from source.

PPPS: It is not possible to set a goal time >100s. Bad for large levels.

Oops. Will fix it soon.

[Wuzzy]

I think we can discuss if we should always render the crates in front of other blocks.

Crates should be in front of shadow blocks for the same reason the player is in front of shadow blocks. It's a shadow. Also, it just looks horrible to see a crate fly behind a shadow block.
As for the other blocks, this might be debatable, but crates must be at least consistent, i.e. always in front or always behind, not depending on object order in level editor, as this leads to hilarious situations in which a crate might render in front of some swappers, but behind some other swappers. I think at least the notice block should be rendered behind crates as it's often not essential and it just looks odd when it renders in front of a crate. Others are indeed debatable, yes.

What do you think if we use a gray box with a player/shadow portrait inside it as the image of starting position?

Good, as long it's subtle.

These will introduce game mechanics changes Maybe we should ask others for opinion first.

Well, crates flying through spikes just feels very very wrong, they pretty much look and “feel” they should be an obstacle. Floor buttons are debatable. Also, crates are a new addition and not part of a formal release, so there should be no fear of change at this stage. If anyone already depended on this behaviour, I'd frankly say “touch luck” for depending on bleeding edge. It should have been obvious that crates are clearly still WIP.

Here https://github.com/acmepjz/meandmyshadow

Then the homepage desperately needs updating.


EDIT:
Another problem with crates: They behave really weird when they sit on both a moving conveyor belt and a non-moving surface, they are confused and cannot really decide whether to move or not. It is difficult to explain, so I have attached a level for you to analyze (conveyor_test.txt).

EDIT 2: Just pulled 4e31d65a991ee349e2316a853f0ec11bab4dfa59. The level goals are now even weirder. Apparently I can set arbitrary negative time values down to -1. Like -1, -0.5, -0.0125. Trying to save the level with any negative time value doesn't work, on reloading, the time resets to the previous value. A new level starts with a time of -0.025. XD

EDIT 3: If you disable menu transition (fade to black), then click on Add-ons, the text “Loading …” is written over the menu items. It looks a bit ugly. I suggest to just insta-paint the screen black in this case.

[acme_pjz]

Crates should be in front of shadow blocks for the same reason the player is in front of shadow blocks. It's a shadow. Also, it just looks horrible to see a crate fly behind a shadow block.
As for the other blocks, this might be debatable, but crates must be at least consistent, i.e. always in front or always behind, not depending on object order in level editor, as this leads to hilarious situations in which a crate might render in front of some swappers, but behind some other swappers. I think at least the notice block should be rendered behind crates as it's often not essential and it just looks odd when it renders in front of a crate. Others are indeed debatable, yes.

OK, I will make the crates in front of all other blocks.

Well, crates flying through spikes just feels very very wrong, they pretty much look and “feel” they should be an obstacle. Floor buttons are debatable.

I think you're right. I'll think that if it's reasonable for the buttons triggered by crates.

Then the homepage desperately needs updating.

This is not under my control... I should ask Edward_Lii then. In fact I forked the homepage to Github too

For the other three reports I'll check them soon.

[Wuzzy]

This is not under my control... I should ask Edward_Lii then. In fact I forked the homepage to Github too

Is the link in the description of this forum under your control? This should be updated then.

[acme_pjz]

Oooooooops the commit 08bd7b7 breaks pushable block with vertical moving moving blocks completely (which affects V0.5 Beta and V0.5 RC) However, without this commit the script function block:setLocation() and block:moveTo() are completely broken I have to come up with a fix

[EDIT] I came up with a fix now

[EDIT2] It is fixed in commit 3d3c9ae. But I think we need some more time testing

Maybe a V0.5 RC2 is needed then...

This is not under my control... I should ask Edward_Lii then. In fact I forked the homepage to Github too

Is the link in the description of this forum under your control? This should be updated then.

No, this is not under my control, either.

[GunChleoc]

Is the link in the description of this forum under your control? This should be updated then.

No, this is not under my control, either.

One of those people can change it for us: https://forum.freegamedev.net/memberlis ... de=leaders

[acme_pjz]

Is the link in the description of this forum under your control? This should be updated then.

No, this is not under my control, either.

One of those people can change it for us: https://forum.freegamedev.net/memberlis ... de=leaders

OK then. But I think we need to discuss with Edward_Lii to see if he agrees to do so.

[GunChleoc]

Definitely!

[acme_pjz]

Hello all,

I have decided to released yet another RC due to a log of bug reports after last RC See here https://acmepjz.github.io/meandmyshadow ... eased.html for release notes and here https://sourceforge.net/projects/meandm ... es/0.5rc2/ for download.

If everything goes well I plan to release the V0.5 final in next weekend, about Oct. 7. There are one week to find last bugs

[Wuzzy]

0.5 RC2 still has that unwinnable level 24 in the classic level set. I don't get why this is still not fixed. You shouldn't wait for permission to fix this (you already have it thanks to the license). I disagree with the reasoning. This level does not contribute anything interesting or fun to the level set, I think it can be dropped safely.

In the editor, when you open the context menu for multiple overlapping things, the tooltips of the select and delete widgets are wrong; they include a keyboard shortcut in the tooltip, but these shortcuts are actually not working. Instead, they activate the editor features. Removing the shortcuts from the tooltip would fix this.

In the editor, the exit question is inconsistently used. If you made no changes, and click the “back to menu” button, no question is asked. But if you hit Esc, the exit question always appears. This is a bit weird. Intentional?

Floating-point numbers are not localized properly. I mean the decimal point, which might differ in other languages. E.g. the number “5.25” should be written “5,25” in German, but the rule differs from language to language. Hint: As far I can remember, this can be fixed by reading/setting the system locale or something like that.

Credits include a link to Sourceforge.

In credits, should replace http:// links with https:// links (unless HTTPS does not work on a particular site).

MAMS gets very confused when you are making a level set but decide to move levels around. Moving levels is common when the level set is still in progress. The problem is the locked state of levels if you try to play them. If you have completed a few levels before, then move them around in the editor, it's possibe that levels are locked in such a way that it's impossible to unlock the remaining levels, no matter what you do. E.g. if you move a locked level to become level 1, the first level will now be locked and can't be unlocked.

EDIT:

The add-ons description window which appears when you click on an add-on is rather small. The description always has a horizontal scrollbar (thanks to the links), which should be removed (horizontal scrollbars are considered bad usability).

I still have the “ghost add-on” problem, i.e. I have add-ons which don't show as “installed” in the add-ons list. :-( Do you have any idea on how to debug this? Just ask if you need more info.

If you watch a replay, the “play” icon that flashes in the bottom right corner of the screen overlaps with the level name.

[acme_pjz]

0.5 RC2 still has that unwinnable level 24 in the classic level set. I don't get why this is still not fixed. You shouldn't wait for permission to fix this (you already have it thanks to the license). I disagree with the reasoning. This level does not contribute anything interesting or fun to the level set, I think it can be dropped safely.

I just forgot to fix it I also forgot to update the credits for translations.

In the editor, when you open the context menu for multiple overlapping things, the tooltips of the select and delete widgets are wrong; they include a keyboard shortcut in the tooltip, but these shortcuts are actually not working. Instead, they activate the editor features. Removing the shortcuts from the tooltip would fix this.

Oops, will fix it.

In the editor, the exit question is inconsistently used. If you made no changes, and click the “back to menu” button, no question is asked. But if you hit Esc, the exit question always appears. This is a bit weird. Intentional?

I think this is sort of intentional (the original code is not written by me). If you click "back to menu" button you know that you are going to quitting level editor (and it's harmless if the level is already saved), but IMHO Esc key may be hit accidentally (e.g. hit the Esc twice in the test play).

Floating-point numbers are not localized properly. I mean the decimal point, which might differ in other languages. E.g. the number “5.25” should be written “5,25” in German, but the rule differs from language to language. Hint: As far I can remember, this can be fixed by reading/setting the system locale or something like that.

I don't know how to do that. I will look for some information first.

Credits include a link to Sourceforge.

In credits, should replace http:// links with https:// links (unless HTTPS does not work on a particular site).

OK, will fix that.

[EDIT] In fact the Sourceforge cannot be https; it doesn't work. Some other links are changed to https, though.

MAMS gets very confused when you are making a level set but decide to move levels around. Moving levels is common when the level set is still in progress. The problem is the locked state of levels if you try to play them. If you have completed a few levels before, then move them around in the editor, it's possibe that levels are locked in such a way that it's impossible to unlock the remaining levels, no matter what you do. E.g. if you move a locked level to become level 1, the first level will now be locked and can't be unlocked.

I think this is definitely an unconsidered corner case. Will loot at it soon.

[EDIT] Restart the game and the first level gets unlocked. I will make it work without restart the game.

The add-ons description window which appears when you click on an add-on is rather small. The description always has a horizontal scrollbar (thanks to the links), which should be removed (horizontal scrollbars are considered bad usability).

Yes, this window is indeed very small. I'll try to make it larger but the rooms for improvements are limited. The horizontal scrollbar is inevitable IMHO because of the links, however the remaining part of the description is word-wrapped with respect to the text box width if possible (there is an ad-hoc word wrapping code).

What's your opinion, hide the horizontal scrollbar even if the links are out of text box?

I still have the “ghost add-on” problem, i.e. I have add-ons which don't show as “installed” in the add-ons list. :-( Do you have any idea on how to debug this? Just ask if you need more info.

I'm very sorry for that, however I haven't reproduce it yet. Also, the original code of addon manager is not written by me, so I have no ideas for it. Do you run the game with terminal open? Maybe the error message helps.

If you watch a replay, the “play” icon that flashes in the bottom right corner of the screen overlaps with the level name.

This also needs new ideas, I mean a better way to indicate replay mode. Maybe currently we should only display the flashing icon on the top left corner?

[Wuzzy]

The horizontal scrollbar is inevitable IMHO because of the links, however the remaining part of the description is word-wrapped with respect to the text box width if possible (there is an ad-hoc word wrapping code).

Just move the URLs outside of the tiny description box and inside the main pop-up window which has much more space anyway.

Do you run the game with terminal open? Maybe the error message helps.

Nothing useful in console on startup. When I try to re-download an add-on I already have, I only get a standard error message:

WARNING: Levelpack directory '~/.local/share/meandmyshadow/levelpacks/CastleRescue' already exists, addon may be broken or not working!

But the installed state of add-ons seems to not have been reset for a while now.

EDIT:
If you assign any letter key to move up and down in the menus (e.g. “W” and “S” (WASD keys)), then entering those while you are entering text in a text input field will steal the focus, so you are forced to re-select the text input again. Workaround for users: Don't use letter keys for these actions.

EDIT 2:
If you used the editor to make custom levels and put them into the “user levels” category (levels w/o level set), then those levels will display incorrectly in the level selection screen if you want to play them. The level name is not shown (only the file name) and the recordings/time goals do not seem to be working at all.

EDIT 3:
Not sure if intentional or not, but if you fall on a stage 2 fragile block and immediately press the jump key, you will jump off the breaking block. It's not easy to do since you have to time it exactly right.

[acme_pjz]

Not sure if intentional or not, but if you fall on a stage 2 fragile block and immediately press the jump key, you will jump off the breaking block. It's not easy to do since you have to time it exactly right.

I think this is also a bug, will loot at it later.

[EDIT] This is introduced in a commit after V0.4 release which change the block event from synchronous to asynchronous I revert the event to synchronous but only for fragile block.

[acme_pjz]

Floating-point numbers are not localized properly. I mean the decimal point, which might differ in other languages. E.g. the number “5.25” should be written “5,25” in German, but the rule differs from language to language. Hint: As far I can remember, this can be fixed by reading/setting the system locale or something like that.

OK, I found the code to be something like setlocale(LC_NUMERIC, "de") or setlocale(LC_NUMERIC, "de_DE") for Unix and setlocale(LC_NUMERIC, "de-DE") for Windows. However, this only affects sprintf() and the tinygettext (which uses C++ iostream) is not affected. Moreover, this breaks sscanf() completely so some level files and themes are failed to load . Therefore I decided not to fix it.

[GunChleoc]

What you could to in the future is to provide a translatable string "%$1d.%$2d" and let the localizers take care of the separator. We can't do this now though because of the string freeze.

Another option would be to look into what the ICU library can do, but that would take more coding effort.

[acme_pjz]

OK, implemented in git master branch.

However, I found a random crash bug when exiting the game . I haven't found a way to reproduce it; it only occurred twice when I change the language multiple times, viewing achievements and statistics, and viewing level play select screen. I haven't found what's wrong with the code yet, it looks like something like double delete of ThemeBlock, but I'm not sure.

[acme_pjz]

I have downloaded a few add-on level sets. But after restarting MaMS a couple of times (or after some time has passed), the add-on menu claims I have installed none of them. But I didn't delete any of them and still can play them normally. Trying to download them anyway gives me an error, that the directory ~/.local/share/meandmyshadow/levelpacks/<PACKNAME> already exists.
Strangely, sometimes the “installed” state is preserved, so this bug is not reliable. Sadly, I do not have reliable instructions for you to reproduce this bug.

I think I found where the bug is. Currently the installed_addons is synchronized with downloaded addons list. The installed_addons will be erased in the following cases:

• If the game failed to download addons list or failed to process it. In this case all installation status will be lost.
• If there are addons removed or renamed in the download addons list, in this case the installation status for old addons will be lost.

I'm fixing the first case. As for the second case I don't have a good way to fix it, unless we make the installed_addons decouple with downloaded addons list.

[leovilok]

Here is the list of addons with license unclear:
...

• Geometry to Chaos by leovilok https://forum.freegamedev.net/viewtopic.php?f=48&t=3319 and https://forum.freegamedev.net/viewtopic.php?f=48&t=2922

Wow I totally forgot about that ... everything I made can be CC0 ... sorry for the delay. (Are these level still playable in current versions anyway ...)

[acme_pjz]

Wow I totally forgot about that ... everything I made can be CC0 ... sorry for the delay.

No problem, I have just restored the file on addons repository (with another months of delay).

(Are these level still playable in current versions anyway ...)

At least they loaded. But I haven't tested that the existing solutions still work.

[leovilok]

I tested a bit, it seem to be playable just as when it was created ... with a level design just as questionable.

[rudrisazz]

I noticed quite a few times being "squashed" without actually being "squashed", not sure what caused that, but will try and get to the bottom of that.

mobdro