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 - namida

Pages: [1] 2 3 ... 42
Not sure exactly what triggers this, nor if this bug is in the stable version or only in development code, but sometimes when placing a new resizable object, the initial size of it won't be correct. I've noticed this most often with the height; I don't think I've seen it happen with the width yet.

This may be a side effect of the modification to remove empty space around objects. If so, the fix is to simply not apply this removal to anything that's resizable (it'll likely mess with the tiling, and where applicable nine-slicing, anyway).

NeoLemmix Main / EXPERIMENTAL BUILD: High-Resolution Mode
« on: November 30, 2019, 08:11:57 am »
As this is a very major feature, it's going to need a lot of testing, so here's an experimental build you can use to test it out.

Steps to set up:
1. Download (or make a copy of your existing folder) the current stable version, including the styles
2. Download the attachment, which acts as an "upgrade" from the stable version to this experimental

If you start with a clean slate, you'll be asked on first run if you want to enable high-resolution mode or not. If you copy an existing configuration, high-resolution mode will be disabled by default; enable it in the Config menu.

While most UI elements have high-res graphics provided already, as far as styles go only four objects are provided in high-res - the default pickup skill, and the three default one-way arrows. All others are purely the product of the upscaler at this point in time. Note that there is only a difference in-game; the menus will look the same as they always have (although the level preview image on the preview screen will be generated using high-res graphics).

For now - please don't try to create dedicated high-res graphics for your styles. If you'd like to work on preparing high-res versions of the official styles, discuss this with me - I'm happy for this to happen, but let's make sure it's done right. (You can, however, try experimenting with the upscaling.nxmi file - I'll give more detail on this later.)

One other thing to be aware of - alias.nxmi is no longer in "data" in this build. Instead, put any custom alias data either in styles/default/alias.nxmi, or better yet, styles/(the style the alias is for)/alias.nxmi. ;)

There may be other small tweaks / fixes included in this build that I have not described here.

Please be reminded - This is an experimental build. It should not be treated as anywhere near stable. Any content you are creating should be tested using the stable version of NeoLemmix before releasing it. I do not recommend trying to create high-resolution graphics for your styles at this stage.

If you'd like to help with testing, but your PC isn't powerful enough to run high-resolution mode (note: turning off high-quality minimap REALLY helps, even more so than in low-res mode!), you could try running this experimental build in low-res mode and seeing if there are any new bugs that have popped up there.

Currently, if you have one-way arrows, if you flip these, it also changes their physics direction.

The same should happen for the force-left / force-right fields - horizontal flipping should change their direction. (Rotation should be forbidden. Vertical flipping should remain as-is; ie: a purely cosmetic thing with no impact on physics, but it is allowed.)

If you want to change a piece's name: Deprecate the old piece (add "DEPRECATED" on its own line to the NXMT or NXMO file), and create a duplicate under the new name (don't have "DEPRECATED" on the new one). Please then specifically point this out to Nessy when you submit the update to your styles where this happens; and we'll remove the original version (and get NeoLemmix to redirect to the new one automatically) in a future update.

If you want to remove a piece: Deprecate it instead. Only remove it if it's broken and can't be repaired, and thus "missing piece" errors are a nicer result than whatever happens if the piece remains existing in some form. If it's functional but you just don't want it in the style anymore (eg. perhaps you've replaced an object made up of three seperate pieces, with a resizable nine-sliced single object), then just deprecate it.

In the future, I'll likely look into a means where styles can specify the redirects themself, but currently, redirects are specified in a single central file.

And finally - this applies specifically to styles you've released. You can rename / delete as much as you like in unreleased WIP styles.

For the record - deprecating a piece means it still exists and will be found by NeoLemmix, but the editor won't display it in the piece selection list (unless the user specifically chooses to show deprecated pieces). It was specifically implemented for this kind of situation.

NeoLemmix Main / NeoLemmix V12.7.3, Editor V1.17 Release
« on: November 09, 2019, 06:26:25 am »
Well, it's time. V12.7.0 of NeoLemmix is here!

The first "flagship" feature is neutral lemmings. These are sort of half way between regular lemmings and zombies; and can be identified by their greyscale clothing; entrances that spawn them can be identified by a hollow diamond appearing over them. Like zombies, the player cannot assign skills to neutral lemmings. However, unlike zombies, neutral lemmings can be saved, and are not infectious.

The second is that custom pickup skill objects are officially supported now. A system has been implemented that allows for designing these, such that they won't need any updates if/when new skills are added, or the skills are reordered, etc. At the time of initial release, the only pickup skill objects present (other than the default one) are in namida_bridge, namida_basement and namida_garden; but I'm aware of several more that are in the works and will likely be in the next styles update (and probably available to download manually from the forums even sooner).

Moving onto smaller details, antisplat pads - a feature we had in old-formats that got culled in the move to new-formats - are back! We also have a few minor changes with zombies - they're now affected by the nuke, and a zombie that bounces off a blocker always infects that blocker (addressing an edge case where sometimes they wouldn't - this edge case resulted from the physics behaving exactly as intended so this was not a glitch, but was an illogical result, so there is now a special rule here). We also have an explicit rule for overlapping one-way arrows; one-way arrows of different directions that overlap each other now cancel out, instead of combining their effects in various (and visually-obscured) ways.

