Hi,

this thread assumes that you've kept checked the option Keep replay after ◀▮ at all times. If you uncheck it permanently or temporarily, also look at topic: Rewind as Undo: Still Preserve a Loaded Replay.

Quote from: That thread
Rewind is browsing. You keep "Keep Replay After ◀▮" checked at all times. This is the default. You treat the replay functionality like a book, and use framestepping to browse through this book. Only when you're really sure, you cut content by clicking air or by assigning. You accept that Lix occasionally surprises you with unwanted assignments when you forget to cut the replay.

Let's try to improve this style even more. The behavior of Lix 0.10.3 is:

• While you're viewing a replay (a loaded one, or your current attempt after rewinding), Lix will assign by itself the remaining future assignments from that replay.
  
• Click air (really, click anywhere in the game map where no lix is) to cut the replay. Cutting discards all future assignments from the replay. Because you're now at the end of the replay, the floating R disappears.
  
• Or assign to a lix. This first cuts the replay as if you clicked air, then adds your now assignment to the replay. It also advances physics once, therefore the assignment is already in the past. Again, you're now at the end of the replay, and the floating R disappears.
  
• The tweaker (filmstrip icon) allows you to discard assignments (past or future), or to move assignments by single physics updates. Tweaking preserves the remaining future assignments, and this is deliberate -- it's really a tool to edit history and see what future results from that single change only. To discard all future assignments, click air as usual, or discard all future assignments manually in the tweaker.
  

Design hole: In Lix 0.10.3, there is no way to insert new assignments into the replay without cutting the replay.

I'd like to offer replay insert mode. Let's design it. Insert might become a user option (that you toggle from the options menu only, and never during play), it might become a mode during play, or it might even become a default.

In my recent livestream, I've experimented with a hacked Lix version that inserted all assignments instead of cutting the replay before appending the assignment. This was very useful when many lix had to work together in a tough singleplayer puzzle. But it was annoying on ccx's 100% Built By Lixes: Here, many builder assignments go to a single lix, and each assignment desynchs future assignments to that lix. I got surprised and annoyed from Lix constantly replaying future assignments because I failed to cut them. As a result, I'm considering:

Idea (*): Click air to cut all future. Assign to discard only that lix's future.

Example:
In phyu 100, lix #0 builds.
In phyu 200, lix #1 mines.
   Phyu 300 is now.
In phyu 400, lix #0 digs.
In phyu 500, lix #1 climbs.
In phyu 600, we nuke.

(Phyu means physics update, a.k.a. physics frame.)

In Lix 0.10.3, when you click air here, Lix cuts the two future assignments and the nuke. Likewise, when you assign to either lix #0, lix #1, or an entirely different lix, Lix cuts the two future assignments and the nuke, then inserts your new assignment for phyu 301. Even with idea (*), when we click air here, Lix cuts the two future assignments and the nuke.

The difference of idea (*) is when we assign. If we assign to lix #0, we discard the assignment in phyu 400 and the nuke, then add an assignment to lix #0 at phyu 301. If, instead, we assign to lix #1, we discard the assignment in phyu 500 and the nuke, then add an assignment to lix #1 at pyhu 301. If, instead, we assign to lix #29, we discard only the nuke.

Is (*) sensible? Or do you see a different way to improve Lix in this direction?

Should we offer (*) as an option, in addition to offering how 0.10.3 always cuts all future actions on assignment? Should it be a user option in the options menu, or should it be a button during play? Either way, should (*) be the default or should 0.10.3's cutting be the default?

-- Simon

Hi,

Lix has a single binary option for how Lix's replay rewinding works: Keep replay after ◀▮. In the options menu, if you hover over this option, you'll see this description: "On framestepping back (◀▮), keep future replay actions until you click air. If not checked, replay actions are removed when you undo them by framestepping."

There are at least two styles of play here:

• Rewind is browsing. You keep "Keep Replay After ◀▮" checked at all times. This is the default. You treat the replay functionality like a book, and use framestepping to browse through this book. Only when you're really sure, you cut content by clicking air or by assigning. You accept that Lix occasionally surprises you with unwanted assignments when you forget to cut the replay.
  
• Rewind is undo. You've unchecked "Keep Replay After ◀▮", never re-check it, and treat rewinding as undo. Lix won't ever magically assign anything by itself when you continue after rewinding. You won't ever be surprised. At any time, what you see is exactly what's in the replay. Unless you've loaded a saved replay, you won't ever be replaying during your attempt. You like this consistency, and you accept extra work from re-assigning.
  
