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 - geoo

Pages: 1 2 [3] 4 5 ... 104
31
Lix Main / Re: Replay Insert Mode for Lix (like NeoLemmix's "blue R")
« on: December 31, 2022, 10:19:25 AM »
I will say that cancelling assignments corresponding to a specific Lix is a weak heuristic, as while it *does* cover a case where desyncs are likely, many skills are capable of desyncing *other* Lix (i.e. basically anything that alters pathing) and those desyncs are a big part of why replay insert mode can be annoying at times.
Certainly doesn't cover all cases, but in practice might serve the purpose reasonably well, espcially if you alter somewhat recent assignments and not assignments at the beginning of the replay. Always depends on the use case, and should certainly be better than nothing.

In the future, the same considerations will also need to be applied to the replay tweaker, i.e. desyncs caused by adjusting the frame of an assignment.

Quote
E.g., assignments might cut all future assignments of lix from that same hatch. I still believe (*) is better, but cut-future-of-same-hatch sounds viable enough, too, that I can't easily argue against it.
For single-hatch levels, that's basically having no insert mode. Usually, as a single-hatch level progresses, some worker lix are separated and operate essentially independently (and independent of the crowd), and so there are good use cases for insert mode.

Quote
The biggest worry remains that I roll out (*) and everybody gets upset over losing assignment-cuts-global-future. That was a reasonable behavior after all and it annoyed mainly on multi-hatch maps.
For a prototype, having an option in the options menu to enable/disable sounds like a good start, it allows people to experiment while being able to disable it if they get fed up. At the same time, you don't have to worry about in-level UI yet.

32
Lix Main / Re: Replay Insert Mode for Lix (like NeoLemmix's "blue R")
« on: December 29, 2022, 11:04:27 PM »
Quote
Ill replya more in depth later. My initial reaction is I like NL's function; two modes: insert mode and non-mode and being able to switch it on or off during play. While insert mode is super useful it has very specific uses for myself anyway, im more often not using it so it would get annoying
Quote
I personally would not want this to be always-on. While I do make use of this mode at times in NL, the majority of the time I would have it turned off - it's essentially an "only when I specifically want it" feature for me. [...]
I think the question to ask here is: why would it be annoying if it was always on? It annoyed Simon when it was still assigning to the Lix whose task you just overwrote, but if the assignments to that Lix were cut, or if all desynched assignments were cut (as Dullstar proposed, something that had come to my mind as well), would there still be instances where it'd be annoying? I think it's hard to know without trying it for a while.
If in the majority of cases this is the behavior you desire, and in the few other cases there's an easy mechanism to cancel the replay, then this is probably good behavior.
Note that I do not see any use case where you actually want to keep the future assignments for the lix whose assignment you just overwrote, because they will be desynched anyway. The one exception is assigning permanent skills, however, you only need to assign them just before they actually take effect, and in that case a desyc of future assignments happens as well. Are there any use cases where you want to keep desynched assignments? If not, Dullstar's proposal is arguably even cleaner, and just cancelling the assignments of the lix you're overwriting is merely a heuristic that is easier to implement (and thus a sensible first step).

It seems cumbersome to me to have it something you turn on and off during play, especially if mentally you need to keep in mind whether it's on or off at a given time. (Tracking a state always takes mental capacity, and to me tracking whether the replay is still going or not is already complex enough, and I don't think I ever consciously look for the visual indicator to check for the state).
Having two different sequences of input actions corresponding to the two seems like it would be less confusing (because it's state-less), and the proposal (simply assign to insert, assign and click somewhere else to cancel) seems to be as simple as it gets and consistent with previous behavior for cancelling replays (and this behaviour will still be needed in the future, e.g. to cancel when backward frame stepping or loading from a savestate).

Also note that if you want to change an assignment to a lix/lemming to a later point in time, this behaviour is already required, as you have to click first to cancel the assignment.
This ties into the discussion in the other topic: https://www.lemmingsforums.net/index.php?topic=6120.0 In the context of option (1), the proposed behavior in this topic is simply a practical implementation of insert mode that is consistent with everything else. In the context of (2), whenever you go back to a previous point in time (rewind, load state, restart), future actions are cancelled, and the whole point of this topic is moot as remembering replays (and therefore insert mode) wouldn't exist.

Quote
I think if you want to default to on, it's *extremely* important to have an easy way to cancel the replay, and I'm not sure clicking the air is the best solution here, as it seems like a very easy misclick. I think a hotkey would be better: still possible to mispress, but I would suspect it to be less likely than accidentally clicking the air next to a Lix.
I disagree here. I really wouldn't like to use another hotkey for this, personally, as keyboard estate is really precious and I'm already out of keys within easy reach with all the other hotkeys. Clicking into air has been in place for ages, and I personally haven't had any issues with misclicking. (Admittedly, when you assign a skill it cancels as well currently, so the cursor position didn't matter and now it would, but I'm having a hard time seeing this a big issue. Given the many hotkeys already in place, I think fatfingering the one in question is more likely to me than misclicking, and that's from a user who's very clumsy with a mouse and prefers keyboard wherever possible.)

33
Lix Levels / Re: Ramond streams lemforum, 2022-12
« on: December 25, 2022, 09:14:02 PM »
Managed to skim through the recordings. A few notes:


Stairs bro: Interesting alternative solution which I'd argue is trickier than the intended one.
Merge Sort: Interesting to see you struggle, and somehow finding a solution without fully understanding why it works. There's a key observation about merging (which I thought was obvious, but seeing different people struggle I guess it's not) which, once realized, makes it very clear where and when to place the miners.
Downpour: Used to have timed bombers, so I set the requirement low to make the level not too annoying. Now with instant bombers, it's quite trivial so maybe the save requirement could be raised a bit.
Impetus, Prelude, Lix Cannon: Look like backroutes?

I agree with your assessment that Lovely and Quirky contain some levels which seem too complex for the rank, and maybe it'd have been sensible to make these ranks a bit easier than their are overall. For example, Lovely could contain a few more levels with small skillsets that reinforce the behaviour of certain skills (like Beneath the Lab reinforces that builders turn while platformers do not).
Time to change the road: Used to have a time limit, enforcing a specific idea. Now it's easier, so I think it could be moved down to Lovely. (Could also fix it enforce my initial idea, but in line with the assessment above I'd also support the simple downrank).
100 ways to die: Should this maybe go into Lovely as well?


