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.

Topics - Dullstar

Pages: 1 [2] 3 4 ... 10
Closed / [BUG][PLAYER] Unknown-cause Corrupted Installation
« on: September 23, 2020, 12:31:24 AM »
EDIT: Locked by namida as there's no useful info to go on, and no further reports of this happening. Please create a new topic or PM me if you have more info / it resurfaces / etc.


I figured I'd report that this happened, though I have yet to figure out why it happened.

When launching NeoLemmix Player, the following errors appear

Error 1:
Error loading level packs and/or progression. Progress will not be saved during this session.

Error 2:
Error during settings loading:
EAccessViolation: Access violation at address 00B43628 in module 'NeoLemmix.exe'. Read of address 0000000C
Default settings have been loaded. Customizations to settings during this session will not be saved.

Error 3:
An error occurred while trying to save data.

The menu will then load. No pack will be selected.

On attempting to select a pack:

Access violation at address 00B313D6 in module 'NeoLemmix.exe'. Read of address 0000000C.

F3 on menu for settings:
Loads properly.
When exiting this menu:
An error occurred while trying to save data.

On exit:
Error 1:
An error occurred while trying to save data.

Error 2:
An error occurred while trying to save data.

(not a copy/paste mistake - the error appears twice).

So far, it hasn't come back after creating a fresh installation and copying over settings, levels, replays, styles, music, and pretty much all the data you'd actually care to preserve between installations. I did attempt replacing the .exe in the original installation with a fresh one, which did not fix the problem.

The first attempted launch which exhibited this behavior was when testing an in-development style through the editor, but that might have been a coincidence.

Found in v1.27, but at least quickly checking in older versions of the editor from installations of older versions (since I usually make a fresh installation each major player version), it's been present since at least v1.11, and is probably even older than that.

It appears to occur with any dropdown menu, as the style selector, music selector, and theme selector all appear to be affected.

OS: Windows 10

Loading a large level before attempting to reproduce is not necessary, but may help to visualize the issues more easily.

Issue 1:
To reproduce:
Load or create any level with a minimum size such that you can scroll the level vertically (you can zoom in to accomplish this). Having terrain and/or objects present in the level will help to visualize the issue, but is not required. Make sure no objects or terrain are currently selected.
Now, hover the mouse over the style selector/music selector/theme selector and use the mouse wheel to change the selected option.
Expected Result: The next option in the dropdown menu should be selected.
Actual Result: In addition to the expected result, the level will also scroll in the direction the mouse wheel is moved. Note that is the same scrolling behavior that occurs if the mouse is hovering over the vertical scrollbar on the right side of the screen. Every other mouse hover location I thought of to try using the mouse wheel either zoomed the level or did nothing (except the horizontal scrollbar, which behaves properly).

Issue 2:
To reproduce:
Load or create any level with at least one terrain piece or object, and select at least one terrain piece and/or object placed within the level.
Now, hover the mouse over the style selector/music selector/theme selector and use the mouse wheel to change the currently selected option.
Expected Result: The next option in the dropdown menu should be selected.
Actual Result: In addition to the expected result, the terrain pieces/objects will be moved in the direction of the scroll wheel. This particularly seems strange because there doesn't seem to be any other circumstance under which the scroll wheel can be used to move terrain/objects.

Note that clicking on the dropdown menu and then scrolling through it with the mouse wheel does not trigger this bug.

From the components present in a NL style, it is often possible to build up much more complex pieces using combinations of blocks and erasers, such as the numerous vertical/horizontal to diagonal bar transitions in this level:
(yes, I keep re-using the same level images I have lying around if they happen to demonstrate my point)

Now that we have terrain grouping, I can see that it has useful properties when working on these sorts of combinations: not only do they become easier to select, any erasers that are included to make up the piece are absorbed completely into the group and essentially become a private member of sorts: it exists to the pieces inside the group, but the surrounding pieces only see the net result of the combination of pieces and don't have to worry about implementation details like what erasers were necessary to make the block possible. In that sense, the terrain block thus functions exactly as a piece provided by the style. You can even use it as an eraser or as part of another terrain group - that's right, nesting terrain groups works exactly how you would expect, and they ungroup cleanly one nesting level at a time.

So, what's the suggestion?

These are two closely related but also mostly independent suggestions, though if both are implemented the implementation of 1) may have implications for the best way to implement 2).

1) Allow user to save commonly used terrain groups. They could then be lumped in with a style's terrain or as an additional groups tab to go with objects and terrain... well, most of the time. But sometimes styles get mixed, and then how should that be handled? Should the piece be shown in the groups tab for each contributing style?

