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 ... 10
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.

SuperLemmix / [DISC] Existing content preservation
« on: June 05, 2023, 08:07:55 PM »
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.

If a climber or a slider is facing left and passes through a permanent skill remover, they will be embedded in the wall.

(For clarity, since Sliders turn: the slider would have been traveling right before transitioning to slider: that is, this always occurs when the skill is interacting with a right-facing wall, thus lemmings interacting with the wall are facing left).

The object works as expected when lemmings are facing to the right.

For what it's worth, when NL redefined Release Rate in order to remove the duplicated values in the original, I switched my config to Spawn Interval because I figured if I was going to have to relearn the values, I may as well use Spawn Interval because the definition is very unambiguous about what you get when you use it: the spawn interval is the number of frames between spawns, whereas release rate is an entirely arbitrary scale.

Having cleanse levels available from the player makes sense when you're updating a pack's worth of levels in bulk, but if you load an outdated level in the editor, presumably you want it updated to the latest format, and I've definitely seen a few instances of editor bugs where the problem was "user failed to cleanse level prior to attempting to load it." While this is easy to workaround, it's not really readily apparent that failure to cleanse the level is causing the issues (essentially, "Did you try cleansing the level first" has become the NL editor equivalent to "Did you try rebooting?"), and it's kind of annoying. Why would the user want to load the level without cleansing it first, when this can cause problems? Of course, there's one major technical problem: the level doesn't appear to store any information that would indicate that it needs cleansed. But that's fixable: we could add a field tracking this, and if this field doesn't exist, we know the level predates it and therefore should probably be cleansed just in case, so go ahead and cleanse it.

Closed / [SUGGESTION] theme.nxmt overrides
« on: April 15, 2021, 08:05:54 PM »
This has definitely been brought up before, but I'm not sure it's ever been made its own thread, so I'm going ahead and creating a thread for it.

Problem: A pack might want to have certain items provided by theme.nxmt consistent for the whole pack, e.g. Lemming sprites. To do this, currently one must set all levels in the pack to the same theme. However, theme.nxmt also affects things such as one-way-walls, pickup skills, builder colors, the background color, which we would probably still want dependent on the level's information, and not the pack's. So if we want to have custom lemming sprites for the pack, but retain other style properties given by theme.nxmt, we must create a theme for every combination of custom lemmings and styles that we might want!

Proposed Solution: A pack could provide a theme.nxmt file that isn't required to be complete. Anything present in the pack's theme.nxmt replaces the equivalent fields provided by the level's. Ranks could also provide these, too, although this would raise the question of what happens if the pack and the rank both provide one. More on that later. This still leaves individual levels out (I still might want the custom lemmings in an individual level, after all!). Theme.nxmt is a pretty small file, though - if we really want to override it in an individual level, we could simply embed one within the level (alternatively, a file with the same filename as the level but different extension). Of course, this would result, as implied earlier, at least 4 potential sources of theme to go through, so how would we decide what gets priority?

I'd suggest going in the following order, where the first item is the one that's processed first, and then each subsequent item overrides the result of the previous operations:

Level's specified theme.nxmt -> Level's embedded theme.nxmt -> Rank's theme.nxmt -> Pack's theme.nxmt

I haven't actually checked if subranks are a thing or not, but if they are, we'd just work our way out starting with the level's subrank to its parent, continuing until eventually reaching the theme.nxmt of the parent pack.

Finally, if we really wanted to be able to stop overriding at a certain point (perhaps we want a specific level's embedded theme to take priority over the pack's), we could mark fields as "FINAL" which would block that field from further overrides.

Editor Bugs / Suggestions / [SUGGESTION][EDITOR] Auto theme
« on: February 11, 2021, 07:15:26 AM »
Ever since the introducing of style mixing back in whenever-that-was, the theme (which affects things like colors, lemming types, etc.) has to be tracked separately from pieces. For this reason, when building a level, it can be easy to forget to change this, leading to orig_dirt's color schemes basically becoming the default since "oops, I forgot to change it to match the primary style!"

