Quote from: Simon on June 09, 2026, 10:15:53 AMWhen two levels in the same pack share an ID, it confuses the mass verifier, okay.

What is with levels across different packs? Is it okay to duplicate one of the IDs outside the pack, as long as the pack, among itself, has all-different IDs?

Assuming it's okay to duplicate IDs outside the pack: How do authors with N packs verify solvability? Verify each pack individually, and point for each pack to a different tree of replays?

-- Simon

Across different packs, duplicate IDs do not really matter.

Replays are being checked in the mass replay checker out of one folder for one pack, so as long as a pack itself has no duplicate IDs everything is fine.

That way we cannot really run out of IDs.
The extremely rare case it could matter is if you create a compilation pack with levels from different packs, but I have yet to see an ID-collision there.

For replay verification of N packs: I go to each of the N packs in the level selection tree and click on the Mass Replay Check button for each one and select the respective folder. So I verify each pack individually as you stated.

In addition to what kaywhyn said, when you play two levels with the same ID one after another, the engine thinks you are still playing the same level and will start in replay mode. Sure, this isn't a huge deal as you can click to cancel the replay, but it's confusing for new players and best avoided.

Ah, yeah.

They weren't gitignore'd properly in the repo, but weren't generally being copied manually when updates were occuring. They also weren't being included in the backups. I fixed the backup script to include them while doing this update, including that the backup I ran just before the update was with the new version of the script - so this time, I am able to restore them (and have now done so). And going forward, they should no longer be a problem (but can be restored from the backup if they are).

When two levels in the same pack share an ID, it confuses the mass verifier, okay.

What is with levels across different packs? Is it okay to duplicate one of the IDs outside the pack, as long as the pack, among itself, has all-different IDs?

Assuming it's okay to duplicate IDs outside the pack: How do authors with N packs verify solvability? Verify each pack individually, and point for each pack to a different tree of replays?

-- Simon

Thanks for the explanation, kaywhyn That probably explains why it didn't seem like such an issue to me, because I've never felt the need to use the MRC. If (when?) I get to creating levels, I guess I will do. Maybe players as well as creators use it to check replay folders, but I never have, so far.

Levels having the same ID is a problem when it comes to verifying your replays with the NL mass replay check because it confuses it. Basically, when a replay is generated for a level, it has the exact same level ID as the level. Thus, if you have two levels with the same level ID, you will have two different replays with the same level ID, even if the level title is different. Nxrp files are text files, and hence you can verify the level IDs by opening the replays with a text editor, such as Notepad.

The underlying idea with the MRC is when you run it on your replays, it checks the levels by finding the one with the matching level ID as the replay. When it finds a match, it checks the replay to see if it solves the level and then it can spit out three different outcomes for the replay: Pass, Fail, or Undetermined. However, in this case, the mass replay check finds two levels with matching ID and hence the MRC will instead check the first replay with the corresponding level ID on the repeat level with the same level ID instead of checking the newer replay with the different level title despite having the same level ID as the replay for the original level.

The result => It can get very messy reading the text file that's generated after the MRC is done running when there's multiple levels with matching IDs.

That's why to prevent confusion with the MRC, it is advisable to always generate a different ID by using the random ID button in the editor, even for repeat levels. In this way, the MRC will run more smoothly when checking your replay collection for a level pack.

Split off Heart66 easy pack

Genuine question, as it's something I've never been sure about, but why is several levels sharing the same ID such a problem? If level 5 and level 11 share the same ID, the auto-generated NXRP files are differentiated by name and each will still play when selected for their corresponding levels, no? If it is such a problem, is there any easier way of fixing it than by manually checking for dupes and opening the problematic NXLV files in NLEditor to re-generate the ID with the Random ID button?

IDs in level files are easy to get wrong in seemingly normal editing workflow. The IDs are hidden in the level files and have no effect that a newbie can observe. Newbies have no obvious reason to de-duplicate IDs.

Can you find something better for replay-to-level association that doesn't give such opportunity for mistakes?

The obvious continuation here would be to immediately discuss what Lix does, and what NL does. But I hope to bring new designs to light unprimed. You can always copy existing designs later.

-- Simon

CE 1.1.1

This is serious data loss.

Here is a typical settings dir from vanilla NL 12 or from NL-CE 1.0.x:

NL/settings/hotkeys.ini
NL/settings/settings.ini
NL/settings/styletimes.ini
NL/settings/userdata.nxsv

Now:

• Have such an already-set-up NL or CE 1.0.x.
  
• Extract CE 1.1.1 over the existing directory structure.
  
• Run CE 1.1.1's executable.
  
• CE 1.1.1 detects a missing ./settings/NLCESettings.ini.
  
• CE thinks that you're a new user, and shows the following dialog.
  
• In the dialog, CE lies about existence of ./settings/settings.ini.
  
• On OK, CE overwrites all of your custom hotkey bindings with one of its 3 premade sets.
  

Step 7 is the data loss. It arose from splitting CE settings from vanilla NL settings. I have several NL trees and, after that loss, could copy an old hotkey file into CE 1.1.1 as a workaround. Not everybody will have that.

I believe that CE should import from settings.ini when CE can't find a NLCESettings.ini. It should consider you an old user when either exists, and a new user when both files are absent.

Ignore the lie in step 6 until you've designed such an import. Presumably, in step 6, you want to print both filenames here. You'll show the dialog less often than now; you'll only show it when both files are missing.

-- Simon

Here's the Playlist as text.

Most of it comes from soundtracks of 90's DOS games. Hard to say what you like the most from it. Random grab of the more unique tracks from the playlist:

Winter Time II (.xm) (Youtube) and Buns & Guns (.it) (Youtube), both by Firage a.k.a. Kermakastikeritari

prehistorik.a2m (Youtube) by Nula. (Linking to Youtube because I assume you don't have an AdLib player installed. If you do, hunt around the net for the tracker file.)

Dynatech Ingame by Holger Gehrmann

The Humans, Ingame track 3 by Barry Leitch

-- Simon