1
Bugs & Suggestions / Re: [BUG][PLAYER] Lemmings sometimes survive the fall onto the splat-pad
« on: July 26, 2024, 11:14:27 AM »
The splat pad is the bug. It's also a feature. 
-- Simon
-- Simon
- July 27, 2024, 04:38:19 AM
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.
2
NeoLemmix Main / Re: Replay Insert Mode ("blue R") silently overwrites: Decision?
« on: July 26, 2024, 12:25:03 AM »"If in replay insert mode, and a skill assignment is attempted that would result in overwriting an assignment to a different lemming, prevent that assignment.
Sounds good!
Quote
Retain existing behavior in the case of assignments to the same lemming,
The existing behavior is: Silently overwrite the next-frame-same-lemming assignment. Yes, keep this. I would be surprised if somebody wants to keep the old assignment here.
In addition, I recommend to remove all future assignments to this same lemming. They'll all be out of sync. They'll even be of sync when one of the two assignments (the overwriting one or the overwritten one) was a permanent ability. The rare exception that doesn't desync is overwriting a permanent ability with a different permanent ability, and this sounds too rare to cater.
This will then be closest to Lix, and I like it like this in Lix, but I may well be biased. Prod more people for opinions.
Quote
as well as when not in insert mode."
The existing behavior is: Cut all future, then append the assignment. Yes, that remains the expected behavior in normal mode, i.e., the mode that isn't insert mode.
Quote
Should a single physics update still be performed when the assignment is prevented for this reason (as would happen if it were successful)?
Interesting. I never had to solve this before, but NL needs a design for this.
First hunch without sleeping over it: Don't advance. On successful assignments, NL advances once. Now, NL refused the assignment, and the easiest feedback is to refuse to advance, too. The feedback won't indicate what exactly is wrong, but you be the judge on how much UI work you want to invest. More is better but will go against your grain.
I'll sleep over it.
Quote
(I should probably double check what happens with an attempt to make an invalid assignment (eg. assigning a builder to a blocker), and keep consistency with that.)
Yes, look at what you do on disallowed assignment attempts, and make the two consistent. First hunch without sleeping: Neither should advance.
-- Simon
3
NeoLemmix Main / Re: Replay Insert Mode ("blue R") silently overwrites: Decision?
« on: July 25, 2024, 10:29:27 PM »
How is hassle added in this case? Do you have a workflow that relies on the silent overwriting?
I imagine that nobody, when he enters replay insert mode, ever wants to implicitly overwrite to some different far-away lemming. The mere possibility of this accident feels nasty and murky, and was the reason for making the first topic. Your answer makes me now believe that you want the implicit overwrite for some workflow.
Anyway, to answer your question directly: For me, cutting the assignment some other way is vastly preferable over the silent overwrite to different lemmings. I don't mind explicitly cutting assignments in a different way.
-- Simon
I imagine that nobody, when he enters replay insert mode, ever wants to implicitly overwrite to some different far-away lemming. The mere possibility of this accident feels nasty and murky, and was the reason for making the first topic. Your answer makes me now believe that you want the implicit overwrite for some workflow.
Anyway, to answer your question directly: For me, cutting the assignment some other way is vastly preferable over the silent overwrite to different lemmings. I don't mind explicitly cutting assignments in a different way.
-- Simon
4
NeoLemmix Main / Replay Insert Mode ("blue R") silently overwrites: Decision?
« on: July 25, 2024, 10:13:01 PM »
Hi,
Replay Insert Mode ("blue R") silently overwrites
namida, you closed the original topic, but you've never declared this fixed nor wontfix.
You consider this data loss. I agree.
You wrote that don't want elaborate fixes or physics changes; fine with me. WillLem offered help, you haven't replied; also fine with me, I assume you'll find something reasonable yourself.
Considering that you care about the data loss, you should at least chose one of the un-elaborate resolutions:
Replay Insert Mode ("blue R") silently overwrites
namida, you closed the original topic, but you've never declared this fixed nor wontfix.
You consider this data loss. I agree.
You wrote that don't want elaborate fixes or physics changes; fine with me. WillLem offered help, you haven't replied; also fine with me, I assume you'll find something reasonable yourself.
Considering that you care about the data loss, you should at least chose one of the un-elaborate resolutions:
- Refuse all same-frame assignments.
- Refuse only to different lemming. Allow overwriting same lemming.
- Allow noisy overwriting, i.e., tell the player that he lost his old data.
- Allow silent overwriting and let people run into unnoticed data loss.
5
Lix Multiplayer Dates / Re: Lix Multiplayer Session - Sunday 18th August 5pm UTC
« on: July 25, 2024, 11:08:51 AM »
Sunday, August 18 is good, I'll play!
-- Simon
-- Simon
6
Lix Main / Re: Lix 0.10.25 released
« on: July 24, 2024, 11:44:31 PM »
Lix 0.10.25 released.
Download for Windows 64-bit -- recommended
Download for Windows 32-bit -- fallback for ancient machines
Download for Linux 64-bit
Source code
Changelog
Issue tracker
-- Simon
Download for Windows 64-bit -- recommended Download for Windows 32-bit -- fallback for ancient machines Download for Linux 64-bit Source code Changelog Issue trackerHow to update (click to show/hide)
- Refactor the collision code between lix and goals a.k.a. exits. This speeds up rewinding and mass replay verification by at least 13 %.
- Refactor the world into a mutable and an immutable half to make savestates smaller and speed up rewinding. This brings only a small improvement.
- Add Rainbow Day, a 2-player and 4-player map by Miri.
-- Simon
7
Contests / Re: [SUG] Update contest format to include/encourage more players/designers
« on: July 24, 2024, 06:55:22 PM »
WillLem, what exactly do you want to see instead?
You count the number of designers who have shown (= placed 1st, 2nd, or 3rd) exactly once in the past n contests, and you value a high count for this. Let's assume Nessy did 50 % worse than he really did (2 showings), i.e., assume he showed only once. This will improve your metric by 33 % or by 66 %, depending on who takes the now-open slot. Is that desirable?
I don't particularly mind switching from levels to desigers for top 3, but it won't fix your problem either. Your proposal brings a change only when you see 1 or 2 designers sharing top 3 levels. Your example is that someone at random will get 3rd under your proposal. But the much more likely outcome is that one of the frequent showers gets promoted from 4th to 3rd.
3 may be small, but more than 6 or 7 would be odd, too, when we have prolific core contributors.
Certainly, I don't expect 51 different people showing exactly once. I would expect that if we had 1,000,000 designers participating in those 17 contests. I'm more surprised that Icho and Armani tie exactly than that there are exactly 3 exactly-one-point scorers.
If we ignore strength (= a designer's ability to create levels that show in the top 3), I expect the number of showings per designer to follow a Poisson distribution: Many people score low, some people get medium scores, and a few people get high scores. Your data is roughly shaped like one: Many people have no hits (and you aren't listing them), then you have 7 with one or two hits, then you have 2 people with more hits but not the maximum, and 2 more with the maximum.
I'm not sure if the Poisson distribution is really the appropriate model after we begin looking at designers' strengths. Poisson describes independent events scattered across a-priori equal targets.
-- Simon
You count the number of designers who have shown (= placed 1st, 2nd, or 3rd) exactly once in the past n contests, and you value a high count for this. Let's assume Nessy did 50 % worse than he really did (2 showings), i.e., assume he showed only once. This will improve your metric by 33 % or by 66 %, depending on who takes the now-open slot. Is that desirable?
I don't particularly mind switching from levels to desigers for top 3, but it won't fix your problem either. Your proposal brings a change only when you see 1 or 2 designers sharing top 3 levels. Your example is that someone at random will get 3rd under your proposal. But the much more likely outcome is that one of the frequent showers gets promoted from 4th to 3rd.
Quote
There are only 3 unique designers out of a possible 51 (top 3 multiplied by 17 contests)
3 may be small, but more than 6 or 7 would be odd, too, when we have prolific core contributors.
Certainly, I don't expect 51 different people showing exactly once. I would expect that if we had 1,000,000 designers participating in those 17 contests. I'm more surprised that Icho and Armani tie exactly than that there are exactly 3 exactly-one-point scorers.
If we ignore strength (= a designer's ability to create levels that show in the top 3), I expect the number of showings per designer to follow a Poisson distribution: Many people score low, some people get medium scores, and a few people get high scores. Your data is roughly shaped like one: Many people have no hits (and you aren't listing them), then you have 7 with one or two hits, then you have 2 people with more hits but not the maximum, and 2 more with the maximum.
I'm not sure if the Poisson distribution is really the appropriate model after we begin looking at designers' strengths. Poisson describes independent events scattered across a-priori equal targets.
-- Simon
8
Lix Levels / Re: Miris Multiplayer levels
« on: July 18, 2024, 12:12:20 AM »
Thanks! Happy to hear that you and your brothers like the shorter building section.
The 4-player version will be asymmetric, but that doesn't mean that it's imbalanced. On first sight, I can't tell if the top exit or bottom exit has an advantage. You've got a reasonable chance that it's pretty balanced!
If you and Miri agree, I'll include both maps (2-player and 4-player Rainbow Day) into the next Lix release. If it turns out imbalanced, we can always fix it later.
-- Simon
The 4-player version will be asymmetric, but that doesn't mean that it's imbalanced. On first sight, I can't tell if the top exit or bottom exit has an advantage. You've got a reasonable chance that it's pretty balanced!
If you and Miri agree, I'll include both maps (2-player and 4-player Rainbow Day) into the next Lix release. If it turns out imbalanced, we can always fix it later.
-- Simon
9
Lix Levels / Re: Blitzs Multiplayer Levels
« on: July 18, 2024, 12:07:17 AM »
Now it's like Selective Rescue, except that it's imbalanced and longer.
You've removed the cage, which certainly had its problems (walls too high, nasty squeeze at the top), but it was the unique feature of your level.
What's the fundamental idea of your level? Why should we play it instead of, e.g., Selective Rescue, or Rescue Ranger Trolls? Is it the cage where you free at least one other team whenever you free yours? Example: For 5 players, you might put 5 cages, one for players A and B, one for players B and C, one for players C and D, one for players D and E, and the last one for players E and A. That would be something new that sets your map apart. And you can make such a map completely balanced, by placing the exits accordingly.
But it can also be something else, anything you like. You get to decide! Find an idea and let it be your inner light during map design.
No worries if you struggle with English sometimes. Keep it up! Lemmings Forums (or any English online community about your hobbies) is an excellent way to improve English over what one learns in school. It's how I've been improving my English for 20 years: Relentless reading about games on the internet, and writing posts in English web forums.
-- Simon
You've removed the cage, which certainly had its problems (walls too high, nasty squeeze at the top), but it was the unique feature of your level.
What's the fundamental idea of your level? Why should we play it instead of, e.g., Selective Rescue, or Rescue Ranger Trolls? Is it the cage where you free at least one other team whenever you free yours? Example: For 5 players, you might put 5 cages, one for players A and B, one for players B and C, one for players C and D, one for players D and E, and the last one for players E and A. That would be something new that sets your map apart. And you can make such a map completely balanced, by placing the exits accordingly.
But it can also be something else, anything you like. You get to decide! Find an idea and let it be your inner light during map design.
No worries if you struggle with English sometimes. Keep it up! Lemmings Forums (or any English online community about your hobbies) is an excellent way to improve English over what one learns in school. It's how I've been improving my English for 20 years: Relentless reading about games on the internet, and writing posts in English web forums.
-- Simon
10
Lix Levels / Re: Miris Multiplayer levels
« on: July 13, 2024, 08:19:51 PM »I had given the map more Builders
Your most recently attached version (Miri Multiplayer Level more builders.zip) still has 20 builders.
I can increase the builders to 50 myself. Although: With strong players, you'll always have saboteurs near your exit, and sabotage by removing terrain is easier than adding terrain. If you want to be really safe, let's increase the builders to 80.
I still warmly recommend: Lower the exits! Try it with the exits in the lower half of the level. I've attached a version of Rainbow Day with what I have in mind. This will avoid the dull building. I'm sure other players will like the map better with this shorter building section. This still has a building section where strong players will go all-out to sabotage.
What do you think? I believe others will like it better with the shorter building section.
-- Simon
11
Lix Levels / Re: Miris Multiplayer levels
« on: July 12, 2024, 11:46:57 PM »
Hi!
To translate to German, copypaste the post into: deepl.com
Rainbow Day looks really promising, with lots of fighting in the outside columns after crossing the middle. Thanks!
Why did you put the exit so high, with a steel wall in front? Do you expect people to climb up? Or do you expect people to build up? Building will be boring, and it's near-impossible because you give only 20 builders. Or do you want to make it a race map where you win if you climb one single lix? In this case, cut the overtime from 1:00 to zero (0:00).
Have you played Rainbow Day yourself? How do you usually win: By climbing or by building?
Try it after moving the exit down, e.g., into the lowest one-fourth of the height of the level. I'd keep the overtime at 1:00, but give 50 builders instead of 20. Do you like it better now? If you don't like it, you can always go back to the version you've attached to your first post.
I'm happy to merge Rainbow Day into the main Lix download after you've decided if the exit should be lower or not.
-- Simon
To translate to German, copypaste the post into: deepl.com
Rainbow Day looks really promising, with lots of fighting in the outside columns after crossing the middle. Thanks!
Why did you put the exit so high, with a steel wall in front? Do you expect people to climb up? Or do you expect people to build up? Building will be boring, and it's near-impossible because you give only 20 builders. Or do you want to make it a race map where you win if you climb one single lix? In this case, cut the overtime from 1:00 to zero (0:00).
Have you played Rainbow Day yourself? How do you usually win: By climbing or by building?
Try it after moving the exit down, e.g., into the lowest one-fourth of the height of the level. I'd keep the overtime at 1:00, but give 50 builders instead of 20. Do you like it better now? If you don't like it, you can always go back to the version you've attached to your first post.
I'm happy to merge Rainbow Day into the main Lix download after you've decided if the exit should be lower or not.
-- Simon
12
SuperLemmix / Re: [FEAT] Rewind button / hotkey
« on: July 10, 2024, 06:54:32 PM »Quote
The question remains, though - why are we able to perform repeated backskips by pressing and holding a key, without any of the aforementioned issues? [When holding the single-tick rewind key, ] It responds smooth as butter. Why can't Rewind mode also do this?
Your observation in your older message suggests: It's well possible that there are still other problems in the rewind mode that the single-tick rewind doesn't have. It's good to investigate this even before the other concerns.
Assuming your observations still apply to your recent versions, I expect the biggest gains from:
- (biggest gain) Find the conceptual difference between the one-shot n-tick rewind and rewind mode. Without looking at your codebase, I imagine that it's best for rewind mode to be implemented in terms of the (backend of the) one-shot rewind-n-ticks technology.
- (also big) Savestate more often.
- Improve efficiency of a single physics update. Its well possible that there is treasure to be found here, but it may well be deeply buried and expensive to lift.
- Avoid storing the land twice if two successive savestates have identical land. This may need a conceptual redesign of the savestate collection. I don't do this at all.
- Improve the size of savestates.
- Improve efficiency of saving/loading the world in other ways than #4 and #5.
Quote
My concern is that keeping more savestates in memory might cause other performance issues...?
This sounds like a classic time-vs-space tradeoff. It's hard to recommend anything but: Implement it one way, measure, then implement it the other way, measure again, and compare.
You can ballpark RAM usage in the OS's standard system monitoring. Should you crash with out-of-memory, you have a clear answer.
Right, forgetting savestates appropriately becomes an important part of saving more often.
-- Simon
13
SuperLemmix / Re: [FEAT] Rewind button / hotkey
« on: July 09, 2024, 10:02:17 PM »
There is also the possible optimization with the value-type lemmings. I'm explaining this only for completeness after reading your posted code. Avoid doing this.
I assume the lemming is a heap-allocated class object. The optimization goes as follows: Make the lemming a struct (record) without indirection inside, i.e., no references to other objects inside. This means that you can copy the raw memory (with the Delphi equivalent of C's memcpy) and get a perfectly fine deep copy. Next, you ensure that LemmingList stores the lemmings in contiguous memory (with the Delphi equivalent of C++'s std::vector or most languages' dynamic array, or brazenly allocate raw memory yourself). Then you can copy the raw memory of all lemmings in one go. To create a savestate, you need only one heap allocation for the new dynamic array instead of one allocation per lemming. And the CPU will also be much happier iterating over lemmings in an array than iterating over individually heap-allocated lemmings scattered across the RAM.
This brought me 2 % in 2017/2018. But the 2 % is really compared to my earlier code, not yours. In my earlier code, I had the job (current activity) of the lemming inside the lemming as another heap-allocated object, therefore I got rid of two allocations per lemming, not only one. (I still call virtual methods on the job subobject that's embedded in the lix. I changed only the allocation strategy, not the object-orientation of the physics.
)
Thus, likely it won't be 2 % for you, and it's not worth the trouble unless you know exactly what you're doing and how you can do it in Delphi. You need a reasonable understanding of what the language and standard library offer.
The same optimization is possible with gadgets, and I assume it brings even less there.
My money is still on savestating more frequently than every 10 seconds.
I edited my previous post: I got 3.5 % out of refactoring away from too many shared pointers and out of immutable gadgets, not out of making the world faster to savestate. I can only measure this properly during mass-replay verification from the command line, where I don't savestate at all. It's possible that there are gains bigger or smaller than 3.5 % in leaner world savestating, but I'm not sure if it's your best bet immediately. I still recommend savestating more frequently, to reduce the amount of forward calculation during rewinding.
-- Simon
I assume the lemming is a heap-allocated class object. The optimization goes as follows: Make the lemming a struct (record) without indirection inside, i.e., no references to other objects inside. This means that you can copy the raw memory (with the Delphi equivalent of C's memcpy) and get a perfectly fine deep copy. Next, you ensure that LemmingList stores the lemmings in contiguous memory (with the Delphi equivalent of C++'s std::vector or most languages' dynamic array, or brazenly allocate raw memory yourself). Then you can copy the raw memory of all lemmings in one go. To create a savestate, you need only one heap allocation for the new dynamic array instead of one allocation per lemming. And the CPU will also be much happier iterating over lemmings in an array than iterating over individually heap-allocated lemmings scattered across the RAM.
This brought me 2 % in 2017/2018. But the 2 % is really compared to my earlier code, not yours. In my earlier code, I had the job (current activity) of the lemming inside the lemming as another heap-allocated object, therefore I got rid of two allocations per lemming, not only one. (I still call virtual methods on the job subobject that's embedded in the lix. I changed only the allocation strategy, not the object-orientation of the physics.
)Thus, likely it won't be 2 % for you, and it's not worth the trouble unless you know exactly what you're doing and how you can do it in Delphi. You need a reasonable understanding of what the language and standard library offer.
The same optimization is possible with gadgets, and I assume it brings even less there.
My money is still on savestating more frequently than every 10 seconds.
I edited my previous post: I got 3.5 % out of refactoring away from too many shared pointers and out of immutable gadgets, not out of making the world faster to savestate. I can only measure this properly during mass-replay verification from the command line, where I don't savestate at all. It's possible that there are gains bigger or smaller than 3.5 % in leaner world savestating, but I'm not sure if it's your best bet immediately. I still recommend savestating more frequently, to reduce the amount of forward calculation during rewinding.
-- Simon
14
Site Discussion / Re: [BUG] Site timeouts when posting
« on: July 09, 2024, 06:01:45 AM »
I haven't ever seen this. General troubleshooting:
- What OS does the laptop run?
- What browser did you use?
- Did you log into the forums via the small login widget on the main site, or via the dedicated login page?
https://www.lemmingsforums.net/index.php?action=login - Did you pick the permanent login ("Always stay logged in")?
- "pretty much every time I post", does it also happen when you spend fewer than 5 minutes between opening the post-composing form and submitting the message?
- After you've received the error about session time-out, are you then still logged into the forums afterwards, or do you have to log in again?
- After you've received the error about session time-out, does the forum present you a blank post-composing form, or does it pre-fill the form with your previously typed text?
15
Lix Levels / Re: Blitzs Multiplayer Levels
« on: July 09, 2024, 12:56:10 AM »
Hi! I don't think Cage Rescue is ready for merging yet.
The biggest problem is the long and boring work in the cage. To release your crowd, you'll have to release all crowds with you. This encourages to let others do 100 % of the work in the big cage and save your builders.
There is also an imbalance with the exit positions because there are only two small holes to leave the cage. When your exit is under the middle of the steel cage, it's much harder to reach it. Maybe give everybody two exits, an easy one and a harder one? Or think of more ways to leave the cage. Or arrange the existing exits in other ways than a long row at the bottom. There are many possibilities to make the hard exits easier to reach.
When you only have a hard exit, it's extra bad on Cage Rescue because the map forces you to reach your exit it while you're releasing everybody else. If this is what the map should be about, make the cage shorter vertically, so we get to get to the interesting part of the match much sooner.
It's unnecessarily hard for the crowd to squeeze through the holes at the top. Beginners' builders will cancel near the top. Consider removing the entire ceiling of the cage.
Decorate the level! It needn't become art, but at least put a few more terrain pieces than only the plain steel rectangles.
-- Simon
The biggest problem is the long and boring work in the cage. To release your crowd, you'll have to release all crowds with you. This encourages to let others do 100 % of the work in the big cage and save your builders.
There is also an imbalance with the exit positions because there are only two small holes to leave the cage. When your exit is under the middle of the steel cage, it's much harder to reach it. Maybe give everybody two exits, an easy one and a harder one? Or think of more ways to leave the cage. Or arrange the existing exits in other ways than a long row at the bottom. There are many possibilities to make the hard exits easier to reach.
When you only have a hard exit, it's extra bad on Cage Rescue because the map forces you to reach your exit it while you're releasing everybody else. If this is what the map should be about, make the cage shorter vertically, so we get to get to the interesting part of the match much sooner.
It's unnecessarily hard for the crowd to squeeze through the holes at the top. Beginners' builders will cancel near the top. Consider removing the entire ceiling of the cage.
Decorate the level! It needn't become art, but at least put a few more terrain pieces than only the plain steel rectangles.
-- Simon