2) Allow style developers to provide pre-built terrain groups. To simplify dependencies, it might be best to require all pieces come from the style the group is defined in. These could then be displayed either as regular terrain, or in a separate groups tab as described in 1). Many styles already feature distinct terrain pieces that are essentially just concatenations of smaller components (e.g. pillars and longer pillars in orig_pillar; bars and longer bars in orig_marble); while this wouldn't necessarily replace that for backwards compatibility reasons, it would be an option for new styles going forward.

Since terrain groups are simply groups of other terrain, levels wouldn't need to be aware of whether the user used a saved/pre-built group or built one from scratch like you can do currently, since it would all look the same in the level file. Therefore, in addition to convenience, it would allow more flexibility in updating styles without introducing breaking changes, as pieces provided as terrain groups can safely be modified or even completely removed from the style without breaking levels that use them as long as the underlying component pieces are left unchanged.

NeoLemmix Styles / [Discussion] L2 Classic vs. Orig Pillar
« on: August 11, 2020, 10:40:15 AM »
Aesthetically, the original game's Pillar style is very similar to L2 Classic. However, they are not the same. In the original game, terrain pieces could be placed on any pixel coordinate, but L2 has a much stricter terrain grid. For this reason, many of pillar's block pieces could not be inserted in L2 unmodified, because they were sized in such a way that they do not line up with the original grid. In fact, many of the terrain blocks can't be lined up with any grid due to the larger blocks being sizes that are not evenly divisible by the smaller blocks.

This design quirk of the Pillar style has made it difficult for me to work with when designing levels, and it's actually caused me to scrap level layouts and redo them in other sets (usually L2 Egypt) on multiple occasions (an example of a level I've released that underwent this change is my Contest 20 level "Tunnel Project"). This is kind of a shame, because aesthetically the style is quite nice. Therefore, I'm thinking I'd be able to get more use out of it if I go ahead and port L2 classic to NeoLemmix and use that instead of Pillar.

When I do this, would it be preferred for me to make it an expansion to Pillar, or an entirely new style?

I was testing a level out and I wanted to see how many stackers, hypothetically, would be required to make this fall safe, if that's the route I decided to go to get the shimmier down. With three stackers, the shimmier will survive the fall, but the climber dies. I don't know if the shimmier gets an extra pixel of safe fall distance or if the climber gets one less pixel of safe fall distance.

I'm guessing it's probably a bit too ingrained to fix, even if it is a bug, but I figured I'd at least report it.

At the very least, the splat ruler doesn't really lead me to identify this as the expected result.

Fairly self-explanatory, really.

Right now, when you look at an exit in clear physics mode, it tells you it's an exit.
If the exit is locked, it also tells you it's an exit.

It does not tell you it is a locked exit; this must be inferred either by interpreting the graphic outside clear physics mode or by finding buttons in the level.

So I found out you can do a thing. I don't think it's intended, but technically it could be used as a feature. I'm not endorsing this technique, but I think it's best to go public about this discovery, and let the community and namida decide what, if any, response should be made to prevent it, rather than relying on obscurity to make sure people don't do it. Of course, if you know relative file paths, it's pretty trivial, but on the other hand you might simply not have thought to try this, because, well, you probably shouldn't actually do this.

Maybe this should have gone in the Bugs and Suggestions subforum instead, but I wasn't comfortable calling it a bug and also wasn't comfortable calling it a suggestion either. I guess I'm intending a discussion here? Still, mods: I won't be upset if you decide it should be moved there.

This is almost certainly bad practice and you probably shouldn't do it.

A recent post by WillLem led me to believe he'd encountered an issue with a music pack masking the default music and got me thinking about the way music filenames are handled and how name collisions can occur because of it. I wanted to think about ways the engine could help prevent these collisions (beyond just hoping pack authors adopt their own unique subfolders or naming conventions), and this made me think about whether we could allow level packs to store their music in their own fully self-contained music folders inside the pack, instead of part of a separate directory. I wrote up a huge post about it (along with some other methods of alleviating some of the issues) and then second-guessed if it was worth posting, but I then thought about this:

What if it's already possible for level packs to have their own music folders stored with the pack and not in the music folder?

It turns out, it is! Suppose your pack is located in levels\My_Pack and you want to put the music in My_Pack\Music (as opposed to a My_Pack subfolder in the main music folder). We're already allowed to have our music in a subfolder of the main Music folder, and this is the feature we can abuse to accomplish this nonstandard music location.

The music selection box lets us type the filename in. This is useful because otherwise subfolders wouldn't work, and subfolders are useful since they mean we can store the music for a particular pack or author together to try to reduce the chance of name collisions. It would also be a pain to find the file you want if your music folder is filled with the music from several level packs, so typing it in lets us find it faster. Plus, even if we weren't allowed to type it in, we could just fill in the relevant information in a text editor. There is also nothing that stops us from nesting these subdirectories, which is still useful for something like Music\Author_Name\Pack_Name\[songs go here]. If we are in a command prompt and a certain subdirectory of some arbitrary directory, and we want out of that subdirectory, all we need to do is type
Code: [Select]
cd ..Now we have everything we need to put the music wherever we want: to put the music for the pack in levels\My_Pack\Music, all we need to do is type the following into the music selection box:
Code: [Select]
I'm not sure if this should be allowed, but the engine won't stop you.

