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.

I've already stated my reasoning in more detail in Discord, but summarizing here:

While the NeoLemmix behavior may not neccesarily be what newcomers would expect, it only needs to be learned once. After that, it is completely unambiguous: there is no guesswork as to exactly what is and is not steel, and thus no nasty surprises once the player has learned the rules. Any other reasonable behavior means that every instance of overlapping terrain + steel must be assessed individually and/or that CPM must be used to ascertain the steel boundaries.

Thus, the existing NeoLemmix behavior is the best solution.

---

That said, I get the desire to be able to decorate steel. Simon's proposed solution is a good general solution, I think, though presumably two adjacent steel tiles should be treated as one for this purpose.

A simpler alternative might be to allow styles to mark some pieces as being primarily decorative, such as moss pieces in orig_dirt. These pieces could be overlaid on steel and wouldn't turn it into non-steel, while normal terrain pieces would. It would be less consistent, however... but presumably there wouldn't be particularly many pieces marked as such and it would be obvious something weird is going on if someone tries to abuse it (this assumes that standard styles get vetted to make sure the choices they make are reasonable, of course, but new styles aren't super frequent so I don't think that will be an issue).

On Windows specifically, the CLI is not super great. Useful for administrative tasks a lot, but in general it's a much bigger pain and a lot of the CLI tools target Linux (well, more accurately Unix). Even if Windows ports exist, you have to track them down yourself, while they probably just kind of end up on your Linux machine thanks to the package managers handling dependencies (plus a lot of them are typically bundled). GUIs are much more tightly integrated in Windows land (does Windows even allow terminal-only installations? I know there's a server edition, at least, but I'm pretty sure it has a GUI?), so solid CLI interfaces are less common. Of course, the plus side of this is that Windows GUIs seem to be more reliable.

For C++ specifically: Like Simon said, CMake is popular. There's an alternative called Premake that's easier to use, but also not nearly as well-supported. It's generally easier to set up from scratch, but if you're e.g. linking libraries it's less likely that the library will support it out of the box (but: if the library doesn't support either out of the box, it should be easier to make work). I haven't decided if I want to pick up the book Simon recommended for CMake, but I can confidently say I wouldn't recommend trying to learn it without a book. Pretty much every online resource I've found on CMake is either too basic (stops before your app would have reached the point where CMake is helpful) or too advanced (assumes too much existing CMake knowledge to be helpful for beginners).

For Windows/C++: Visual Studio seems more likely to be supported than Codeblocks. If you don't have a specific issue with Visual Studio being closed-source, that's the one I'd recommend learning.

I would like to make it abundantly clear that I'm not talking about conversions of NL -> SL content. For the purposes of this discussion I'm assuming that NL content is expected to break. Existing content, here, thus refers to existing SL content, whether it be levels that people have already made for SL, or NL content that has already been ported.

---

I feel like you kinda side-stepped my point a bit.

My main point is as follows: You should have an idea of which features are still subject to change and which ones are pretty much set. Currently, the impression that I've gotten is that EVERYTHING is on the table. If you wanted to make a SL level without worrying about if you're gonna need to make a ton of maintenance updates and even full level reworks down the road, which subset of features are safe?

It's not too important if you aren't sure exactly what specific changes you want to make; but you should know, for example, which skills/objects/mechanics/etc. are you considering making changes to?

Keep in mind that there were very few breaking changes in NL history *because* of the existing content attitude. There certainly were some, but they weren't something to be taken lightly. We did it on a few occasions when we decided the benefits outweighed the costs, that's true, but we also weren't constantly discussing a new set of breaking changes every week or so (except arguably the infamous culling frenzy, but they were also pretty grouped, like, if we're going to do breaking changes, let's do a bunch of them at once... and they weren't without controversy at the time).

Generally, we don't want to be constantly revisiting old levels to update them for breaking changes. It takes away time that we can use for other things, like making new levels, or literally anything other than updating levels that were broken for no reason. So when you do break levels, you should have a good reason for doing so.

MOD: Split from this topic.

---

Something to think about:

SL is still a relatively new engine, so if you're going to break existing content, this is the time to do it.