I'd suggest creating an "auto" setting for theme, and making it the default for new levels. When auto is selected, the theme will be taken from the style from which the most terrain pieces and objects are taken. This might not always get it right - for example, if you have a primary style with a few really big pieces decorated by many smaller pieces from a different style - but you'd still be able to explicitly specify.

A possible edge case would be if there are any ties. If this happens, use something like alphabetical order to determine the result. If the result is determined during player runtime, I wouldn't suggest using something like styles.ini - the final result should have an objectively correct answer that's not dependent on the player's settings. However, the editor could bake it into the level (in which case the player would not need to know about it) - though this has the disadvantage of losing auto when the level is saved for the first time. This could be countered by having the editor save the result of auto in the level, but also store the fact that the theme was set to auto; the editor would then load auto, while the player would load the result.

Closed / [BUG][RC EDITOR] Default size of objects not supported
« on: January 20, 2021, 12:42:00 AM »
Objects with default size are loaded/created with the size of the graphic, not the default size of the object. This affects adding new objects to a level, as well as loading levels predating the vertically resizable water.

The player loads these levels fine.

Tech & Research / PC-98 Lemmings
« on: January 05, 2021, 05:08:01 AM »
There isn't much about this port out there (I've seen several lists of ports that are unaware of its existence), so I've been messing with it a bit.

These are my somewhat disorganized notes on it:

It doesn't use either the Amiga or DOS music ordering. I have not yet determined if music is tied to the level or to an order like in DOS.

The level format is largely shared with DOS, and the PC-98 levels can be loaded and saved by vanilla Lemmix without issue. Repeat levels appear to be stored differently somehow - I didn't see an ODDTABLE.DAT. I assume it's probably still there somewhere, though - but I don't know where. Passwords are shared with DOS as well, and the special graphics levels are included. I have not noticed any level differences between DOS and PC-98 so far. However, the UI is based off the Amiga version rather than the DOS version.

I don't have much experience with the DOS version glitches to test them in this version, However, I was able to confirm that direct drop works in this version of the game. I would not be surprised from what I've seen so far if most of the DOS glitches still work here.

Help & Guides / [Guide] Running PC-98 Lemmings in Neko Project II
« on: January 05, 2021, 04:16:48 AM »
This information is largely adapted from this guide intended for Touhou.

Disclaimer: While I haven't noticed any issues with them, follow the download links at your own risk.

Note that a copy of Lemmings is not provided here. You will have to find that yourself.
The emulator: The Touhou guide recommends using the unofficial fmgen build, available here (scroll down until you find a file called "np2fmgen.7z" - 7zip is required to extract it): . Lemmings doesn't appear to use any features that benefit from this build over the official one, but relevant to Lemmings, there is a speedup function in the fmgen build. The audio emulation is noticeably better for some games in the fmgen build, but Lemmings seems to emulate plausibly well in both versions (I don't have real hardware to compare to at this time). The rest of the guide will assume the fmgen build, though much of it will work in the official build.

Configuring the emulator: There's multiple executable files in the fmgen build download. Multiple of them will probably work, but I'd suggest using np21nt.exe. The colors will look super wrong by default. You can improve this considerably by turning on Real Palettes (under the Screen menu). It doesn't seem to be perfect, though - I don't know if it's an emulation problem or if that's just how the PC-98 port is. Also, go to Emulate -> Configure, and set the multiplier next to the CPU selection. 32 should work okay, but if the performance seems bad, experiment with it a bit. I got bad performance when this was too low as well as when it was too high. Unlike DOSBox CPU cycles, however, I didn't seem to notice any immediate changes when messing with this - you'll probably need to reset to apply the changes.