• Undo your play, but browse replays. During your own play, you uncheck "Keep Replay After ◀▮", but you check it before watching saved replays. This offers the best of both worlds: You won't get surprived by maverick assignments after rewinding, and you can still browse existing replays backwards and forwards without dropping their content explicitly. To continue playing from a loaded replay, you click air.
  

Most players appear to prefer style 1. mobius prefers style 2, or possibly style 3. Forestidia prefers style 3. From a user-experience standpoint, I glean:

Support undo play, browse replay: Allowing style 2 (Rewind is always undo) as an option is really a misdesign, and it should have been style 3 all along (undo your play, browse replays). If Lix has a single binary option for these playstyles, it should be an option to toggle between styles 1 and 3.

• The current option toggles between 1 and 2. I'm considering to change it so that it toggles between 1 and 3.
  
• When you choose this (undo your play, but browse loaded replays), Lix won't cut anything from the loaded replay when you framestep back. When you play yourself, Lix will discard all rewound actions from the replay immediately.
  
• You can still interrupt a loaded replay by clicking air. You can continue your own attempt at the level from there. New: From this point on, Lix will discard rewound actions from the replay. This is new and exciting because in existing Lix, when you use style 2 or style 3, even style 3 doesn't offer you this sudden switching into rewind-is-undo.
  

This looks to me like a much improved merge of the styles 2 and 3.

Would anybody be annoyed over losing style 2 in favor of this?

mobius: How do you feel about this proposed change? Undo your play, but browse loaded replays. When you click air during a loaded replay, Lix shall switch from rewind-is-browse to rewind-is-undo.

We can also improve style 1 (rewind is browsing), or possibly we can split it into several styles and support them all, by turning the single binary option into something multi-way. But that's meaty discussion for a separate next topic: Replay Insert Mode for Lix.

-- Simon

Hi,

while I composed today's main issue about about negatively-worded binary options, I thought about how namida and Nepster worded those options in the config file. Then I stumbled onto this bug on the side:

NeoLemmix 12.12.5.

The user options file settings/settings.ini does not persist the option "Don't Replay After Backwards Frameskips". If you check that option during your session, it will be forgotten after the end. settings/settings.ini contains no line for that option. When you run NL for the next time, the checkmark will be gone. During play, then, NL will replay your actions after you've rewound them.

Expected instead: NL writes that option to settings/settings.ini. NL restores this on next session.

(Other options save properly to settings/settings.ini and restore properly.)

Who needs the option to ditch actions from the replay on rewind? I haven't seen anybody ranting about this bug before. It looks like I'm the first to run into it, and I only ran into it during the naming research, not because I wanted to toggle that option. Lix offers a similar option ("Keep replay after rewind") and Forestidia and mobius prefer in Lix the rewind to be an undo. Forestidia feels strongly about this in Lix. Thus, it feels like it makes sense to keep the option. But stay tuned over Christmas for the popcorn on insert-into-replay in Lix.

-- Simon

Hi,

NeoLemmix player version 12.12.5. Here is a screenshot from the interface options. You reach these options from NL's main menu, click the gear icon, then click the interface tab at top of dialog.



I recommend the following rewordings:

Don't Replay After Backwards Frameskip -> Replay after Rewind or Preserve Replay after Rewind. Invert the meaning of the checkmark. Maybe "Keep" instead of "Preserve". Another wording: Cut Replay after Rewind and keep the meaning of the checkmark, but I feel this isn't as clear. I'm not 100 % sure if "rewind" is clear enough if the program calls it "backwards frameskip" elsewhere, but "rewind" is at least popular and short.

Disable Background Images -> Show backgrounds and invert the meaning of the checkmark. Maybe "display" instead of "show"?

Hide Skill Shadows -> Skill Shadows and invert the meaning of the checkmark. A verb doesn't feel as necessary as with "show backgrounds" because the skill shadows feel exactly in the middle between a tool and a graphics option.

Use Spawn Interval -> Show Spawn Interval Instead of Release Rate and keep the meanig of the checkmark as it is now. Or "Spawn rate" if NL prefers that term. I don't have a good short wording. The setting is really only for visuals and has no bearing on physics. Even better: Convert the box into a radio-button option. Reason: It's a choice between two meaningful different things, not a togging of a single thing.

