Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Simon

Pages: [1] 2 3 ... 200
1
Contests / Re: The Level Solving Contest #7
« on: January 04, 2020, 05:32:44 pm »
Highly interesting that ccexplore's route finishes with the exact same stats than geoo's/mine. Merely from watching, I guessed that ccexplore's stats had to be higher, and I looked at the text replay to confirm that it's the same. Nice find!

ccexplore uses that the basher (that makes an 18-pixel-high tunnel) has 2 pixels of steel lenience at the top (basher will not cancel if steel falls within these 2 pixels). This is pixel-precise, but allows the basher to continue towards the outer wall. This avoids the brick that minim places.

My and geoo's solution is extremely fiddly and requires lots of framestepping. The tweaker (filmstrip button) to timeshift assignments was helpful. There is a leftover bug that the tweaker always covers the right-hand side of the screen/map, the map doesn't know whether the tweaker covers the map, and the hacky action happens near the right. Inclines me to fix this. :lix-winktongue:

Batting the infinite fallers on this map is fiddly unless the brick-layer is coincidentally well timed. Floating everybody would have been easier, but the floating nukes the total skills score that takes precedence over SAOBL.

I'll have busy weeks ahead -- moving out of my student's flat -- and can't run an immediate follow-up contest. But I've already gotten first ideas for when it's time. I'm contemplating to add/multiply/take-maximum-of the different scores instead of deciding on a lexicographical order.

-- Simon

2
Contests / Re: The Level Solving Contest #7
« on: January 04, 2020, 04:23:49 pm »
Thanks for hosting!

Only today, I find time to adequately reply. I'm about to watch the solutions in Lix.

Quote
Geoo's txt file I found harder to read than the others probably because he was using a considerably older version of Lix

geoo directionally forced some assignments. For example, the middle two lines here are directionally forced assignments; the first and last lines here are unforced:

! 969 0 ASSIGN=BATTER 8
! 1056 0 ASSIGN_RIGHT=BASHER 21
! 1062 0 ASSIGN_LEFT=MINER 10
! 1305 0 ASSIGN=DIGGER 10


In singleplayer with heavy framestepping, it has become less common to force direction.

I made directional force part of the replay format for networking games about 5 years ago. This was to combat latency between several players on the same team. E.g., you have a lix walking towards an abyss, and want to assign walker to turn her. If your teammate also assigns walker to turn her away, and both of you directionally force your walker assignments, the lix will only turn once, away from the abyss, and the second assignment becomes illegal as desired.

I've even considered to write every single assignment into the replay with directional force, not merely those where the player actively forces. I.e., for an unforced assignment, I would look at the highlighted lix's direction, and write the assignment forced with that direction. I don't know if that would be helpful or a hindrance, in any of the three interesting scenarios: a level's terrain changes, the physics change, and networking lag.

Anyway, that's rambling and getting technical; if anybody has strong feelings on this, we can happily make a thread from this idea. On to watching replays.

-- Simon

3
64-bit physics updates would be a physics change because the binary networking protocol hardcodes 32 bits for this field. :lix-evil:

But yes, it's sound to upgrade phyus to 64-bit or to stop physics at at 2^31 - 1. The stop is sounder game-design-wise but sadder mathematically.

-- Simon

4
Yes, it's an overflow bug in Lix. Good find, yes, Forestidia had the idea before, too.

It should be patched for 0.10.0, whenever that comes, as namida suggests, fallers that have achieved splat fall distance should remain splat-prone until the end of the fall.

In D, signed ints are defined to overflow by two's complement like an unsigned int, and only during interpretation treat the most significant bit as a sign bit. (In C and C++, signed int overflow would be undefined, even though implementations on contemporary machines often treat them like D has to.)

-- Simon

5
Lix Multiplayer Dates / Re: Lix Multiplayer: Sun, Dec 29th, 18:00 UTC
« on: December 29, 2019, 02:08:58 pm »
Sorry, no stream by me. I'm not at my home computer, I'm with my parents during the holidays and haven't set up the stream on my notebook. I'll try to stream the next sessions again!

IchoTolot usually records for Youtube, but he's also with his parents over the holidays, therefore I don't know if he will record.

In a pinch, if the asker has Lix, they can sit in our game room on the central server as observer.

-- Simon

6
Lix Main / Re: Lix 0.9.30 released
« on: December 29, 2019, 11:12:30 am »
Yes, any 0.9.x is good for multiplayer, in particular 0.9.29 and 0.9.30.

-- Simon