We've also had some tweaks to the styles and level formats. For styles, all styles included with NeoLemmix have been updated - but if you have any unreleased work-in-progress styles, there's a tool to auto-update them attached to the 2nd post. For levels, we've got a new feature - "Cleanse Levels". This is activated by pressing F8 on a pack's title screen; this loads and re-saves a copy of every level in the pack. Cleansed copies of levels are saved in a "Cleanse" folder, they do not overwrite the originals. This isn't a blind "make a copy", but rather a load the level, then re-save it, so the output is completely up-to-date format-wise. Files other than levels are just directly copied, except for automating replacement of $RANK with $GROUP in levels.nxmi files. This can also be used as a way to mass convert old-formats or other engine levels, without having to build an NXP first. The engine retains full support for non-updated content for now, though this will be dropped in the future for styles (V12.10.0 most likely) - it will be kept as long as possible for levels and packs; while the editor does mostly support it, support on the editor side is not guaranteed and could be dropped at any time (including that some things might already not work) - if the editor doesn't seem to be loading a level properly, and that level was created before V12.7.0's release, run the level through Cleanse Levels before reporting a bug.

In short: Styles need to be updated before V12.10.0, but any included with NL are already updated. Levels don't need to be updated with any urgency for game compatibility, though may need to be updated for editor compatibility.

Editor-side, we've finally got talisman and preview / postview text editing in the level editor - a feature that's been sorely needed for a long time. Do note that the addition of these has broken the non-tabbed view, this will be fixed in a near-future update to the editor. We've also got much nicer handling of secondary animations now. Unfortunately, we still don't have proper alpha channel handling.

And of course, for both the engine and the editor, we've got plenty of bugfixes too.

Changelog (V12.7.0 -> V12.7.1) (click to show/hide)

Changelog (V12.7.1 -> V12.7.2) (click to show/hide)

Changelog (V12.7.2 -> V12.7.3) (click to show/hide)

Download: (Permalink to V12.7.3)
Styles: (Permalink to 2019-11-10)
Editor: (Permalink to V1.17)

Upgrade from earlier V12.7.X (stable only!) -> V12.7.3:

The styles must be downloaded in full when updating from V12.6.5 or earlier (or from V12.7.0-RC builds); there is no "upgrade" download.

It is VERY HIGHLY recommended that you create a new folder for V12.7.0 instead of using your existing folder when updating from V12.6.X. You can use the same folder if you're updating from a V12.7.0-RC build, but to be safe delete the "styles" folder first. You can copy the "settings", "music", "levels" and "replay" folders, and the "NLEditorSettings.ini" file, from your old folder if you like - those will work with the new version no problem. It's the "styles", "data" and "gfx" folders that should be cleaned out.

As usual - please report any bugs you find, with the new features or otherwise, in the Bugs & Suggestions board.

Closed / [SUG][PLAYER] Remove the "PANEL" keyword for info.nxmi files.
« on: November 04, 2019, 09:39:19 pm »
Currently, in order to use custom skill panel graphics, the pack's info.nxmi file must have a line "PANEL".

I don't see why this is necessary. If a custom graphic exists in the pack, use it; if it doesn't, fall back to default.

Is there anything I'm overlooking here?

To be very clear: I am not proposing that support for custom panel graphics should be removed. I'm proposing that content creators shouldn't need to include the "PANEL" line in the info.nxmi file in order to use custom panel graphics, and that NL should just use them if present.

Closed / [BUG][EDITOR] Non-tab view is really messed up
« on: November 03, 2019, 02:08:09 am »
GigaLem's screenshot from Discord illustrates this best:

Things are fine when using the tabbed option, but because I wasn't aware this option existed, I hadn't accounted for it at all, and the new tab seems to have messed things up.

