Single-Player Lemmings Streams

Consider livestreaming your solving. It's fun!

You can stream to Twitch, to Youtube, you can host your own RTMP server/webchat and link people to that, you have many options. Announce your streams in advance on the forums, then forumers can join your chat.

There are two main styles to stream single-player puzzles:

• No spoilers allowed in chat; this is the more common style, or
  
• viewers are actively encouraged to help solve.

There are nuances among both of the styles. darkshoxx forbids spoilers and considers even UI explanation in chat a spoiler.

I've always encouraged active solving; the idea is: If you join chat, you should be allowed to participate fully. If you weren't allowed to help solve, you'd have to limit your chat to irrelevant smalltalk. I wouldn't want to inflict that on you. (To solve 100 % hint-free, I'll solve off-stream.)

With active solving encouraged, again, there are nuances. It's hard to pin down what I really want. I've written: "Help solve, unless you had already known the full solution by heart." There is a problem here: This rule forbids hints that other people in the same chat are allowed to write after they live-solve a part of the puzzle in their head.

I'm beginning to think that my rule is bogus (help solve, unless you had known the solution before). There should be a rough guideline that you shouldn't outright spoil the solution immediately at the beginning. What that means in detail should be interpretation of the viewer, i.e., the guideline should remain largely unenforced. If you pop into my chat and want to give hints, you should give hints.

-- Simon

In May and June, I've streamed thrice, for a total of 10 hours.

I've got through ~30 % of the Level of the Year nominations on stream. I've given every played level a good shot, solving many level, and making progress on the others. Of every author with a nomination, I've played at least one level.

Mobiethan, Pieuw, and Icho watched live. Thanks for hanging in the chat!

I'm happy with the invested time. The mix of nominations is wonderful, with varied puzzle difficulty. It shows the creativity and spirit of the Lemmings community. Among the played levels, I have some secret favorites already, but I won't name any for now, lest it skew the polls.

I'll review the remaining unplayed levels offline before the voting. There had to be ad-hoc level selection during the livestream. If I didn't hit your best entry by chance, I'd still like to have tried it.

-- Simon

Thank you for the replays! 

The Maso 11 solution is totally fine and a clean solution. Great job! 

Bonus 1 Plethora's Temple needs a fix though. A little steelblock extrension should stop the easy miner. 


V 4.0 is out! 

Backroute fixes based on Guigui's replays:

- 5 01 (extended a steel block slightly)

I cleared the pack, very nice time had with those middle difficulty levels perfect for my solving skills at this time.
The hardest levels for me were Maso 11 A Hard Nut Level, and Bonus 1 Plethora's Temple. After finally clearing them, I looked at replays form kaywhyn and others to compare.

Maso 11 A Hard Nut Level : kaywhyn needs very precise timing on the bombers, close climbers and uses a "bash into steel" thing to turn the last climber around.
I'm joining another solution that feels more natural to me, and needs less very precise timing. The bomber is used to break the thin floor on the right and allows to make a symmetrical bridge structure to save the crowd.

Bonus 1 Plethora's Temple : I think this one is a backroute, since the level is cleared without ever going to get the pickups on the left side.
Just mine downright from the beginning and delay necessary lemmings for the pioneer to build the last bridge. I love how the climber skill is used to delay one lemming, which frees the crowd at the end !

I've added a poll.

I'm thinking of re-labelling the SuperLemmix versions of the OG styles (with edited water objects, exit positions, etc) as "amiga_(nameofstyle)" or "slx_(nameofstyle)" rather than keeping the "orig_" and "ohno_" author tags.

So, orig_crystal would become slx_crystal, and so on.

Reasoning:

At this point, the SuperLemmix versions are significantly different from their NeoLemmix counterparts. They feature the brighter Amiga colour scheme (a subtle difference from the DOS colour scheme, but a difference nonetheless), additional water objects and other NeoLemmix-incompatible items, and updated exit positions. I'd also like to be able to modify these styles further going forward without the concern of cross-compatibility.

It would also mean that the NeoLemmix OG styles (orig_crystal, ohno_bubble, etc) could simply exist in SuperLemmix exactly as they are in NeoLemmix, which would make porting levels from NeoLemmix much easier.

Note: it would still be possible to change the level's style to its SuperLemmix variant, should the level designer wish to do so for aesthetic/mechanical purposes. It would be a simple case of swapping the style of each piece from "orig_" to "slx_": this functionality would of course be added to the SLX QuickMod tool, and could even be added to the Editor itself for quick, single-click, on-the-fly style switching (it occurs to me that this should probably be a thing anyway, since the Editor supports both engines).

Designers who have already ported their levels from NeoLemmix to SuperLemmix (and thus made the necessary cross-compatibility tweaks) would be fully supported as much as possible if this change were to go ahead; I'd be prepared to personally help make the necessary corrections to each affected pack, and I'm sure Eric (who caretakes most of the "unofficial" conversions) wouldn't mind helping with this also, particularly since much of it can be automated anyway.

Note also that, if porting levels made in the SuperLemmix OG style variants to NeoLemmix, it would still be necessary to make the compatibility tweaks (exit positions, water objects, etc). The SLX QuickMod tool already takes care of this, but - as stated - I'll most likely add something to the Editor that can quickly make the necessary tweaks as well.

Nothing will change as yet; I'll run the poll for 14 days to get an idea of people's thoughts on this, and I'll also keep in close contact with Eric regarding this, as he's likely to be the user most affected by the proposed update at this point.

If it's decided that this will go ahead, I'll likely get it sorted within a few days of the poll closing to minimise impact going forward, and include the changes in the next SuperLemmix / SLX Editor update. I'm currently about 60/40 on it in favour of "yes", but I'll let it brew for the full 14 days and see if I still think it's worth it, or if there's an even better solution.

In the meantime, leave a vote on the poll, and post any comments or suggestions you might have. Thanks 

Stream is over! Recording will remain for 14 days at:

https://www.twitch.tv/simonnaar

-- Simon

Video: Splat ruler freezes CE for 5-10 seconds (70 seconds long, 4.4 MB)

This is an excerpt from my stream 3 weeks ago. I've had already played CE for 2 hours here.

-- Simon

Forestidia saw this in 0.10.29 again.

Forestidia's report

-- Simon

Thanks!

I have to investigate whether we draw from current state onto the new savestate (that we allocate), or if the current state becomes the savestate (and we allocate a new current state), drawing from savestate onto current state.

This can merge all of the following 3 phenomena,

(a) missing bridge slap during stutter,
(b) all terrain becomes black,
(c) failed VRAM allocation,

... into a consistent world-view: The theory will be: When a monitor turns off, something happens with Lix's window behind the scenes, all VRAM drawing during this short time has no effect (but won't crash), and all VRAM allocations with this window in this short time fail (and crash because Lix chooses to crash then). In case (a), Lix wants to draw only a brick, but in case (b), Lix wants to load an old savestate including all of its saved terrain.

Leftover consistency problem: Why does the terrain in case (b) become black ... it should remain the terrain from before loading the savestate, then, right? Details, details.

In any case, more to investigate.

All of this has given me ideas to ask directly in the Allegro IRC: How does an Allegro 5 window react to monitor turn-off, such stutter etc., and should the usercode (Lix) react or should Allegro react.

-- Simon

I tested a bit (Lix 0.10.29 - release build - win64 - Allegro 5.2.10):

• Monitor no. 2 is set as primary monitor.
  
• Before play, go to Windows's monitor/display settings, and choose: Extend the display to all screens.
  
• Start Lix.
  
• Observe how Lix starts on monitor no. 2 in software fullscreen.
  
• Start a level and play.
  
• During play, go to Windows's monitor/display settings, and choose: Display to only monitor no. 2.
  

Either:

Out of VRAM error:
193.41 src\basics\alleg5.d:26:
193.41 Out of video memory. Can't create bitmap of size 913x946 with flags 5120.

Or:

Graphics stutter for 0.5 seconds or 1 second. After that, Lix continues to run smoothly without further stutter. But if there was terrain modification in that 1 second of stutter, e.g., a builder was building, then the newly built bridge slap is not drawn, and will continue to be invisible throughout the future: