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
OK, I'll give it a try. Can't promise anything, because I currently have no idea what an enum is, let alone how it works or how to properly implement it. With that said, lack of prior knowledge hasn't exactly stopped me so far ;P

The syntax will of course vary by language, but I think an example will be the easiest way to show it:

Note that this example isn't Delphi, as it's not a language I've worked with. This is more about the concept of enums in general, not how to write them in your language of choice.
Code: [Select]
enum Colors

Basically we've just created a new type* that can only hold these values**. Internally, they're probably just ints where Red = 0, Orange = 1... Purple = 5, but code that wants a Color doesn't need to care about that. When saving/loading from a file, we can convert them to/from strings as needed; some languages offer features to do this automatically, but if not, well, if we had to do some if/else to read/write anyway without the enums, we can do it with enums too. Many languages allow you to explicitly choose an underlying type and assign your own values, but there will usually be sensible defaults.

*Well, symbolically anyway. Languages vary in whether their type system considers enums to be different from their underlying types.

**Among languages that consider it to be a separate type, they also vary in whether or not you can force it to convert a value from the underlying type to the enum type even if that value isn't part of the enum, but fortunately in many (most?) languages it's difficult to do this accidentally.


Well, there's also the somewhat more complex Rust enums which basically merge unions and enums into one feature, but let's not worry about those.

I understand your desire for the singular option, but there are benefits to keeping them separate (and, identified by strings rather than numbers). My instinct on this one is, let's keep it as it is at least for now.

I agree with Simon here regarding the use of an enum. There *should* always be one and exactly one of the options active, but an enum will consistently enforce it across the entire codebase. Even if everything's correct now, this has maintenance benefits long-term. It shows that it's intended that exactly one of the options is true, and you won't have to worry about any bad behavior as a result of attempting to run multiple options at once (sure, maybe setting them all to true doesn't misbehave for now... until some other change happens and it no longer gets handled gracefully but nobody checked).

You can still identify them with strings in the options file, and the enum values have names so it's not like you need to remember that "OptionA" is 0, "OptionB" is 1... keeping track of that is the compiler's responsibility.

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.

Pages: [1] 2 3 ... 164