This bug exists in V1.15 and above.

Closed / [DISC][STYLES] Pickup skill objects for initial V12.7 release
« on: November 03, 2019, 02:05:32 am »
Okay so - as everyone knows, custom pickup skills are gaining official support in V12.7, but this does mean every custom pickup skill object needs to be remade to fit the new system.

To avoid any glitchy or semi-incompatible pickup skills showing up, so far, my plan was that the styles download, upon V12.7's release, will have all the custom pickup skill objects outright removed. Yes, this will give "missing object" errors, but it will be pretty clear why, as opposed to the unpredictable results from non-updated ones.

However, in a discussion on Discord, IchoTolot made a suggestion to a user who didn't have their replacements ready: just use copies of the default one as placeholders for now.

How do people feel about this idea - instead of nuking the custom pickup skills, replacing them with copies of the default one as placeholders until the author submits a proper V12.7-ready copy?

NeoLemmix Main / Plans for V12.8.0
« on: October 29, 2019, 05:58:33 am »
With V12.7.0 more or less set in stone at this point, it's time to start thinking about what will happen in V12.8.0. As per the release schedule, V12.8.0 likely won't introduce or change any gameplay features (outside of bugfixes). Instead, the focus will be on cosmetic features.

The major feature I want to look at for V12.8.0, is a high-res mode. That aside, I'd also like to get some kind of online support back in place.

This aside, some of the minor things I'd like to consider if time / can-be-bothered-ness permits (and where applicable, there's enough support):
- Closing animations for limited-use entrances and exits
- Facing direction visibility for diggers and blockers
- Recoloring in certain cases of the time limit and lemming counts
- Slow motion mode - was added in a minor V12.7.X update
- Color-coding clear physics mode
- Improve the fall height ruler for climbers
- Outlining and possible recoloring of one-way arrows (Outlining confirmed, recoloring under discussion)
- Shimmier-walker-glider skill shadow

Closed / [SUG][EDITOR] Rename "To Front" / "To Back"
« on: October 28, 2019, 10:12:11 pm »
Quoting this from another topic sums it up best:

What I've never understood, both in Old and New Formats, is that the "to front" / "to back" feature works the other way round for objects as it does for terrain. Meaning: If you want an object in the very background (in this case: the updraft), you actually have to click "to front".

The issue here is perhaps that "back" and "front" aren't the best terms, and instead, "start" / "end" (of the piece list) would be more accurate. Pieces are drawn starting with the first piece in the list, then the 2nd, and so on. An "eraser" piece thus erases what's been drawn up to that point (but not anything drawn after it), and a "no overwrite" piece will be drawn behind (instead of in front of) all existing pieces - however, crucially, this doesn't change when the piece is drawn, just how it's drawn. Thus, a No Overwrite piece at the end of the list, will be drawn behind everything else (because the only thing that could get drawn behind that is another No Overwrite piece even later in the list).

Now, combine that with that objects generally have "No Overwrite" selected by default, and you see why these buttons seem to work backwards for objects - but they're actually doing exactly what they're meant to do, they just have a poor choice of name. And that's probably something that we should discuss fixing.

The question is, what would be better terms here, that are still short enough to fit on a clickable button?

We recently received a style submission. I will call this style "Style A". This style was created in old-formats by one author, and converted and submitted by a different author. This style in question was almost identical to "Style B", from the same author who created Style A (but Style B was submitted, a long time ago, by the author themself). I didn't compare the exact physics, but at a quick glance, it differs only slightly in terms of shading. On top of this, both of these are in turn just a derivative of Style C (which was among some of the first NL custom styles), by a different author altogether.

I feel that this is an excessive level of duplication. Style C vs Style B, there is some merit - while they're intended to be (though aren't always) physics-compatible, there's a significant difference in visual. As in, one is almost DOS-style, and the other is more full-color, modern style. However, A vs B is literally just a slight difference in brightness. As such, Style A was rejected from the download - it would have been utterly nonsensical IMO to accept Style A at the same time as we're removing orig_dirt_md.

My concern however, is that when I brought this to the attention of the user who converted and submitted Style A, they brought to my attention some other styles that are partial or wholly duplicates with recolorings, such as GigaLem's Xmas variants of ONML styles, or Mobius's "tancastle" style. To be fair - these are generally a lot more distinguished from the source styles than Style A and Style B were from each other; these two were so close that orig_dirt and orig_dirt_md were more different than these two were. But I also wonder if we really need even that - we're already dealing with a very over-bloated styles download, can we trim some of the fat? We currently have about 42MB of styles (to be fair, this also includes sound effects; but on the flipside, this is zipped size), consisting of a total of 166 styles.