Hide Advanced Options in Level Select -> Show Advanced Options in Level Select and invert the meaning of the checkmark.

This report is more about the UI than about what really ends in the config files. You can remove negative wording in the config files, too, and invert the setting under the hood, or you can merely invert the meaning of the checkbox.

-- Simon

All streams will be at:

https://www.twitch.tv/simonnaar

-- Simon

Hi Proxima,

while streaming lemforum on twitch, Ramond found this backroute 2nd intended route in Rumble to the Bottom.

Spoiler

Idea how to change

Not necessary because Proxima deems it the 2nd intended route.

Lower the floor on which the exit sits.

The cost is that the level will look less than Smile if you love Lemmings. At least you can lower the floor uniformly, not merely dent it where the exit is.

-- Simon

Hi,

Proxima has laid down maintainership of Lix's lemforum level pack.

As long as we don't have a designated maintainer, we'll still work together on the levels, but nobody's word trumps others. I'll glean from the discussions what might be best, and implement that in Lix. Everybody, please speak up if I make odd decisions, and I'll happily do something else in the next version of Lix. Also, if you know lemforum well, you can step up to be maintainer and call the shots!

Lix lemforum is the flagship pack. One possibility is to stabilize lemforum, which means that we'll mostly fix backroutes, but avoid larger level swaps. This is best for speedruns, and it preserves the spirit of the contributions. If Lix gets fancy new features or new levels, we can put those separately from lemforum.

The alternative is to keep cutting weaker levels every now and then, and let lemforum slowly adapt to Lix when Lix gets new features like neutral lix, or new tilesets. This allows us to recommend lemforum to new players as a sample of the state of the art, and still have the vast majority of the content from 2010 to 2012, although not necessarily all of it.

You can mix the two ways to a degree, but they're fundamentally incompatible. I'd like to recommend to new players at least some cross-section of Lix's features and level designers' work. Proxima prefers a stable lemforum that we still recommend to new players as first pack, as we've always envisioned.

It's an amicable parting. I'm sure geoo's and Proxima's handwriting will stay visible on lemforum. Thanks for your contributions! Proxima, you're busy in life, about to get a foot into the door of the software industry. And in Deadly Rooms of Death, you've got a big project on the brink of release. I wish you the best of luck with both projects!

And barge in if we ever screw it up.

-- Simon

Ramond's list of episodes down here in this thread.

All video are preserved for 14 days on his main stream page:
https://www.twitch.tv/paramondox

-- Simon

Hi,

darkshoxx joind our recent Lix session on Saturday, November 26th. I streamed the session to twitch, and darkshoxx also streamed the session to twitch. To familiarize himself with Lix, darkshoxx played Lix singleplayer for an hour before the multiplayer session.

darkshoxx's Lix stream from 2022-11-26
(twitch will delete this on Dec ~10th)

Thanks for the stream! Here's my feedback:

Button caption: darkshoxx played the first level Any Way You Want and reached the end-of-singleplayer screen. The button at the bottom says "Back to the browser". darkshoxx reads the button, and says: "What? It's not a browser. Whatever."

Indeed, the level browser is a level selection first and foremost, and it only happens to be also implemented as a file browser that can browse to every level. I'll recaption the button to "Back to Level Browser" or maybe "Back to Level Selection".



Feedback on winning/losing: darkshoxx played Let's Block and Blow?, which has a save requirement of 19/20. First attempt, he flings several lix to death. Obviously this is wrong, and he resets.

Second attempt, he carefully assigns the exploder to not fling any lix to death. And he succeeds in this goal. This second attempt saves 18/20, it doesn't save the exploder and the blocker. This comes short of the save requirement of 19/20. Since he didn't fling anybody to death, he believes that he's won, nukes the blocker, reaches the end-of-singleplayer screen, and happily moves to the next level.

The end-of-singleplayer screen always presents the next level, even if you've lost. I like this, but it makes winning and loosing look nearly alike on that screen. The only difference are the small numbers at the top left, and the caption "Congratulations! You solved:" vs. "Try again:" over the solved level in the top right. We're all conditioned to not look much at the solved level in the top right.

During play, I'd still like the nuke to exit regardless of winning/losing. I think it would be awkward to pause after nuking a losing attempt.

