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 ... 164
Contests / Re: Level Design Contest #30
« on: March 24, 2024, 08:47:15 PM »

Tip for replicating L2's style: Lemmings 2's terrain is strictly grid-aligned; this is why L2_classic is not a direct port of orig_pillar: orig_pillar's tiles would not have been the right size for L2's grid, and many of them don't align nicely with any grid size, so they had to redesign them. If I'm not mistaken the smallest size piece you can place is 16x8.

Is disallowing Water in Rule 3 intentional, or is it an oversight (since the stated reasoning is "Anything that was not available in Lemmings 2 is not allowed")? Water is present in L2 and the Classic water tiles are not unused in L2: they appear in 9 of the 10 official Classic levels.

There are also several unused tiles and objects in the set, which I still chose to include when I put L2_Classic together (using a rip made by... I think it was Icho?), but it's probably worth clarifying if these tiles are allowed. To my knowledge they are:

Steel: steel_01, steel_02, steel_03, steel_06, steel_07 (basically, just the small 16x16 square and one variant of the tiny 16x8 rectangle is used).
Wood: wood_14 to wood_24 are unused.
Misc: gray_block, pillar_end_03, pillar_end_05, pillar_end_06
Objects: trap_01, trap_02 (plus NeoLemmix standard objects: owa_down, owa_left, owa_right, lemming, pickup, button, updraft, flag_blue, flag_green)

NeoLemmix Main / Re: Future of NeoLemmix development
« on: March 23, 2024, 11:38:53 PM »
Regarding forks, if namida was okay with it my suggestion would be to keep the NL name (perhaps with a prefix/suffix) until breaking changes are made. If it's just an enhanced version of NeoLemmix but the physics and file formats are the same, so content made for one will work perfectly in the other, then I think a new name would just introduce confusion; conversely, if it's merely compatible with NL content, but its content is not compatible with NL, then calling it NL would be confusing.

Contests / Re: Should we change the contest voting system?
« on: March 18, 2024, 03:58:30 AM »
I don't think the forum software supports it out of the box, if at all, but I wonder if there's a way we could implement ranked choice.

New Objects / Re: [DISC][PLAYER] Visual designs of new objects
« on: March 14, 2024, 08:29:51 PM »
I agree that the arrow version is better, as the animation is more of an enhancement to the visuals rather than outright required to figure out what you're looking at. I don't like to go *too* far with the picture puzzle mentality but it's much more convenient the fewer things I need to go send a lemming to test (particularly if just figuring out how to get a lemming over to the thing I want to test in the first place is part of the puzzle!) And when I'm inspecting the level I will generally have the game paused so I don't have distractions from things happening elsewhere.

Though I wonder if it might be a good idea to have an option to continue playing idle animations while the game is paused (triggered animations, such as those for triggered traps, would be a bad idea since it would make it less clear when the trap is active again). Maybe that's a dumb idea, idk. Just throwing it out there, really.

To clarify, by "larger resolutions" I'm considering this any resolution that's larger than the monitor's native resolution. We certainly wouldn't want to reject a resolution that we're not 100% certain shouldn't fit.

But I suppose the "larger than the monitor" part probably isn't the actual problem. Just hazarding a guess: could excessively large resolutions just use too much e.g. VRAM and then the application doesn't know what to do?

From looking at what's been posted here, I do have a possible guess as to why Forestidia got a different behavior than Silken: from other reports we know Silken prefers hardware fullscreen, so it's possible the behavior may be dependent on it.

Ruler Snap like in Lix is probably the best solution.

Rather than making the end multi-colored, I think a better solution (although it would require changes to the code) would be to make the colors change. It wouldn't be entirely new functionality at least, since that visual effect is used in clear physics mode, just not with the splat ruler.

General Discussion / Re: Simon blogs
« on: February 22, 2024, 02:56:17 AM »
One thing I really appreciate about your approach to Lix is that you will look at something that people find unintuitive, and say that the fact that it's unintuitive is a problem. There's definitely a lot of people who write off those sorts of concerns as "It's working as intended." [often implying: "It's not broken or badly designed; you're just stupid."]