34
Lix Levels / Re: Lemforum outtakes/replacements, 0.10.x
« on: December 23, 2022, 04:29:40 PM »
Pretty sure this is a backroute.
I also suspect that there's more backroute potential using the fling bombers, so it might be better to replace them with normal bombers.

35
Lix Levels / Re: Lemforum backroute fixes, Lix 0.10.x
« on: December 22, 2022, 09:04:41 PM »
Fix for All Aboard the Pain Train.

36
Lix Levels / Re: Ramond streams lemforum, 2022-12
« on: December 20, 2022, 08:54:14 PM »
Glad you asked :D Madeleine's World is a private romhack for Super Mario World which I created, and with it I sequenced the complete soundtrack myself using the SNES music engine. It's a mix of original compositions, songs from bands I've played with and other internationally known pop songs or video game tracks. If you're interested in any of the tracks, I could link you the originals or even the soundtrack itself.
I was wondering the same, that song stood out to me but I couldn't find any information. Thought maybe it was a Celeste mod or something. Would be happy to have the soundtrack as well :)

37
Lemmings Main / Re: "The Lemmings File Portal" question
« on: December 12, 2022, 09:39:30 AM »
The are replays for some Lemmix levels. Now where to find those levels is another question...

38
Contests / Re: Level Design Contest #WasteMyTime
« on: November 25, 2022, 10:58:30 AM »
This is a fun idea. Wish I had time to implement a level.