7
Lix Main / Re: Lix 0.9.30 released
« on: December 28, 2019, 10:01:36 pm »
Lix 0.9.30 released.

:lix-cool: Download for Windows
:lix: Download for Linux 64-bit
:lix-evil: Source code
:8(): Changelog
:8:()[: Issue tracker

How to update (click to show/hide)

It's been a while! In August 2019, I got a fulltime job as a C++ engineer. Naturally, I've begun to relax with software-unrelated things during weekends. But as promised, here's a Lix release still in 2019.


  • Fix #339: Imploder animation: Now, purple stars and vortexes circle around the center, then get sucked into the center. The old animation was too slow and subtle.
  • Fix #388: Oblivion sound was too noisy and high-pitched. Replaced this sound effect with meow-like voice acting that is not shrill.
  • lemforum: ccexplore fixed a backroute in Brickout.
  • Always print hotkeys on buttons' lower-right corner. Removed user option that toggled whether hotkeys would be printed on buttons.
  • Code: Remove body encounters from physics implementation; these happened at (foot - 4), (foot - 8), (foot - 12). Always check foot encounters instead. Before, only fire hazards checked for body encounters. Draw larger trigger area (in the editor) for fire to compensate. No changes to file formats. No changes to physics.
  • Multiplayer maps: Added Down with Frogs by Flopsy. Added remake of Humps (2-player map from 2010) using Lix's earth terrain. Removed endless falls at the side of Honeypots.
-- Simon

8
Challenges / Re: How to view Lemmix replay (.lrb) solutions
« on: December 28, 2019, 02:38:47 pm »
Magnificent resourceful post!

Press U to save a replay during play. (I forgot whether this opens a dialog or merely saves a file without any feedback.)

-- Simon

9
Help & Guides / Re: How to play Lemmings 2 in DOSBox
« on: December 24, 2019, 02:34:02 pm »
output=overlay
windowresolution=1280x960


Not all output methods support bigger windows. Nastily, the default output=surface does not allow bigger windows, and then windowresolution would be ignored without error or warning. output=overlay supports bigger windows. This windowresolution=1280x960 is already 4x but you can increase it further.

-- Simon

10
Lix Main / Re: Trigger area of frog trap too small? (Spoiler heavy)
« on: December 14, 2019, 08:53:17 pm »
I'm most surprised about the horizontally-narrow area. The frog is so wide and yet it has the most narrow trigger. Widening the trigger would suit the frog, but that's more intrusive than the downwards trigger extension. I'd have to test replays.

-- Simon

11
Lix Main / Re: Trigger area of frog trap too small? (Spoiler heavy)
« on: December 14, 2019, 08:47:16 pm »
Yeah, from this comparison I agree that the frog trigger should extend downwards for 1 extra pixel, for consistency with other traps.

I believe: The lix in (my post's second image from your replay) would still survive even if the frog's trigger extended downwards by that 1 extra pixel, and thus wouldn't fix your original concern.

-- Simon

12
Lix Main / Re: Trigger area of frog trap too small? (Spoiler heavy)
« on: December 14, 2019, 08:31:29 pm »


Frog y-3 is friendly to walkers. The other frogs (y-2, y-1, normal) are all deadly. Do you find this strange, too?

In particlar, y-2 has a a one-pixel air gap between belly and floor, yet is deadly. >_>;;



This image is from your replay, with a hack of Lix that shows trigger areas during play (important missing feature). The miners produce a gap, and the walking lix survives the upwards slope. In this light, do you think that the trigger is too short vertically? Too narrow? Or both? Or fine after seeing this?

-- Simon

13
NeoLemmix Main / Re: Creating a level pack
« on: December 14, 2019, 06:28:20 pm »
Others will give more qualified answers.

In the meantime, examine other packs. Imitate their folder structure. Any nx... files are regular text files, copy and edit.

-- Simon

14
Contests / Re: The Level Solving Contest #7
« on: December 14, 2019, 07:11:54 am »
Busy before Christmas, but I'll still submit this year.

-- Simon

15
Lix Multiplayer Dates / Re: Lix Multiplayer: December Poll
« on: December 10, 2019, 08:16:38 pm »
Let's pin it on Sunday 29th then? I haven't voted for Sunday 29th, but am 90 % available nonetheless, making 29th the best day.

For the time, I suggest 18:00 UTC, our usual time. In a pinch, I'd be up all European day, 10:00 through 21:00 UTC.

-- Simon

Pages: [1] 2 3 ... 200