other formats [...] aren't explicitly intended to be supported.

I assume this means "supported by the lib". You've given lots of support for it already.

Does the lib outright refuse to load a file with an unwanted ending?

if [...] a format other than OGG or IT doesn't work at some point [...] I'm probably not going to try too hard to fix it.

In that case, the forced rename has put users in the worst of all situations. They won't see at a glance which files have stopped working.

-- Simon

Random properties of the upcoming implementation:

Replays won't record (change active skill in the skillbar) anymore. Instead, each assignment is augmented with information about the assigned skill. This makes the skillbar solely part of the GUI, like fast-forward. Playing back a replay will not change skills in the panel. Changing skills in the panel will not interrupt a playback.

I have written and tested backwards compatibility for older replays. Exploder assignments in older singleplayer replays will be moved forward in time. When playing back such an old singleplayer replay, the untimed exploder makes a crater at the same position as when played back in the currently released Lix versions.

An exploder assignment in a replay doesn't carry information about whether the exploder is timed or not. This is inferred by the number of players.

Exploder mass-assignments from the nuke are untimed in singleplayer, timed in multiplayer.

I am making a longer animation for the non-fling exploder. I'll show sprites when it's done. The exploder will stand still while going through the anim, as before. Thus, the crater is at the same position as when played back in the current Lix version. The explosion will happen a few frames later.

Exploders in mid-air will not go through the anim, but explode instantly. This is also unlike the current version.

From the new anim, it's less obvious that exploders can be assigned in mid-air. We have to think about this.

-- Simon

I'd lean towards ending the game, too.

It is common for new masters to make rules too hard on accident. You have noticed this surprisingly early, and then handled it really well by offering hints or an early end. It's much better this way than attempting to change the secret rule mid-game.

-- Simon

Only one type of exploder per level: This is already in the current release. I didn't expect there to be levels that use both.

Proxima: Will change Halfway down the stairs as you have described. I recommend you to post an updated version to the pack thread, in addition. This way, the change won't be reverted later, when geoo does maintainance work on the pack.

Your bomber-timing levels: Yeah, they don't seem trivial to me at all without timing. :-)

-- Simon

Yes, icon design is the next thing, and it's important. I didn't want to go here before making the above decision.

-- Simon

ccx has explained it perfectly. Thanks.

Right now, choose Integer scaling, or play windowed.

Support for all screen resolutions will come in the D port using Allegro 5. The support has been a development goal from day 0 there. Screenshot with my desktop resolution of 1280x1024, which is 5:4.

-- Simon

[12:28] <geoo> l.get_good returns true if the contained level is valid, and false if it's not or doesn't exist, right?
[12:29] <SimonN> right, not exist implies not good
[12:29] <geoo> so basically, when I hold the key I want the same to happen as in the !get_good case, right?
[12:29] <SimonN> right
[12:30] <geoo> except that it doesn't work

Later:

[12:34] <SimonN> the gameplay will again decide which level to load, what a mess
[12:36] <geoo> so it must be possible for levels to be both good and not good...oh wait nvm you're overwriting l
[12:37] <SimonN> the magic doesn't happen in this file
[12:37] <SimonN> gameplay/gameplay.cpp:106, determine_filename
[12:38] <geoo> haha, so is the function even used?
[12:38] <SimonN> which function?
[12:38] <geoo> ReplayBrowser::on_file_select
[12:38] <SimonN> it is used, but only to check whether the level is good
[12:38] <SimonN> if it's good, we go into the game, and the game again decides which level to use
[12:39] <SimonN> it so happens to come to the same conclusion as the browser
[12:39] <geoo> that's terrible redundancy
[12:39] <SimonN> this is extremely dumb code
[12:39] <SimonN> yes
[12:39] <SimonN> also, gameplay.cpp:109 the comment is wrong, but the code is right
[12:40] <SimonN> the comment should be "always use pointed-to level"
[12:41] <geoo> ok it works now

-- Simon

Thanks. I'll try to put it in the tooltips for now.

You're making a reasonable case against the buttons. Then, tutorial + tooltips seems to be the best we can do, other than fat in-your-face advertisements that obscure the main play area.

I will make two options: one to show tooltips, one to show skills on hotkeys. This was demanded a couple years ago already, I should have done it earlier.

-- Simon