As annoying as it is to admit: Winning and losing is central to every game, and Lix fails to present it properly. We need better feedback about winning/losing, both during play and during the end-of-singleplayer screen. I have loose ideas, but nothing ready to discuss yet.

---

This third finding is feedback for darkshoxx, it's not for Lix.

You had us in Mumble. At first, your viewers considered us too quiet. You raised the audio output in Mumble, but that didn't affect the loudness of Mumble in your stream. I think you should lower the Mumble audio output back to 100 %, to reduce the chance of audio clipping.

Then you put gain on the Mumble output. We were pretty loud already then, at least as loud as yourself. Then you put gain on the Mumble output a second time. Now, we were very loud, far louder than yourself. When I spoke, we got audio clipping in your stream. Maybe it's the mix of more than 100 % on the audio output, maybe it was from my side, but it ended loud in the stream.

I think a good amount of gain was how much you put on us the first time, before you raised it for the second time, together with Mumble at 100 %.

Or perhaps even slightly less gain than the first time (but still more than nothing)? Then you're at least as loud as anybody on Mumble, and your viewers want to hear you after all.

-- Simon

Hi Proxima,

in 2017, you suggested the following, which is also github issue #376:

Quote from: ProximaIn the replay browser, display the full replay filename under the level name on the right, so that it's easier to distinguish multiple replays in the common case when the default filename does not display in full in the list on the left.

I've come around to implement this. Look at the attached images; they differ in the bottom two lines of the nameplate (= the text between level preview image and the big buttons). I assume that you're still running Lix in 640x480, it's a rather tall resolution at 4:3, leading to cramped horizontal space.

The nameplate abbreviates the beginning of the replay filename, so you can always see the last part of the filename. Compare this with the file browser's listing at the left-hand side of the screen: It abbreviates the end of the filename, as is customary for abbreviating text in general.

Implemented in 0.10.1 is the first attached image: It says "Replay:" in line 3 and has a big arrow for the pointed-to level in line 4.

• Is the first image clear enough about what's the replay file and what's the pointed-to level? Captions are up for discussion.
  
• Does the nameplate show enough of the replay filename? The idea is that for really long filenames, you'll have the browser listing for the beginning, and you'll have this nameplate for the end.
  
• Do you still run Lix at 640x480?
  
• The second image is an alternative idea: Shorten the "Replay:" in line 3 to some single symbol and shorten the pointed-to arrow in line 4 to match the symbol in line 3. Is that better or worse?
  
• Or do both solutions suck and you need something else?
  

-- Simon

Hi,

everybody is busy near the end of the year, therefore I don't want to plan a big multiplayer session on short notice. Instead, let's meet in Mumble for loose discussion ("campfire" or "fireside chat") this Saturday, December 3rd, starting 17:00 UTC. Who's up?



Ideas for the discussion:

• I'm working on writing handicaps into replays, and playing back multiplayer games from replays with the correct handicap. We can test this together before I'll release 0.10.2.
  
• Level reorderings in our flagship pack, lemforum.
  
• Game modes involving neutral lix. Which good ideas can we copy from NeoLemmix? What should be a level option, what should be a property of the goals/exits? At the September 2022 campfire, I discussed this with geoo, but haven't written anything on the forums about it.
  
• Solving levels together on livestream is fun. I had a great time with Flopsy, mobius, and Ramond this past Sunday. Let's do it more often?
  
• Anything you like. Bring your own topics!
  

If you don't have time, no worries: I'd like to have campfire every couple weeks/months. We don't set in stone any plans for development. Important things should go through the forum in any case, giving everybody a chance to comment on plans.

See you in Mumble!

-- Simon

Hi,

namida said in the closed topic Any changes / additions needed in replay?:

Quote from: namida on December 31, 2021, 12:15:26 AM
last-minute idea come up on Discord - saving the frame on which the replay is expected to complete.

Quote from: namida on November 06, 2022, 11:54:13 PM
Commit 6b1bca2 implements this.

Mass replay check will make use of this too. Currently, a replay check will give up and return "undetermined" if 5 in-game minutes have passed since the last action and the save requirement is not yet met. It will now only do this if it's also been at least 5 in-game minutes since the expected completion time, if one is set in the replay file.

What moment will the game choose to write into the replay as completion time?

Sensible candidates:
* When the replay satisfies the save requirement,
* when the replay wins a talisman,
* when the replay wins all talismans,
* when you lose all lemmings.