Ideally, eventually NL will get back its download-on-demand features so new users will only have to download a few core styles (the official ones, probably including L2 / L3, and maybe some of the most commonly-used custom ones like the Lemmings Plus ones, the Lemmini Castle set, etc) and those that are rarely / never used will just sit on a server doing nothing instead of bloating the download / user folders. However, this is likely still quite some time away, and I think we need to do something in the meantime. I suspect that when Nepster made the call to start including all styles with NL's download, it was not envisioned that the number of styles available would explode like this - there were maybe 40 or so styles back then. (Indeed, if I'm being perfectly honest, the potential for this was a reason I was averse to moving to these kind of simple formats. Having somewhat of an effort-based barrier to entry helped keep the quantity down and the quality up; though it's undeniable that the flipside is true too, that there have been some excellent styles created that might not have happened under the more-difficult old-formats way of doing things.)

I have implemented a feature for the next update (V12.7.0-RC6 or V12.7.0-stable) that can be used to specify replacement pieces / styles for any removed ones - this can work either on the level of entire styles, or just single pieces (I've made use of the single-piece replacement feature to deal with a duplicate piece in one of my styles, for example).

Perhaps a good starting point is figuring out which of the current styles are actually used by anything. For example - GigaLem's Xmas variants of OhNo styles, I'm fairly sure the only use those saw was in Holiday GigaLems, which I don't believe GigaLem has any intention of bringing over to new-formats, so do we really need to keep the styles? Unfortunately though, unlike Lix, NL doesn't have a single central repository of levels, so every pack would need to be tracked down and checked to determine this. (It would also not be very practical to maintain a central repository, unless it's based on user-submission, in which case it likely won't catch every existing level.)

The alternative option may be to go back to how we used to do things - NL comes only with a few core styles, and users must download any extras on their own. Content authors would need to point out what styles are used in their packs, and ideally, where to get them. Downside of this, is that if someone's download link breaks, the style is lost, and all content that relied on it is broken. Also, we now have a whole bunch of content that uses a mix of "core" and "non-core" styles, and creators of this would need to go back and figure out what's included vs what needs to be downloaded.

Closed / [BUG][EDITOR-EXP] Loading old-format levels fails.
« on: October 23, 2019, 08:08:11 pm »
Tested on V1.15; may also be on V1.14 but not completely confirmed.

When trying to load an old-formats LVL file, nothing happens after selecting the file.

NeoLemmix Levels / "V12.7.0-RC or V12.6.5?"
« on: October 20, 2019, 06:13:56 pm »
This topic is now obsolete, as V12.7.0 has been released. Thus, target V12.7.0 in all cases.

I've seen people ask on a few cases whether they should release their pack for V12.6.5 or V12.7.0-RC. I want to have a clear post on the Levels board that answers this.

Firstly, a couple of things to make clear:
- If you don't expect to release your pack within the next 3 weeks or so, target V12.7.0-RC, because V12.7.0 stable should be released by the time your content is ready.
- I say these things as NL's developer, not as admin of the forums. Not following them could lead to your content being excluded from NL's installer / the included styles download until issues are resolved (I won't do this just to be spiteful, but I will do it to avert compatibility issues), but it will not lead to you facing any sanctions forum-wise.

That aside:
- Content that has been upgraded to V12.7.X is not compatible with V12.6.5, even if it only uses features that exist in V12.6.5
- On the other hand, content that targets V12.6.5 is 100% compatible with V12.7.X, but compatibility will break from V12.10.X onwards
- It is expected, but not completely guaranteed, that nothing further will change about formats between V12.7.0-RC and V12.7.0 stable - further changes would only be to fill in obvious oversights, fix typos, etc

V12.7.0-RC is not quite considered a "stable" version. RC versions should be thought of as "very close to, but not quite, stable". However, the usual advice is to target stable versions. If you release content using V12.6.5 now, it will work on V12.7.0-RC and on V12.7.X stable - it won't break until V12.10.0 (including any V12.10.0-RC builds).

Private releases on the other hand, since these are usually for testing purposes, should target whichever NL version your public release is intended to target (or the closest available version, so if you intend to target V12.7.0-stable, then your test version should target V12.7.0-RC).

Some edge cases:

- You want to release now and provide both a V12.6.5 version and a V12.7.0 version. This does offer a benefit: The V12.6.5 version can be played on a stable version of NL immediately; while the V12.7.0 version is more futureproof so if you were to leave the forums, it's already there and leaves your pack useable for V12.10.X and beyond. However, especially if you update often, I'd say this probably isn't worth the hassle unless you specifically expect to leave the forums in the near future.

- You want to release now, but your content uses features that don't exist in V12.6.5 such as neutral lemmings or antisplat pads. In this case, you really have no choice but to either delay the release, or release it for V12.7.0-RC. If you must do this, please make it very clearly visible in your release topic / post that your content requires V12.7.0-RC. Please also be aware that this would disqualify it from inclusion in the installer's list of downloadable packs (until V12.7.0-stable is released, at which point it can be included again), as the installer installs the latest stable version and any content it installs must be compatible with that.

Engine Bugs / Suggestions / [DISC.][PLAYER] High-res support
« on: October 08, 2019, 08:16:52 pm »
I'd like to look at implementing support for a high resolution mode in NeoLemmix. If not much else comes up, I might even make this a target feature to have for V12.8.X.

First - let's cover a few things that I'm not interested in arguing about, but will be "this is how it is - deal with it":
- There will be no separate high-res physics. Physics will remain unchanged. High-res mode will be a purely graphical matter.
- Custom styles will not be obliged to provide high-res graphics. It's purely optional.
- The feature will be intended for use for low vs high resolution, not for alternate skins. Technical and/or rejection-of-style-submission measures may be taken to enforce this.

WillLem has been working on some high-res lemming sprites that we can use. For the official styles, we can rip high-res graphics from an existing version that has them, such as WinLemm or Mac Lemmings.

Some things that I feel should be discussed:
- Should graphic sets remain required to provide low-res copies of graphics, or should it be acceptable to provide only high-res ones (and NL downscales these for players using low-res mode)? Or perhaps, should it be required for terrain (due to terrain directly impacting physics) but optional for everything else? (My thought: Downscaling is fine, as long as it's a custom-implemented algorithm and not reliant on the graphic library's downscaling algorithm.)
- If a user is playing in high-res mode and encounters a level that some / all components of don't have high-res versions, should NL fall back to low-res, or try to upscale the low-res pieces? (My thought: Upscale.)
- If a user is playing in high-res mode and specifically custom lemming sprites that are in use don't have high-res versions, what's preferable as a fallback: upscaling of the equivalent low-res sprites, or use of the default high-res sprites? (My thought: Again, upscale.)
- Is it important for the editor to support high-res mode? This would be a lot of work to implement. (My thought: No. Editor is fine to remain low-res.)

- Bug with backgrounds

NeoLemmix Main / NeoLemmix V12.7.0-RC release [V12.7.0-RC6 update]
« on: October 04, 2019, 07:48:17 pm »
At this point, the target date for V12.7.0 stable is November 9th.

The Release Candidate build for V12.7.0 is now here.

Known bugs / issues (click to show/hide)

Download V12.7.0-RC6:
If you have a previous V12.7.0-RC build, please delete the "styles" folder (make sure to back up any WIP styles that aren't in the standard download first!) before extracting this over the top of it.
The download includes the latest (V12.7-ready) editor, as well as the "Style127Fixer" tool which can be used to automate most of the style updating. However - unless you've got unreleased styles, you probably don't need to use this tool - all styles included in the download have already been updated.

If you have a custom hotkey setup you'd like to keep, run the new version once, then copy settings/hotkeys.ini across from your V12.6.5 folder; it's completely compatible with V12.7.0.

Please keep in mind that most content made for V12.7.0 will not be compatible with older releases. The exception is replay files; V12.7.0 replays will work fine with at least V12.6.5 (probably with any new-formats version, or at least any V12.6.X, but I make no guarantees beyond V12.6.5).

Changelog from V12.6.5 (click to show/hide)
Editor V1.15 changelog (click to show/hide)

I will stress again - levels saved in Editor V1.15 or higher will not be compatible with V12.6.5 or earlier. If you intend to release your content before V12.7.0's stable release, please continue using Editor V1.14 for now.

For upgrading content, please refer to the tutorials board posts on Level and Style formats, or to this topic:

The included "styles fixer" tool can be put inside a style's base folder and run, to quickly update the styles. This covers text file changes, as well as the "_mask.png" deprecation in lemming sprites.

Please report any bugs you find! One of the two major reasons for the RC build is to avoid the stable build needing several updates (like V12.6.X did). The other of course, is to give creators some time to get their content updated before the stable release hits, with a version that they can be fairly confident will have only the bare minimum necessary changes.

Pages: [1] 2 3 ... 42