That said: the reality is by forking NL and not starting from scratch, you've inherited lots of design choices from NL. You should decide exactly which inherited NL features are up for potential changes and which ones are being kept as-is, even if you don't know exactly what changes you're planning. Currently, at least from an observer perspective, it looks like SL's existing features are still making many breaking changes and I certainly wouldn't feel confident making any levels that aren't boxed in (so you can't use the sides) and Classic 8 skills because anything else might change behaviors. Seems like every time I look at the SL board there's some other established feature being completely overhauled in a way that would break existing content -- which is fine for NeoLemmix content, since that's not designed for SuperLemmix, but also consider that you may be applying an expiration date to early SuperLemmix content because it's too difficult to predict how things will behave in SuperLemmix 3 months from now, let alone a year from now.

I don't have many levels out there, but I should probably comment on this here:

I discourage (but won't outright ban) unofficial SL conversions of my content. Because of the extensive number of differences, I simply cannot guarantee compatibility.

If you choose to port regardless, here are my boundaries:

• You must make it clear that it is an unofficial port, that is
  
  
  • I wasn't the one who did the conversion
  • Issues with the conversion should be reported to its maintainer and not to me (unless those issues are present in the originals)
  • The levels were intended for their original engine (presumably NeoLemmix)
• If the level does not have a time limit, do not add one. If WillLem culls the infinite time option: Set the time limit to the maximum value allowed.
• If the level is made for an engine that requires time limits (and thus has a time limit), the time limit should be removed.
• I don't have any worthwhile vanilla Lemmix content that has tight time limits, so don't bother guessing if it should have one or not.
• If the level was made for an engine that does not require time limits, then you can keep existing limits (there probably won't be any levels like this)
• If in doubt as to whether the level is intended to have a time limit: just remove it
• Always use untimed bombers, even if it's old Lemmix content that would have had timed ones when it was created.

Quote from: kaywhyn on June 02, 2023, 11:54:26 AM
I don't have too much experience with Lix myself, but from what I have seen from the times I have played with it, what I like about Lix, in contrast to NL, is how the hotkeys for everything are all on the screen for you. Therefore, you don't have to worry what they are in case you forget. Yes, it is quite cluttered as a result, but it does make the UI more user-friendly. It even tells you when you're in replay mode to click to cancel. Not so in NL. The other way to cancel replay mode is with the C key, but I never use that. I always use mouse clicks to cancel replay mode.

At the same time, because I'm so used to the hotkeys of NL, I ended up changing all of Lix's to match NL's, meaning FF is F, Restart is R, etc. The one thing I do miss is the lack of a hotkey for "last skill assigned," as I find it super helpful when I'm LPing NL content. Of course, this will likely be a problem when doing Lix multiplayer, but that's because I haven't settled on a hotkey configuration for the skills, and in NL I don't ever use hotkeys to select skills, I always use the mouse to do so. Yea, I'm a bit of an odd horse this way I guess I just find it quicker to click with the mouse and how I'm more used to playing that way instead of with hotkeys.

IIRC the C hotkey almost got culled, and as far as I know I might be the only one that uses it.

I think a lot of people use the mouse to select skills in NL though; the learning curve for the hotkeys is fairly steep because of how much separation there is between where you can look up the hotkeys and where you can actually apply them. In Lix, if you don't remember the hotkey, you can just look at the button and then press the button it says. In NL you have to completely stop playing to go to the options menu and check, which probably means going back to the main menu (I forget if you can access it or not during gameplay, but while we're on the topic of forgetting what the hotkeys were, it doesn't really matter if it's accessible in-game or not if you gotta go back to the main menu to be able to produce the options menu without a hotkey). That's why it's much faster to click with the mouse in NL: technically if you knew the skill hotkeys, it would be faster, but the lookup process is insanely long.

The old "push buttons until you figure out what they do" approach really only works well on console games where there's not that many buttons to choose from. The keyboard has far too many buttons for that.

I thought I'd let you know this is a thing, but it's up to you if it's worth the effort or not: apparently, if you make a highlight out of a VOD, the VOD will still disappear after 14 days but the highlight won't; assuming they haven't changed anything about it since I tried it and just didn't update the system to delete the old highlights, as far as I know there's nothing that stops you from making a highlight that's just the entire VOD.

The NL build instructions are definitely not complete since they don't include how to get the graphics library set up.

Certainly the available tools (that I'm aware of anyway) are a bit of a demotivator for contributing to NL.

Is there a specific motivation for wanting to use the DOS version specifically? You may have better luck with Lemmix (or NeoLemmix if you don't mind enhancements/bugfixes). Probably using NeoLemmix (or, if you insist on timed bombers, SuperLemmix) is your best option; you can choose to either use the new stuff or ignore it and just use the old stuff.

The version of DOS Lemmings I have lying around says the BILLANDTED code is incorrect, *but* it seems to still work correctly (after entering the code and then starting levels as normal, press 5 on the numpad); it just doesn't TELL you that it accepted it. It's not good for custom content for other reasons, though... I think OhNo works a bit better, but I think there's a version of the original that might work better called LEMRMAKE.EXE if I remember correctly. But I don't know what the level skip code is in that one.

There's also CustLemm but the physics are kinda messed up.

First relevant point: Was the save requirement met?
This factor may very well affect the desired behavior! Generally, we don't want to have to manually end completed levels, but having the option can be nice when trying to optimize. We're not always trying to optimize, and probably not trying to optimize most of the time, so while we want to be able to accommodate this use case, the defaults should probably assume the player would like to move on when the level was successfully cleared.

---

Obvious end states (regardless of save progress):

There are no lemmings remaining.
There is no time left.
Only zombies remain.
All remaining lemmings are blockers with no way to free them (note: this specific case may be a niche for auto-nuke since they don't move and it's the only possible move).


Potential other case to consider (trivially-detectable soft-locks):

Too many lemmings have been lost.

---

Further thoughts:
In general, when one of these end cases is reached, if the save requirement has been met, the level should end unless the player explicitly chooses otherwise in the settings menu; if not, gameplay should pause or continue (or have an option), see specifics. Since we have the option to rewind, having the level forcibly restarted is no longer the obvious choice it once was. For clarity: the instant the save requirement is met is NOT an end state and should NOT auto-end; it's merely a milestone that affects what behavior we want to see when the level would end through other means.

When we have the option to pause, continue, or end the game: I think the player should have the option which one to prefer. If they prefer continuing, specific cases should force pausing (specifically, when physics can no longer meaningfully advance; i.e. the physics are unchanging).

There are no lemmings remaining. Should probably block further physics updates to reduce rewinding; there's no benefit to allowing the game to progress in this state. But, not ending the level means that you can rewind from this state, unlike the current behavior where this case always ends the level.

There is no time left. I think it's reasonable to want to pause or continue in this case. Should probably be an option. May want to consider combining with the other "soft-locking" case, where the save requirement can't be met due to losses.

Only zombies remain. If you pause in this scenario, there IS a reason to want to resume, as you may wish to watch the movement patterns of the zombies.

All remaining lemmings are blockers with no way to free them. I'd actually say this specific case should result in an auto-nuke and then proceed to the case There are no lemmings remaining to determine further behavior. No way to free the blockers = no walkers or bombers remaining. We want to auto-nuke since technically, the nuke could free one of the blockers which probably won't get it to the exit, but in theory it could.

Too many lemmings have been lost. It may be worth having an option for, and it's arguably a similar case to time up. Still, though, I think there's arguably a major reason we might explicitly not want to pause in this situation even when we would want to pause in other conditions: replay insert mode. When you have stuff happening in multiple spots on the map, sometimes it's convenient to just completely ignore all but one part of it, do what you need to do there, rewind and replay insert.

It prints the expected 16.

I also went a bit further and grabbed the values it would insert if asked to initialize the struct with 0.0f and -0.0f, which results in 00 00 00 00 for 0.0f and 00 00 00 80 for -0.0f.

A possible next step might just be to grab the source for al_map_rgba, compile just that, and then give magic pink as the arguments and then just see what the underlying bytes are. Maybe for some weird reason converting likes 0.0f and loading likes -0.0f or vice versa.

Hmmm, if plain C works it's probably possible to manually compile all the dependencies (or at the very least get a more specific reason why it doesn't work) but that sounds like quite the pain.

A few more thoughts on the Magic Pink issue:

First: it sounded from the initial bug reports that the workaround to bulk remove Magic Pink from the files worked. Might this be worth doing out of the box, and then culling Magic Pink support from Lix? Common image formats and editors have supported transparency for a long time; does Magic Pink still make sense in 2023? Does it save storage space compared to transparency after compression? It can't be saving CPU time since we have to replace it with transparency at runtime. And while it's not a very common color to actually want to use, it does mean that sets can't make use of it because it will always be changed to transparent. It's also a value that people have to memorize (even if it's not that hard) in applications where Magic Pink is required although my understanding is that Lix supports actually using transparency just fine so that's not as much of a problem as it could be.

Second: it seems likely that other recoloring is affected too, although it wasn't noted in the original report (while you noted that some UI elements wouldn't be recolored, we don't have any confirmation that this is the case). Knowing exactly how other recoloring is affected could be useful. If it's a +/-0 issue, for instance, I suspect recoloring would likely function properly when we're replacing a color that contains no 0 components. If it's something else (perhaps padding, perhaps some other issue we haven't thought of), then it's more likely to break consistently. But we can't know for sure without being able to test.

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?)