At the game moment we save the replay, some replays satisfy none of the above. Will the game extrapolate to find a completion time, or will it write nothing? I assume you don't extrapolate. The completion time dosen't seem important enough to compute it at all costs.

-- Simon

Hi,

Consider the following two-player map.

This isn't an exact map from Lix, but the rough shape is common enough in two-player Lix: Player A goes from top-left to bottom-right, and player B goes from top-right to bottom-left.



Let's assume:

• You start at the red hatch, and you're planning a route to the red exit.
  
• You have reasonably many builders, platformers, bashers, miners, and diggers.
  
• Both hatches have steel. You can still attack the opponent's hatch, but that won't decide the match at once.
  
• Your route will cross the opponent's route somewhere.
  

What will be the shape of your route?

Straight Line

You can mine straight from the hatch to the exit. This produces a linear path.

The problem is that your opponent can sabotage this path: He can send lone saboteurs to the !-marked area, destroy the terrain, and drown your lix. It's always easier to destroy terrain than to rebuild it, and you'll lose several lix here. You'll have to invest a lot of attention to the defense of this single area.

It would be even worse to dig near your hatch, then bash across near the water. Your crowd would have to pass close by the opponent's exit, that's a risk in itself, and the sabotagable area over the water will be even wider than in the direct straight line.

Arc

A better approach is this arc-shaped route. You start to go across horizontally. For even more resilience, you can try to get your crowd on top of the trees.

High routes are strong routes: Your opponent has a harder time getting to you. But you yourself can still get down easily enough. If your opponent bashes through your stairs, you fall back to the grassy surface. Even the grassy surface is still higher and safer than the linear diagonal route from the previous example.

Near the exit, the arc bends downward. You approach the exit in a steep slope -- considerably steeper than a miner's slope. This steep slope is resilient:

• You won't splat anywhere.
  
• When your opponent removes some terrain around you, it's okay.
  
• He can't bat you into oblivion, you're well away from the edge of the map.
  

Don't approach your exit perfectly vertically, that will risk splatting. High arcs are good, but if your arc is too high and stretches too far rightward, you'll risk overshooting the exit, and must turn your lix. Whenever your crowd must turn -- be it at a blocker, at a cuber's cube, or at other diggable terrain -- you're vulnerable to sabotage.

As a bonus, the arc allows good access to the opponent's hatch for your saboteurs, but you don't have to send your entire crowd to his hatch.

Most of our custom maps are more complicated than this example. You'll find steel or hazards in the way of your ideal arc, or the level offers only a reduced skillset. You'll have to be flexible, accept some risks, choose tradeoffs -- and that's what multiplayer Lix is all about.

-- Simon

Get the newest Lix:

Download Lix -- for Windows, pick 64-bit version
Source code
Changelog
Issue tracker

Lix 0.10.0 released:





The big new feature: Lix 0.10 offers handicapping in multiplayer games. If you're too strong for your group, consider to click the handicap icon with the unbalanced scales in the game room. You can choose fewer initial lix, fewer skills, a spawn delay, fewer points per lix saved, or any combination of these four handicap types.

It's up to our sessions to fine-tune the options! Let's see what's reasonable and what's less exciting.

Networking:

• The server allows 0.9 and 0.10 in separate rooms. Decide with your friends whether and when to update as a group to Lix 0.10.
  
• Both 0.9 and 0.10 players can chat with each other in the server's lobby. The 0.10 client will see both 0.9 and 0.10 rooms, and print a console error when you attempt to join a 0.9 room. Since 0.9 has no such functionality, the server will not show 0.10 rooms to 0.9 players at all; instead, the server will write a chat message to those 0.9 players in the lobby if any 0.10 rooms exist, suggesting to update to 0.10.
  
• Renamed the server executable from server to lixserv.
  

The networking fixes are the silent star of the show this year. The server will now continue to support older Lix versions (0.9.x) in separate rooms from Lix 0.10. I won't have to force everybody to adopt a new physics release (this 0.10, or a future 0.11, 0.12, ...)

Let's give the 0.10 physics a good shot. Besides handicapping, many small physics fixes made it into 0.10:

Physics:

• Fix #265: Allow simultaneous exiting. When you're playing a race map and reach the exit at the same time as one or more different teams, all teams will score. Before, only the red team would score.
  