It'd be pretty stupid to step outside the NeoLemmix base directory because from that point on who knows what the directory and filesystem might possibly look like, but it is allowed by the engine. Absolute paths, however, are not (which is a sensible design choice since there's absolutely no reason to use an absolute path since it likely won't work on anyone but the original creator's machine, unless by coincidence someone else uses the exact same folder structure).

I'd say that \..\ in the relative path probably shouldn't be allowed, but perhaps packs should be allowed their own internal music folder since this does have some utility for avoiding name collisions by keeping the pack entirely self-contained - though if we decide to go that route, we'd definitely want to discuss the exact rules for it, since it would probably be a useful feature to allow a structure that allows multiple packs by the same author to share music.

Found in latest stable; did not test in latest experimental.

Updated OP with more accurate steps.

To replicate:

1) Load or create any level.
2) Load a level that is the same size as the current level, but has a different background.

Result: The background from the first level will be shown. This is purely visual and only affects the editor: the correct background will be shown in the player, and if the second level is re-saved, it will keep its original background (unless you change it yourself, of course). This only happens the second level is loaded; a new level will not be affected, even if the first level is the default size.

This size requirement means that in a fresh editor session, you can't properly display the background of a default-sized level with a background other than the default solid black without first taking other actions, such as resizing the default blank level, loading another level (of different size) first, or manually selecting the correct background.

The earlier report had some incorrect observations as a result of the at-the-time unknown size requirement.

Old report (click to show/hide)