Launching the game: You'll need to mount the disk image. If you've got a harddisk image, mount it as one of those (Harddisk -> IDE #0 or SASI #0 depending on build); if you've got a floppy disk image, you'll want to go to FDD1 -> Open (no guarantees they both exist). Then, go to Emulate -> Reset and it should start up. F12 should activate the mouse. If it doesn't, go to Device -> Mouse.

Lemmings Main / Dullstar's Java Rant
« on: December 22, 2020, 05:56:09 PM »
Edit Simon: This thread arose from NeoLemmix, SuperLemmini and Lix, Feature Comparison by WillLem.

Quote from: Simon
The Java Runtime is beh as a dependency, can't just ship the game binary and DLLs, always have to tell people to install Java.

This is another topic I could go on a very long rant about. As a user, I hate Java (I've also heard things about the language itself, but I can't really speak for that because the fact that any Java code I'd write would have to be run on the JRE is honestly kind of a dealbreaker for me). I hate Java so much.  And it's not just the fact that you have to download a runtime environment that makes this annoying, because you need to download the Python interpreter to run Python code, and that language isn't nearly as irritating about it.

Quote from: WillLem
For what reason? This strikes me very much as a "hating for the sake of it" kind of thing. Java is fine: the vast majority of applications require you to install something, Java RE is something you only install once and then you can run any Java app natively. And, it's multi-platform compatible. I'd say that's relatively convenient, as computer-stuff goes.

What I will say is that Java runs very slowly on my Mac, for some reason, and that is a bit disappointing, but not annoying. It's a 2012 MBP, so it's probably just not been able to keep up with the updates.

Well, since you asked:

Dullstar's Java Rant

A lot of this is based on some... adventures... with modded Minecraft, so I suppose it's possible that I'm directing blame to the wrong place, but...

The JRE has two major issues (or at least, had - I've had the updater silenced for quite some time since I only use it for Minecraft now). First, it has my least favorite type of updater: the one that simply tells you that an update exists, but you have to do all the work yourself. This would always lead to a lot of fun adventures back in the day related to making sure Minecraft had all the memory it needed: the downloads page would (I seriously hope they've fixed this by now) always want to take you to the 32 bit version, so then you'd have to track down the 64 bit version instead, which of course was not on the same page because of course it wasn't. Okay, so you found the 64 bit version, let's try to install it, aaaaand oh it wants to install some other junk we don't want. Untick those boxes for like some McAffee trial or Ask toolbar or whatever it was they were peddling... okay, finally, it's installed! A few days later - there's a Java update! Click here to start updating. You wanted the 32 bit version, right? No? Well, then, find the 64 bit version again... download... start the installer... untick the boxes...

For comparison, the Python interpreter:
Go to the website, click downloads, it's easy to find the other builds if it doesn't default to the one you wanted, run the installer, and you're done. No wild goose chase to track down the 64 bit version, no extra junk to opt-out of during the installation. You only need to do a bit of manual work with the installation if you want to change some of the settings, but the defaults are all reasonable.

The second issue is that the JRE is terrible at memory management. For many applications, this doesn't matter because the memory usage never gets that high, but that's not the case for every application out there. Instead, you must tell it how much memory it should allocate ahead of time. Now sure, there's defaults, but they're not suitable for all applications, and when you have to mess with them, that's when things get pretty nasty. Don't allocate enough, and the program will keep pausing to run the garbage collector. You can give it a bit more breathing room by expanding the amount of memory it has to work with, but be careful if you're running other applications in the background! Allocate too much and the JRE will crash when it needs to use that memory - it can't cleanly handle the system running out of memory. Granted, many applications can't - but Java is garbage collected, so if you run out of memory, there is something it should be able to do: run the garbage collector to free all the junk. So if you've got an application that requires a lot of memory, such as a modded version of Minecraft, you'd better make sure there's no memory hogs running in the background like web browsers can sometimes. Being able to limit the memory usage of an application that's holding onto unneeded stuff in memory simply for performance isn't a terrible idea - that'd be great for making my web browser play nicer with other applications since it likes to hold some stuff in memory to speed up loads and overtime can lead to the browser consuming like half of the available memory even though it doesn't actually need that memory to function. But if you're running something like a game, you probably want the computer to give the game everything it's got (well, if it would benefit from it anyway), and this is where the weaknesses of Java's memory management show through the most. That's because the maximum memory allocation size isn't just a cap: it's also a promise to the JRE that it will receive up to that much memory if it requests it. This means I can't give it free reign to use as much memory as it needs, because I have to choose a maximum memory allocation such that I expect it to always be available. And of course it doesn't allocate this right away (I mean, it really shouldn't, but if it's going to behave the way it does at least this would make it a start-up error instead of a runtime error) - it waits until the application needs that memory, but it also adjusts the behavior of the garbage collection based on this, so you'll have a lot of situations where it decides to allocate more memory instead of running the garbage collector. And then if that memory isn't available, the program crashes! Frustrating!

I'm guessing this probably didn't get a lot of attention during the testing of the release candidates, because many (most?) of us have automatic saving on, but I recently wanted to save a best-attempt replay of a level I wasn't able to solve, and that has to be done by saving manually. So, on the post-view screen, I clicked the save replay button.

Expected: Preferably a file dialog, but at least some sort of feedback indicating that the replay was, in fact, saved
Actual: Replay saved silently, with absolutely no feedback. At first I thought my click didn't register until I tried it again and it still appeared to do nothing

I think a file save dialog is the best option here, because if I'm choosing to save a replay manually, there's probably something special about it that would make it desirable to explicitly choose a filename rather than relying on the automatically generated filename.

Closed / [SUG][PLAYER/EDITOR] Version field for levels
« on: October 08, 2020, 10:33:45 AM »
I'd like to suggest adding an optional version field to the level format. This information, if present in a level, would also be saved into replays made for that level.

The main use of this, in my opinion, would be for replay management. Currently, other than trying to load it and see if it works, there's no way to tell what version of a level was made from unless it's been baked into the filename. You could alter the level ID, but then a replay is recognized as being for a completely different level, and depending on what changes were made, there is a chance the replay might still pass - so it is still potentially useful to load a replay from an old version in a later version of the level - certainly, the chance the replay passes is a lot higher than the chance a replay from a completely different level passes. I believe you can still load the replay anyway, but it would be useful to have a different warning for "This replay is for a completely different level" and "This replay is for a different version of this level."

Sometimes, people have an outdated version of your level (and don't realize it) and they submit a replay they think may be a backroute. It may still be useful to watch the replay, even if it fails the current version of the level: is it an old backroute that you've already fixed? Or is it a new backroute that could still be made to work in the current version even if the changes to the level were enough to break the replay? But which old version of the level does the replay go with?

If a replay from an old version passes a new version, it might be beneficial to have it automatically resaved with the new version as well, either as a separate file, or by allowing the replay to store a list of versions that it's known to work against.

There could also be some potential for discussion of what, if anything, the editor should do to help manage this, but I think that might be best saved for after we decide whether or not this feature should be added at all.

NeoLemmix Styles / L2 Classic Style for NeoLemmix
« on: September 25, 2020, 09:14:16 AM »
Sometimes, orig_pillar can be a bit of a pain to use: it has a lot of blocks that really seem like they should follow a grid, but they're off by a few pixels, making it difficult to combine differently-sized pieces to build larger structures. L2, however, follows an extremely strict grid, and as it turns out, a lot of changes had to be made to the style to compensate for this (I've documented most of them in another topic). I proposed adding the pieces to orig_pillar, but there was more support for making a completely separate L2 classic style, so that's what I've done here using some .pngs containing the tiles and objects provided by Icho.

I certainly find this set a lot easier to use than orig_pillar, and hopefully I'm not the only one who will find it useful.

Trigger areas for objects are based off of the trigger areas of the sets they originated from. The traps currently don't have any constant animations despite being closely related to objects from other sets (of course, they also don't blend in very well...) - still, it might be better if it had them. If you want to provide these, they are welcome additions.

2021-01-24: updated for resizable terrain. Pillar and wood pieces (that are not end caps) can now be resized. There are no plans at this time to make the blocks support nine-slicing, though I would probably accept the modification if someone wants to do it themselves as long it's acceptable quality.

Closed / [BUG][EDITOR] Nine-slicing doesn't display right in editor
« on: September 23, 2020, 01:19:46 AM »
This is probably a known issue, but on the other hand there aren't a lot of resizable objects that don't just tile the whole graphic right now. In fact, there's only one that I'm aware of, and that's the default updraft graphic. However, in the L2 classic style I'm working on, I didn't really see a lot of reason why the water shouldn't be vertically resizable, so I went ahead and set that up. But it doesn't look right in the editor. Works fine in game.


In game:

Pages: [1] 2 3 ... 10