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

Pages: 1 2 [3] 4 5 ... 164
I tried but wasn't able to install the dependencies.

The mac was too old to install Homebrew. There's a fork called Tigerbrew that can run on older machines, but while I was able to install it, I was unable to get it to work.

I mentioned this in IRC, but I wonder if clang vs. gcc has anything to do with it: if you could compile the dependencies on Linux using clang instead of gcc, and then link against those instead of the system libraries, does that replicate the magic pink bug? My best guess is that, while we would expect the ALLEGRO_COLOR struct to be basically more or less equivalent to a float[4], clang may have for some reason decided that it's better to pad it to 64 bit boundaries as if it were doubles or something. That, or it's comparing a +/- 0 for some reason (but why/how?)

One advantage of Spawn Interval is that the direct correlation of the values to the result makes quick estimation of the amount to change it easy. If I want to double the release rate, that's halving the time between spawns, thus I want to cut the spawn interval in half. When you think about it that way, you can take a lot of the trial and error out of reaching the number you're looking for. And if you really want to do frame perfect SI/RR twiddling... well, it's not exactly hard to do that with RR either, as you can just figure out, "Yep, that's one frame off, gotta go up/down one... two frames off, so adjust by two..." because of the way modern NL RRs map to spawn intervals (and in the traditional scale, it just becomes an adjustment of 2, 4, 6... instead of 1, 2, 3...). So blocking spawn interval doesn't actually discourage these frame perfect RR/SI shenanigans at all and in fact makes quick estimations (the kind of RR/SI adjustments you might actually want to encourage) harder:

What is double RR 50? I don't know. It might be 75. I think? Could be wrong. IIRC the formula for NL SI to RR is 103 - SI = RR, and thus SI = 103 - RR so 103 - 50 = 53. 52 / 2 = 26 SI. 103 - 26 SI = 77 RR. So we got close, but... not quite (in practice it should be close enough in most cases). It looks like there's a bit of a pattern there, although I haven't proven it holds true for arbitrary values, where we want to increase the RR by half the remaining distance to 99 to double the release rate, but that's a bit harder to mentally calculate than simply dividing a number by 2. Quick, make spawns twice as fast with SI 28: that's 14, easy. Make spawns twice as fast with RR 75!... uh... that's gonna be, like 80 something I think? (it's 89) (these calculations assume the current NL scale, though I suspect they'd still work for the traditional scale, albeit with the SI equivalents being different, but I didn't actually check for the traditional scale).

And, of course, as mentioned, the NL RR scale almost completely different from the original game RR scale, matching only at RR 99.

Since SL doesn't seem too concerned about existing NL content breakage, there may be an argument for reverting to the traditional RR scale.
But: doing that would cut off a lot of the available range, and then you may end up with demand for a 3rd option to use the current NL RR scale (which would need to range from 50 to 99 instead of 1 to 99 because the traditional scale can't represent these values... unless you want negative release rates to be a thing).
Interestingly, reverting to the classic RR scale would actually fix a minor cosmetic issue in the SI display option, which is that SI >= 100 looks like garbage, but it usually isn't a problem because seriously who uses SI >= 100, that's like 6 seconds at the rate of physics updates. That is, like, EXCESSIVELY slow, and if I remember correctly, these SIs were enabled not because there was actually demand for them, but because they wanted to remove the redundant values in the traditional scale so that changing the RR value would always change SI, so SI from 53 to 102 were created as a result of the scale suddenly having space for 50 extra values. But I'm not aware of any serious complaints that traditional RR 1 was too fast.

Although annoyingly, if you for some reason want a stacker to let no lemmings past it, you need 54 SI which is *exactly* one SI out of the traditional range.

I see no compelling reason not to offer SI as an option even in classic mode (particularly if you don't revert to the traditional RR scale as neither current option is really classic...)

General Discussion / Re: Simon blogs
« on: March 08, 2023, 07:50:43 PM »
I think any of No, Cancel, or Delete work fine in this case.

The "Delete" option is already likely as clear as it possibly can be, and conveniently, that's the important one. From context, it's easy enough to deduce that "No" means "Don't Delete" (although I suppose "Don't Delete" is another wording you could consider; a bit lengthier, but abundantly clear), and I don't think anyone's going to say "Hmmm, I definitely don't want to delete this level, but I'm a little unsure of what "No" means here, so I'm going to push the button that says "Delete". That said, thinking about it, "No" is probably the least good option here (out of what has been presented), but least good != bad.

If a climber or a slider is facing left and passes through a permanent skill remover, they will be embedded in the wall.

(For clarity, since Sliders turn: the slider would have been traveling right before transitioning to slider: that is, this always occurs when the skill is interacting with a right-facing wall, thus lemmings interacting with the wall are facing left).

The object works as expected when lemmings are facing to the right.

Simon correctly deduced that I didn't vote in this poll, and I can see from the timestamps exactly how long it was open. I can never remember if the forum software gets my local timezone right, though, so I can't be certain what I was doing during that time, but I think we can all agree that it's a little silly to not get your voice heard because you were busy with something else when the poll happened -- it's not like I knew it was coming ahead of time to be able to make time for it!

Simon has already touched on making sure you understand how you're interpreting "no" votes. He correctly notes that "You ask X if X wants Y, the answer is no, then you draw the conclusion that X wants Z to not have Y." You at least had a "don't care" option, but that doesn't necessarily mean people won't just vote for their preferred option. If we're debating if something should be an option or not, and I already prefer the default, then there's not a strong incentive to keep that option alive because I get what I want regardless. Sometimes it's worth fighting against the option, if you can make a case why the option is a problem (e.g. the old debates on having direct drop as an option for the user or developer, where the inconsistent engine behavior can lead to problems with level design), but I don't think this is one of those times, as SI vs. RR is purely cosmetic.

Generally, I'd say 24 hours is a minimum time you should leave a poll open, and ideally probably a week. There forums don't generally move very quickly, so it's quite realistic to expect many people may only check once a day; maybe a few times a week; or even once a week! Only call it early if it's extremely one-sided, and err on the side of caution (if in doubt, don't close early). You may have thought this poll was one-sided, but it wasn't open very long, and there were only 3 votes. If a high ratio regardless of the number of the votes is the sole criteria for deciding when to call a poll, then you may as well just close every poll after the first vote, because 100% of people who voted picked whichever option the first voter picked.

I could probably make a case that you closed the vote early because it showed the result that you wanted, and I'm not sure a reputation for biasing feature votes in your favor is something you want if you want your development journey to be relatively drama free.

Incidentally, I believe I asked you a while back what your design philosophy for SuperLemmix was, when I was suggesting you should really decide who you're targeting this to instead of trying to make everyone happy, and you said you wanted to try to make everyone happy.

Now, making everyone happy is pretty much impossible (see: timed bombers), but you're now actively failing what's pretty much a freebie test: you say you want to try to make everyone as happy as possible, and then you go cull some random harmless cosmetic option nobody complained about that wasn't causing anyone any problems because you don't like using it.

Another NeoLemmix zoom quirk, but this one might actually be intended: the panel will be located as close to the center of the screen as it will fit when the level's vertical size fits in its entirety, until you zoom in enough to force the panel all the way to the bottom. Thus, zooming in and out can cause the panel to move around.

Lix leaves the panel in place and anchors the bottom of the level to the panel. Personally, I would have expected a similar behavior as well. Still, it's probably worth asking around to see what behavior people expect.

SuperLemmix / Re: [SUG] Improvements to Skill Panel
« on: March 03, 2023, 05:27:32 AM »
For what it's worth, I think there's a strong argument for 16:9 as the standard aspect ratio, *but* I don't think it makes sense to force 16:9 as long as the panel physically fits at x1 zoom for the currently selected resolution (as in high-res vs. low-res graphics). I don't think you're implying that you would do that, but I wanted to state it explicitly.

Because the 160 pixel level height is so common, I think it's a good reference point for the level size. It's kind of arbitrary, but I figure there's enough existing content that there's a strong argument for keeping the tradition unless we can really clean up the layout by making the default something else (I feel like it looks nice when the default height fits exactly, personally).

For what it's worth, when NL redefined Release Rate in order to remove the duplicated values in the original, I switched my config to Spawn Interval because I figured if I was going to have to relearn the values, I may as well use Spawn Interval because the definition is very unambiguous about what you get when you use it: the spawn interval is the number of frames between spawns, whereas release rate is an entirely arbitrary scale.

SuperLemmix / Re: [SUG] Improvements to Skill Panel
« on: March 02, 2023, 07:37:21 PM »
I thought of a possible problem with my number crunching that may affect you that I didn't think of: because I prefer the original pixel art graphics, I completely forgot about high-res mode, which could affect what zoom levels look good. (I can probably still make that many buttons work, but I might have to redo the overall sizes if e.g. x3 or x5 zoom levels look bad when using that mode: if you use high-res mode, it would be helpful if you could give an opinion on how those zoom levels look -- assuming high res mode doesn't just not allow those levels).

SuperLemmix / Re: [SUG] Improvements to Skill Panel
« on: March 02, 2023, 07:42:48 AM »
For what it's worth: I use the minimap sometimes, but thanks to the fact that Lix doesn't have one, I know that I'm really not at all attached to it - if it were hypothetically completely removed, it wouldn't take me long to adapt to its removal. That said, it may be more useful to classic mode players who can't just rewind when they miss something.

That said, it should be noted that many people use the minimap for quick scrolling, so it's important that you have a good alternative to it if you ditch the minimap. One possible alternative method that works in Lix is zooming (you zoom out, point at the new spot, then zoom in, though of course this wouldn't work very well without a scroll wheel, but those have been standard on mice for quite some time and I doubt there's many people trying to play the game on a laptop trackpad). This does not work well in NeoLemmix (as Simon has pointed out, not many people have complained about this, and it seems quite likely that a reason for that is just that you can use the minimap instead, and the minimap predates the zoom function).

Many levels these days break the minimap anyway; it doesn't function well on levels that are too tall: a minimap that can't fit the whole play area is unable to fulfill its role in helping to see what's happening offscreen.

SuperLemmix / Re: [SUG] Improvements to Skill Panel
« on: March 02, 2023, 07:29:33 AM »
In case it is helpful: The Lix default for windowed mode is 1280 x 720. This size seems pretty reasonable for a windowed mode; would recommend trying to make the panel work at this size if at all possible.

Lix doesn't have a minimap though, which probably helps a lot to make everything fit.

I agree you probably don't want to deviate much from the standard aspect ratio if at all possible. Ideally, windowed mode is just like fullscreen mode, but smaller.

I don't understand how everybody else apparently doesn't care and happily plays on. Either everybody else is so thick not to notice any problem, or, more likely, subconciously avoids the nasty zooming even for precision work and just crawls into the screen really close.

Honestly that could be it. I rarely use the zoom function, but weirdly, in Lix, I *will* use the zoom function way more often. Although in fairness Lix levels have a wider variety of starting zooms which could just make it feel like a more natural part of the engine. But it's also completely undeniable that the zoom function in Lix is much smoother than its NeoLemmix counterpart, and generally works exactly as I would expect for the most part until you zoom out too much relative to the size of the level (and idk, maybe that's the least bad solution at that point).

Lemmings Main / Re: Most annoying Lemmings level to you (any game)?
« on: February 25, 2023, 04:45:19 AM »
We All Fall Down.

The solution is of course trivial, having been designed for the original game as an extreme example of a level where doing the solution is where the difficulty comes from rather than figuring it out. But from that regard, really only the Mayhem and maybe the Taxing versions are "interesting" in the sense that they may require a slightly different solution just to be reasonably completable, although NL framestepping tools show that the level DOES actually have enough space to do the trivial solution, if you can somehow pull it off without those player assists. And ultimately the thing that you have to do to be able to pass it isn't very interesting; it's just finicky because it's easy to have to start over because of a single very slightly mistimed input.

SuperLemmix / Re: [SuperLemmix] Introduce Classic Mode
« on: February 24, 2023, 11:48:25 PM »
*I've never fully learned what the various points on the splat ruler are, but I know they have something to do with different fall heights for different states. This is way too much for a player to have to bother about; if your level requires use of it, it's probably not a very good level.

I think it has something to do with some very specific weird considerations with splat height from different transition states, e.g. hatch or climbers hitting their heads or something stupid like that. If you're breaking existing content anyway best to find someone who knows exactly what those are and then fix them so the splat ruler can be nice and intuitive like the Lix one.

SuperLemmix / Re: [DISC] SuperLemmix Discussion Topic
« on: February 21, 2023, 09:45:13 PM »
Some thoughts:

If you're going to do this, it's quite clear that you don't really intend on following the existing NeoLemmix philosophy in regards to the player assist mechanics, and I'd have to question if it makes sense to appease both crowds with this engine. Perhaps fully embrace this engine's difference in philosophy and then design a cohesive experience around that. If we still want to maintain the existing philosophy, there's no reason we can't make divergent forks.

As part of this, rather than allowing levels to disable player assist features, I think it would be better for you to decide which player assist features this engine should keep. As a general rule, I'd suggest definitely keeping the player assist features that multiplayer Lix allows you to use:
 - Directional Select. It only breaks one official level, and that one level has a trivial solution and is at worst a 1 in 8 chance to solve correctly if you don't even try to get the timing right. It prevents you from having to redo a level simply because, for example, you had to pick a lemming out of a crowd and you got unlucky (in practice, there's no RNG going on, but the way small differences can affect the exact alignment of lemmings may as well make it RNG). Additionally, a few of the official ports support it.
 - Splat Ruler. Not even remotely game breaking even on levels with trivial solutions that are just finicky to pull off.

In addition, I recommend keeping Clear Physics Mode just because let's be honest hidden objects suck and it doesn't actually make fair levels easier.

The rest I'll refrain from commenting on for the time being. Though I do hope you at least keep pausing with a hotkey even if you don't keep assign while paused. There's precedent, lots of the official ports support it.

Why disable auto screen start? That's not a player assist feature, that's a designer assist feature. You leave auto screen start on and it chooses a sensible starting position for you, and then you override it in the editor if you don't like what it chose.

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