Long time ago we already discussed how to create levels that take a long time to solve (penultimate paragraph in this post: https://www.lemmingsforums.net/index.php?topic=1314.msg34071#msg34071)
This could directly be applied here: just have X lemmings on X platforms of different lengths (see post - some prime P times a fixed amount of pixels L) that need a certain time to synchronize, and require them to bash at the end of the platform to get out. If they are synchronized, they all cluster on the same spot, and can pass a squisher trap with only one lemming dying. Otherwise, some of them will be at least L apart, and if the trap is fast enough it is guaranteed to at least take 2.

But I feel like you could even make a level here that requires no skills and just solves itself, 200x200 might be enough to waste 8 minutes just slowly walking down a zigzag path.

39
Lix Main / Re: Add button to flip vertically to editor?
« on: November 12, 2022, 10:35:17 PM »
Interesting how inconsistent the designs of the two flipping buttons are. Not only do they use different terrain pieces to illustrate, but one also has both the original and the flipped sprite, while the other doesn't.

Regarding the larger terrain button, do I remember correctly that the zoom button is mostly for discoverability? Does anybody actually click it? Seems to be one that could be done away with, at the risk though that some users may not discover the existence of zooming. Another option to buy screen estate could be grouping hatches and exits into the same dialog (which then poses the question on how to display/sort them; not all hatches/exits are obviously hatches/exits.)

40
Lix Main / Re: Add button to flip vertically to editor?
« on: November 09, 2022, 08:39:18 PM »
I'm with Flopsy and Simon on this one: I personally won't use it (neither button nor hotkey, the latter as there's too many other important functionalities to be mapped), at the same time I agree that it technically belongs there from the UX perspective, even if it costs screen estate. Then again, I think it's a minor issue, so I hope Simon doesn't prioritize it over some other more exiciting stuff :8():

Quote
Ironically within the level text files there is the tile modifier 'f', which means: Tile is mirrored vertically. The flip horizontal button is implemented in the text files via combination of 'f' and 'r' ('r'=rotate 90 degrees clockwise), e.g. 'frr' for flipping horizontally a non-rotated tile.
I think this is historical, because the original Lemmings game allows you to flip vertically, but not horizontally. Lix supported this initially, and rotation was then added on top, if I'm not mistaken.

41
It's too early for me to tell for sure. I might be able to make both or none of the dates, I suspect Saturday is more likely to work than Sunday, as I might be travelling on Sunday, but again, can't say for sure.
So I suggest you pick based on everyone else's preferences, and (as usual) I'll join if I can make it. Would love to try to the new handicap with more players.

42
Loap / Re: Rendering issues - some help?
« on: October 02, 2022, 09:13:56 AM »
Quote
I've been thinking this over for a while and the only obvious downside I can see is that it will mark a lot of pairs of faces as having one that must come first, even when it actually doesn't matter. However, this would only result in a performance penalty, rather than a failure - it might be acceptable, would have to test (and possibly optimize) before I could say for sure.
Actually, if you mark dependencies where there are none, you add additional edges to your graph, and making it more likely to get cycles.

I think the many cyclic dependencies you see are exactly a result of this. There may be instances where you legitimately get cyclic dependencies, but these should be rare in practice (e.g. the lemming intersecting with the diagonal block).

I don't really have time to think through your outlined algorithm in detail, but you should have as few extraneous dependencies as possible.
Newell's algorithm (linked in my previous post, and the linked stack overflow post also has a link to the Wikipedia article) claims to take care of this, maybe worth having a look at.

43
Loap / Re: Rendering issues - some help?
« on: September 26, 2022, 06:11:29 AM »
Quote
Thinking of another possible approach (somewhat based on Simon's idea using planes) - let's suppose I can come up with a list of prerequisites (eg. face A must be rendered before face B, face B and C must both be rendered before face D) - what is generally the most efficient way to translate these requirements into an ordered list? Keeping in mind that two faces may be neutral with regards to each other, but a third face might need to be drawn inbetween them (eg: A and B have no order preference to each other, but A must be drawn before C while B must be drawn after C).

Quote
The next keyword to websearch from there is: Topological sort, or directly on wikipedia. (Starts to sounds like geoo or another computer scientist could have pointed us there much quicker. :D)

Yep, that's exactly what I suggested a couple of posts ago x_x

Anyway, if you do want to do face sorting properly, it seems to me if you're doing pairwise comparisons for intersection like Simon is suggesting, you can then piece it together into a linear order by building a graph (the nodes are the faces, the edges are when a face is partially obscured by another face), and then doing a topological sort. (Note that in practice you might encounter cycles in this graph, e.g. if you have 3 triangles where each one obscures but also is obscured by another one.)

But back to Z-buffering and the Z-fighting issues that you had when using that approach: Why don't you make the blocks a tiny bit smaller (not enough to be visible, but enough to avoid z-fighting due to rounding errors) than a full grid unit?

44
Lix Main / Re: Handicap in Multiplayer
« on: September 24, 2022, 07:39:50 AM »
Interesting, my intuition is that score divisor is going to be the single most applicable kind of handicap (unless you're playing all-or-nothing maps), while I feel that the blanket skill divisor is going to be un-fun and rather useless. The rationale is that you want to limit/cut the strong skills for the stronger player, while keeping the utility skills unaffected. The blanket skill divisor does the opposite: Your utility skills get cut in half (so the strong player runs out and gets frustrated), while the skills allowing to wreak havoc with in small amounts (e.g. digger, blocker) will remain available to some extent. So I don't think skill divisor is going to be all too useful unless you can set it for each skill individually.

Also curious to see you're trying to implement fractional scores. I would have thought in practice it'd be fair to just round up to the next integer (and call it a tie if the scores match). The "divisor" is a somewhat arbitrary number anyway, and changing it in small ways will affect your score by more than an integer, so it doesn't seem like precision is really needed (but happy to be proven wrong with some case scenario).

I'll try to make it to the fireside chat tomorrow night, curious to discuss, not sure I'll be able to make it though.


45
They need some polish before they can be released:

- Title
- Decision on how far to shift the exit from the start (unless you want to include all possible versions)
- Release rate that doesn't perfectly cluster the bunch
- Some mechanism to prevent plugging up other players' climber chutes
- Overtime

Pages: 1 2 [3] 4 5 ... 104