Out of curiosity what is the applicable benefit to allowing larger resolutions? I assume something related to making the game display on multiple monitors at once? (I know there's a few games that support that but I've never looked into how exactly that works).

I'm assuming there's a reason that the solution isn't "Just don't let the user do that."

Lix Main / Solved: Lobby ready-up desync
« on: January 28, 2024, 07:26:12 PM »
Also posted on Github as on one hand it seems like the most appropriate place to report bugs, but I thought it would be useful to post here too as I imagine people will be more active here than on the Github issues page.

Observed during 1/27/2024 lemforum session on central server.

A player dropped and rejoined. The other players in the lobby remained visibly readied up, but when all players were shown as ready, the game did not start. Appears there was a desync at some point. My client version is 0.10.18, compiled from source (I know I wasn't the only one affected, but I'm not sure what version everyone's client was or exactly how many players were affected; I want to say one or two people may have still been on 0.10.17).

I tried to reproduce this with a locally hosted server; the observed behavior was that a player leaving and rejoining would unready all players in the lobby. I need to do some further testing e,g. if the client crashes somehow. I don't know what version of the server is running on the central one; I'd assume it's probably up-to-date but have no way to confirm. The locally hosted one I used to test should be 0.10.18.

Edit Simon: Solved in Lix 0.10.19 with a client-side bugfix. This 0.10.19 and newer can still play with older 0.10s: If the game starts at all, it starts for everybody at the same time.

Lix Main / Re: Hardware fullscreen not working
« on: January 28, 2024, 07:01:51 PM »
I wasn't able to reproduce at resolution 1920x1080, which matches my monitor.

I've been compiling Lix from source as it makes updates very easy (git pull then dub build -b=release), so I went ahead and checked what version of the DLLs I have on my system, which appear to be version 5.2.6. I don't remember exactly where I got them. Lix version is 0.10.18.

Lix doesn't appear to show the currently installed version of Allegro. It might be useful to insert that somewhere, maybe under where the Lix version is currently shown?

Lix Multiplayer Dates / Re: Multiplayer Lix players, we need to talk!
« on: December 06, 2023, 08:11:09 AM »
Since having enough slots for everyone isn't typically a problem, I usually don't commit ahead to joining and just kinda see how I'm feeling day of. I'd say the times aren't great, but they are doable but I'm not sure I can really suggest a better alternative, because the reality is we have players on multiple continents so times that are convenient for one continent often won't be convenient for other continents.

With regard to maps, I think maybe one possibility might be give weaker players a chance to feel out the maps, particularly the overall routes to the exit, before sending saboteurs to collect or destroy the honey pot, so to speak; keep the sabotaging mostly contained to stuff that's directly in the way or just between strong players when playing a new map.

Lix Main / Re: Unable to paste a name into Lix
« on: August 19, 2023, 09:58:20 PM »
This is because long-term users learned to tolerate the flaw. Tolerating is a nasty solution.

In fairness I imagine many long-time users never thought to try copy-pasting something in there. It's something that I would expect to work, but also something I probably wouldn't think to try until I have a reason I want to do it. Usually password fields are the most likely ones for me to paste into (as memorizing tons of unique secure passwords is basically impossible), but Lix doesn't have those. In most other situations it's easier to retype than to go grab the appropriate clipboard contents to be able to paste.

Putting a bit more thought into this and reading through the older replies:

I still agree that turning should in no way be part of the interaction; it just doesn't make sense why this would be a special case where deassigners climb.

Climbers and Sliders have a mechanically similar counterpart which isn't a permanent skill: the Shimmier. It wouldn't get cancelled by this object since it's not permanent, which is technically consistent, but it does make me wonder if perhaps it *should* cancel because the skills are so closely related in function. But then why stop at cancelling Shimmiers -- why not cancel *any* skill, *including* the removal of permanents? Or, on the other hand, there's Simon's earlier suggestion of having the skill remover only remove the skill but not cancel it: so a climber would *finish* climbing the wall, but it wouldn't be able to climb again unless another climber was assigned. But -- this would cause a unique situation in which the climbing/sliding/floating/gliding/whatever state is decoupled from the status of actually having the skill. On the other hand, it's at least a simple rule.

The problem with potential turning is that it's a complicated rule: Usually, the deassigner won't turn lemmings, but in certain cases (which you need to memorize), the desassigner will cause a turn. Non-turning is a simple rule, but there's one "oh, I didn't think it would work that way but I guess that makes sense" exception you have to memorize with the shimmier ("it should cancel a shimmier too, right?" seems like a reasonable misconception even if logically, it's not a permanent so it doesn't get cancelled). If you cancel shimmiers too, then that's a different actual exception that you have to memorize. Non-cancelling (the permanent skill will finish its activity but can't be used again) or all-cancelling (including non-permanents) seems like the simplest rule.

I can't remember if it was an option in the experimental or not, and I could see the UI for it being a problem, but assuming you could find a reasonable way (maybe if you hover your mouse over it?), there's also the option of allowing arbitrary combinations of cancelled skills, which I actually think would be more interesting for puzzles than a simple deeassigner that deassigns everything (whether it affects non-permanents or not): you could imagine a puzzle where you're given multi-athletes and you have to navigate them through a maze of deassigners that requires retaining at least a few of the skills to navigate, so you have to figure out which ones you can afford to pass through.

In most discussions "physics update" is probably the best choice if only because it's extremely clear. But looking at where "phyu" is used in the code I could see that making for some lengthy variable names.

As an internal name, while "phyu" is unusual, I don't think it's too bad. It has a cost as a bit of codebase specific terminology that has to be learned, but it's consistent -- it's not like you're going to get it mixed up with some other thing "phyu" could potentially refer to -- and it's used in enough locations throughout the code that it's pulling its weight fairly well: it's not like it's some obscure variable that you only see when you delve into the internals of some cursed function nobody-knows-what-it-does and everyone is scared to touch it and doesn't know what any of the 30 badly named local variables does. Rather, it's a term you learn once and then is constantly reinforced by the fact that it's used basically everywhere, and it's clear what the connection is between "physics update" and "phyu" once you learn what a "phyu" is. If you have a ton of these, your codebase will be super inaccessible to new eyes. But if you only have a few and a nice getting started guide that explains some of the terminology, I don't think that's too bad. Probably anyone who gets confused by "phyu" for more than about 5 minutes for any reason other than "where is this terminology introduced" isn't going to be learning much from reading the code no matter how good the names are.

The only real advantage of "tick" over "phyu", in my opinion, is that it's more "standard" but I'm also not quite convinced that it's standard enough (particularly considering other possible meanings of "tick") to say "yeah, this is definitely the word to use for physics updates." But "tick" is definitely a reasonable choice. That said, I'm not sure I'd use "tick" in user-facing discussions where you don't expect people to know the codebase, or that it's worth the effort to migrate from "phyu" to "tick" (if only to make sure that none of the documentation rots as a result).

I believe they were a replacement for Only-On-Terrain, a setting that was used in the DOS/Lemmix days which caused an object to be shown if and only if it is overlapping terrain (pixel-by-pixel). This setting could be applied to any object. But in practice, it was almost exclusively used for one-way-walls.

A few levels in the original game use it for decoration, but it's not many (and not in the DOS version). I can think of two off the top of my head, namely Fun 20 (We are now at LEMCON ONE) and Mayhem 7 (Poles Apart) (they use the same layout). I'd have to play through the Amiga version again to see if there's any others that use it, but this particular instance can be replicated using resizable water objects. In the DOS version, the setting does not render properly (specifically, the colors get messed up) when used on arbitrary objects, but it's hard to say if this is a bug or not -- the DOS version culls a lot of decorative terrain/objects anyway, and thus it's possible that they only considered one way wall objects when they designed the DOS implementation (perhaps they could make it perform better that way).
If I remember correctly, the Paint setting was a designation for decorative objects that are intended to be used with the Only-On-Terrain tag, with the intent being that those objects would become paint objects and then Only-On-Terrain would be culled. OWW in NL have had the behavior for a while out of the box with no need for the tag, and on other functional objects the Only-On-Terrain tag would probably be considered a bit of a troll to make use of it.

Pages: [1] 2 3 ... 164