Under certain conditions (the exact details of which I haven't quite worked out yet) the talisman conditions for some levels cannot be edited.

I'll update with more details if I can figure out exactly what's going on, but I've attached the level I found this on.

The talisman "Optimization Lv. 2" was intended to have a limit of 3 bashers, but was saved with no requirements. I didn't notice this when the v9 update was first released (it was a contest level). When I noticed, I tried to fix it through the editor, assuming it was an oversight on my part, only to find that I couldn't change it. I thought that it might be due to its similarity to the talisman "Optimization Lv. 1" (limit 4 bashers), so I tried removing one of them, and the delete button didn't do anything.

Manually editing the talismans in a text editor worked as expected.

Closed / [PLAYER][SUGGESTION] Option to force default lemming sprites
« on: June 18, 2020, 11:44:41 PM »
Some custom content exists featuring custom lemmings sprites and recolors. While many of these are fair and well-designed, there are a few that lack colors for neutrals, athletes, and zombies.

Ultimately, it might be difficult to prevent such content from being created. Even if you were to require unique colors, someone could always try to make one with the minimum allowed differences.

I think a good solution to this on the player's end of things would be to include an option to force the player to use the default sprites, even if custom sprites or recolors have been provided.

The topic title can probably be improved.

No-Effect objects do not interact with the No Overwrite checkbox in the same manner as other objects.

Suppose I were decorating a level using a water object. The water object is, by default, no overwrite, so it only appears behind other objects. But, if I want to draw it in front of an object, I simply have to disable the No Overwrite checkbox. However, No-Effect Objects do not respect this checkbox; they can be drawn where there is no terrain, or you can turn on Only On Terrain to draw the object on top of terrain, but you can't have a single No-Effect Object that is drawn in front of terrain the same way you can with a water object. I imagine this was most likely done to prevent troll levels from being made, but in this case it 1) interferes with non-troll decoration and 2) doesn't actually even help because a workaround exists: you are allowed to perfectly overlap a No Overwrite No-Effect Object on top of an Only On Terrain No-Effect Object, which will look and function exactly as it would if No-Effect Objects respected disabling the No Overwrite textbox.

Suggested discussion questions:
Should this restriction be kept? If so, should the workaround be removed (this would likely require a reworking of Only on Terrain to be tied to object types instead of object instances)?

Suggested changes:
Considering that users who want to make troll levels can still do so by making a custom style, I'm not sure I think removing legitimate decorative features that can potentially be abused to make troll levels is the way to go about it - after all, such users can be punished simply by leaving bad reviews on their packs :evil:. However, contrast this with Fake or Invisible Objects: these features are really only usable for troll levels, so culling them was a wise decision. For that reason, I'd suggest making No-Effect Objects respect the No Overwrite checkbox being off (for compatibility, the checkbox should probably be applied to non-Only On Terrain No-Effect Objects when loading levels predating this change, if implemented).

That said, I do think it's important that whatever choice is made here is done consistently. Thus, if we decide the existing restriction to require No Overwrite for No-Effect Objects should be kept, the checkbox in the editor should be grayed out to match, and the workaround should be patched by reworking Only On Terrain to not allow it to be applied to specific instances of arbitrary objects.

Help & Guides / Lemmings 2: Error Number 8001
« on: April 14, 2020, 04:34:22 AM »
Couldn't find anything about this online. Attempting to run on actual hardware.

Code: [Select]
Error Handler : Error Number 8001
457712 bytes Main memory used
1443168 bytes Expanded memory used
27136 bytes Main memory free
32111264 bytes Expanded memory free
1432 bytes of Data Space free
MEM Error : 1 : No Memory Available of required type

Figured I'd see if I can figure out why it's not working. Don't know what the hardware requirements are or if the computer in question meets them - I think I've had it running on that computer before, but maybe I've always only had it working on DOSBox and forgot about it.

I was working on an unrelated practice project earlier today, and some of what I was thinking about while working on it made me curious to see if the lemming indexes would get messed up if you used cloners with replay insert mode.

Sure enough, this causes assignments to get shifted to different lemmings.

I created a fairly generic level layout where lemmings would be trapped on either side of the level, remaining capable of receiving assignments. Lemmings spawning from the trapdoor would head to the right, while lemmings created by cloners assigned to newly spawned lemmings would head left. Lemmings had access to being a cloner or a builder.

Test Case 1:
 - Assign a builder to the second lemming some time after spawn.
 - Restart the level, and turn on Replay Insert Mode (the blue R thing)
 - Assign a cloner to the first lemming before the second lemming spawns
Expectation: The builder assignment should be unaltered (assigned to the second lemming from the hatch).
Result: The clone will use the builder.

Test Case 2:
 - Assign a cloner to the first lemming as soon as it spawns.
 - After the second lemming spawns from the hatch, assign a builder to the clone
 - Restart the level
 - Bring up the replay edit mode and delete the cloner assignment.
Expectation: The clone's builder assignment shouldn't happen because the lemming no longer exists.
Result: The second lemming from the hatch will use the builder.

Test Case 3:
 - Assign a builder to the third lemming.
 - Restart the level and turn on Replay Insert Mode
 - Assign a cloner to the first lemming as soon as it spawns
Expectation: The builder assignment should be unaltered (assigned to the third lemming from the hatch).
Result: The second lemming from the hatch will use the builder

Because of the behavior here, a cloner assignment can cause problems to skill assignments that should have been independent of the cloner; for example, in a multitasking level.

This is likely caused by the lemming indexes: Lemming 0 is the first to spawn, Lemming 1 is the second; if a cloner is used when N lemmings are in the level, the spawned lemming will have the index N (not N+1, because the count starts at 0). Normally, lemming N would have been the next lemming to spawn from the hatch. When a cloner is inserted or removed, indexes at or above the clone's index get shifted around to different lemmings than they would have otherwise been, so the skills get assigned to the wrong lemming.

But if you altered the resulting lemming index for the clone, it would break replays. Maybe it would be possible to adjust the assignments such that they will still correspond to the same lemming (probably deleting them if they would have corresponded to the clone)?

Help & Guides / Barns, animals, feeding: Software class design
« on: February 18, 2020, 02:23:53 AM »
We seem to have several reasonably experienced programmers on these forums, so I thought I might put this question here.

I'm still trying to learn how classes work and when to use them. From what I've read about them, they sound like they'd help me with organization on larger projects. I might just be having some sort of misconception about how to use classes, but I've come up with the following illustrative example (the actual project has nothing to do with barnyard animals, but I think it's a simple way to illustrate why I want to organize things this way that I suspect the language doesn't want me organizing them):

Suppose we have barns filled with animals and food. In this example, the food supplies in each barn are shared between animals in the same barn, but not between individual animals. Each animal has a daily routine that involves eating if there is enough food in the barn (else, the animal starves). So I'd like to organize things like this:

Note that this isn't intended to be partial code in any language. It's just pseudocode.
Code: [Select]
class Barn:
    contains animals and food

    method have_animals_do_stuff:
        for each animal in animals:

My first instinct would be to try nesting classes, which the interpreter does seem to allow, but it seems like this doesn't actually accomplish anything since from what I could find it sounds like Python doesn't let inner classes access outer class variables.

It's not really a big deal, since it can be fixed just by adding or subtracting a few pixels from the height such that the height is divisible by 4 (I think that seems to be the pattern, at least), but updrafts do not tile correctly in the y direction when their height is not a multiple of 4. It looks correct at all sizes in the x direction.

It also looks correct to me in the editor, but of course it's not animated in the editor.

Pages: 1 [2] 3 4 ... 10