• Fix #311: Top and bottom of maps are hollow. Terrain checks beyond those edges will not behave as if the edge row's terrain extended infinitely. Now, only the left and right edges of the level extend terrain in this way, not all four edges. Staircases built to the deadly ceiling will kill the builder as before, but now all following walkers will also leave the level and die.
  
• Allow ability assignments (climber, floater, runner) to blockers. For now, these assignments have low priority; we can raise the priority after playtesting as a UI change without changing physics.
  
• Fix blocker dancing: Now, walkers (and other non-blockers) don't move when they're both in a left-forcing blocker field and in a (different blocker's) right-forcing blocker field. Before, walkers would move sideways through the fields, turning each phyu. This looked like dancing.
  
• Fix #266: Grant batters extra backwards range against blockers. We keep forward batter range vs. blockers as in 0.9, even though it's a lot of forward range so the batter sprite needn't overlap the blocker to still bat the blocker. Nobody has complained so far, and it's nice to bat blockers without awkward precision. We keep the batter range against other activities.
  
• Half-fixed #397: The faller's distance in pixels fallen will not overflow the 32-bit int anymore. I didn't fix the overflow for physics updates yet, you can still play longer than what fits into the 32-bit int that counts physics updates (4.5 years at normal speed, or 46 days at turbo-fast-forward).
  
• Moved the frogs' trigger areas downward by 1 pixel, so that the coordinates are divisble by 2. No levels broke from this, not even geoo's Las Ranas Hermanas in Hopeless.
  
• Fix #410: Removed spike at top of both matt/beach/04 tiles (day and night). Before, both tiles had identical masks; now, both tiles still have identical masks, although the mask is different than before. There is no odd prong at the top right of those tiles anymore.
  
• Fix #414: Fixed transparency/air pixels in earth.png from the Oriental set. The top row of pixels was not fully transparent (that would be 0 % alpha); it had an estimated 5 % alpha. Lix treats that as solid. Walkers were walking over solid, nearly invisible pixels. Now, earth.png has full transparency above the earth. No levels broke from this change.
  
• Fixed #322: Don't wrap during tile group construction: Now, when you load a tile group on a small torus map, Lix will construct the group without wrongly wrapping the group's elements before grouping. Only when Lix has fully constructed the group tile, Lix will insert the group into the torus level.
  

Other:

• Adapted the singleplayer levels Cry for Me (from lemforum), Baywatch (by RubiX), and Walking in a Winter Wonderland (also by RubiX) to work well with the always-hollow ceiling.
  

All levels are proven solvable in 0.10.

-- Simon

Hi,

Flopsy and I have time to playtest Lix 0.10 (it's now released) on Saturday, October 29th, 2022. We can have a big session or a small one, it's no problem.

I still prefer to start at 16:00 UTC, but Icho prefers to later in general. What time of day suits you all? 16:00, 17:00, or 18:00 UTC seem to be reasonable candidates.

-- Simon

NeoLemmix 12.4.4 in Wine 7.15 on x86_64 Arch Linux.

1. I had NL 12.4.4 already set up, it wasn't a fresh installation.
2. I put Armani's pack Lemmings Uncharted inside NL.
3. I played some levels from Lemmings Uncharted, having NL download missing tiles successfully per level.

Then:

4. Run NeoLemmix (or have it already running).
5. In the main menu, click Settings.
6. In the settings dialog, click Style Manager.
7. Optional: In the style manager, click one of the styles to select.
8. Click Update All.

We get an error box: "Division by zero."

9. Click OK (the only button) on that error box.

Now, Download Selected and Update All are greyed out in the style manager. I can only click Cancel. I have not received any new styles that I didn't have in the list before.

See attached video for a demo of this.

---

Expected instead: The goal of the whole operation was to avoid getting the prompt to download missing tiles before every level. NL should fetch all styles from namida's central style collection, or at least everything from that collection that I need for my installed packs.

I have no idea what exactly you want to happen on Update All.

Per-level style download works fine. When I preview a level with missing tiles, NL offers me to downloads missing tiles from the net. When I accept, NL downloads the tiles, then reloads the map. Now, I see the map with all intended tiles correctly.

Fresh installation: The bug doesn't reproduce (or is different?) on a fresh extract of NL 12.4.4 from the big download button on neolemmix.com: Here, when I attempt step 8 in the repro above, I can't click Update All because it's greyed out. All lines (one line per style) are already green in the style manager. But I don't seem to have every style yet in a fresh installation.

I don't see how I can download all styles on a fresh NL installation. What is the intended way to download all styles (from your central style collection) in one shot?

-- Simon

Hi,

this Sunday will be too short a notice for an organized multiplayer Lix session. Instead, let's meet on Mumble for a loose discussion, without playing. I'll call it a campfire discussion.

Possible topics to discuss:

• Physics on 0.10,
  
• user interface for handicap,
  
• neutral Lix, experimental physics to try in December,
  
• really long-term concerns, e.g., level maintenance N years after an author leaves,
  
• general Lemmings culture,
  
• ...anything you like. Bring your own topics!
  

This Sunday, September 25th, I'll sit in Mumble from 16:00 UTC onwards. Join me anytime on Mumble voicechat, very much like you would for a Lix session. (If you don't know my server, send me a private message on the forum here, I'll tell you.)

-- Simon

Hi,

this is the next suitable weekend that suits both Flopsy and me: Saturday or Sunday, October 15th or 16th.

I can play either Saturday or Sunday. What's everybody else's preferred day for that weekend? I recommend to start again at 16:00 UTC, you can join later.

There's a chance that Lix 0.10.0 is released by then. But I'll play it safe and say that we'll be using Lix 0.9.x one more time for this session. (Current is 0.9.47, but any 0.9.x will do.) I'm still aiming to release 0.10.0 before November 2022.

-- Simon

These are the C++-only posts from Simon blogs.

---

Apropos uniform initialization syntax.

I've used C++ for 16 years now and I still don't know every case of where the language guarantees a zero initialization and when it may leave something uninitialized.

Everybody learns early on that this int is uninitialized:

void foo() {
    int a1;
}

And that's about as far as "everybody knows" goes, I'd wager. Only many people, including me, know that these two are zero-initialized (although I'd still add the explicit = 0):

int a2; // at global scope
void bar() {
    static int a3;
}

The design reason behind this is that these ints live in "static land" instead of going on the stack where the zero initialization would cost runtime: The BSS section is a memory region that comes preinitialized for free when the operating system loads your executable and has to copy all of the executable code into memory anyway.

But I have no clue of the following, although I see this occasionaly in the day job, usually in C code that somebody renamed to .cpp later:

void baz() {
    int arr1[5] = {}; // Is anything zero?
    int arr2[5] = {0}; // Are the subsequent four ints also zero?
}

And do those initializations mean something different in C and in C++? Does it depend on the version of the C standard?

Here are some fun ways to initialize a single int, most of which only arise in theory. This is perfectly legal code that compiles. Are they all zero, are only some zero, are they all possibly uninitialized? I don't know.

void blub() {
    int a4{};
    int a5 = {};
    int a6 = int{};
    int a7 = int();
    int a8{int()};
    int a9 = {int()};
    int* p1 = new int;
    int* p2 = new int{};
    int* p3 = new int();
}

The two cases I should look up for definitive clarification are a4{}; and a5 = {};. The others might also be enlightening eventually, but expressions such as int() come up rarely enough that you can deem those esoteric.

And it doesn't end with ints where you have a chance at initializing them explicitly with zero. Occasionally useful in real life: You have std::vector<int> and you want to enlarge it by calling resize(). Does it zero-initialize the new values?

---

I have dark memories of possible nonequivalence of the following. It might be a false memory from early learner days in 2006, but I've never clarified it. Assume X is a class with a custom default constructor, and no other constructors (in particular, X doesn't define a constructor that takes a std::initializer_list). Do all of these run the default constructor? Quick reality check with g++ --std=c++17 tells me: Yes, all of them run the default constructor. But does the language really guarantee it, ever since C++98? I assume so, then...

void blip() {
    X x1;
    X x2{};
    X x3 = {};
    X x4 = X();
    X x5 = X{};
    X* x6 = new X;
    X* x7 = new X();
}

I should really read the standard directly more.

-- Simon

Hi,

On Saturdays or Sundays, what would be the best time of day for you to start a Lix session? Sessions usually run for 2-4 hours after this starting time.

Rampoina suggested: Our current time of 17:00 UTC (European evening) was suitable for him, but he prefers an earlier time of day, possibly right in the middle of European afternoon. For me, it's fine to play in the afternoon instead of the evening, but maybe the afternoon won't work for others?

The poll offers only the hours possible for myself. Happily complain in a post if sometime else is even better.

-- Simon