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

NeoLemmix Main / NeoLemmix V12.7.0-RC release [V12.7.0-RC3 update]
« on: October 04, 2019, 07:48:17 pm »
The Release Candidate build for V12.7.0 is now here.

Known bugs (click to show/hide)

If you are downloading V12.7.0-RC for the first time, you need BOTH of these downloads. Only V12.7.0-RC1 has the styles and editor included; but V12.7.0-RC3 is the latest build.
Download initial V12.7.0-RC1 (includes styles, and editor V1.15):
Download update to V12.7.0-RC3:
(Update can be used from any previous V12.7.0-RC build.)

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

For everything below except custom pickup skills, you have until V12.10.0 to update (at which point non-updated content will no longer work) - but sooner rather than later is best! For custom pickup skills, please treat them as high priority - this should be the last time you need to update them, as they will now be officially supported and thus care will be taken to avoid breakages.

You'll be able to start updating in a couple of days when V12.7.0 RC is released. However, please wait for V12.7.0 Stable before publicly releasing your V12.7-ready content (you may, however, submit it to the styles download right away, to be released alongside V12.7.0 stable).

BACK UP YOUR FILES FIRST! Or even better, have them in version control (Git or similar).

Run all LRB replays, or any NXRP replays that predate new-formats, through the Replay Refresher tool. If you aren't sure if an NXRP replay is from old-formats or new-formats, run it through the refresher anyway - it won't hurt.

The Replay Refresher will also allow you to add your username to pre-V12.6.X replays when doing this.

NL V12.7.0 will have a "Cleanse Levels" feature. This essentially loads every level in a pack one by one, and saves a fresh copy of it to a separate folder. This copy will be completely up-to-date format-wise. Replace the existing level files with the newly-saved ones.

This goes for existing NXLV levels as well, right up to V12.6.5 levels. I've made some tweaks to tidy up the file format. However, note in particular - this is pretty much "last call" to get old-formats content converted. This is one last chance, that will update it directly to the latest version. If you do not get your old content converted before V12.10.0, do not expect any assistance to convert it in the future - you've had long enough now! Support for old-formats levels, as well as importing of levels from other engines (Lemmini, Lemmix, Lemmins) will all be dropped in V12.10.0!

You do not need to make any changes to files in a pack other than the level files.

If your style has been submitted to the NeoLemmix styles download by the time of this post, the V12.7.0 RC build will come with an updated copy of it.
If your style gets submitted to the NeoLemmix styles download between V12.7.0 RC and V12.7.0 stable's releases, it may be either V12.6.5-format or V12.7.0-format. In the former case, it will be updated for you.
Once V12.7.0 stable is released, all styles being submitted must be in V12.7.0 format, taking note of new deprecations / etc - any new submissions using deprecated features / formats will be rejected, as support for them is for backwards-compatibility, not for people who aren't keeping up to date.

Custom pickup skills are an exception to the above. These are simply going to be removed from the styles download altogether, as existing ones will be completely incompatible. Style creators may either choose to leave their styles without the custom pickups, or to submit new ones in their place. You are encouraged to make new ones that are name- and physics- compatible with the now-removed ones, so that existing levels will work again as soon as the pickup is reintroduced. To make sure it is properly updated: Create a level that has Walker, Shimmier and Cloner pickups, with at least one of them giving exactly 1 skill, and at least one of them giving more than 1 skill. Test this level in V12.7.0 (stable or RC). Make sure that all three display correctly. You may start submitting new / replacement custom pickup skills, in V12.7.0-format only, once V12.7.0 RC is released - custom pickup skills in V12.6.5-format will not be accepted and/or updated for you.

Custom lemming sprites are a partial exception to the above:
- The deprecation of the "_mask.png" files will be handled for you, either in the new styles download or by the automatic update app (as applicable).
- If your custom sprites are a direct recolor of the official ones, and are submitted to the styles download before 12.7's release (RC or stable), I'll handle porting them to the recoloring system; but if they do not get submitted by 12.7-stable's release, it will be up to you to do this yourself - the update tool will not be able to automate this part.
- If you have completely-custom sprites and you want them to be able to be recolorable like the official ones are, this is something you will need to do yourself in all cases.

I haven't conclusively narrowed down the cause of this, though I strongly believe it's related to groups only containing a single level. It may also relate to the final group in the overall loaded content (not just a single pack, but all content NL has loaded).

NeoLemmix Tutorials / Custom pickup skill objects in NL V12.7.0+
« on: September 28, 2019, 09:34:07 pm »
Please note that all images in this tutorial have been scaled up to 4x their actual size, and given a magenta (rather than transparent) background. This is for the purpose of clarity in the tutorial; and you should not 4x scale + magenta background the actual image files in your objects.

Finally, it is assumed that you're already familiar with custom objects in general, including the use of secondary animations. If not, please refer to the general information on style formats.

If you prefer to learn from examples than from reading a tutorial: Please look at of course default_pickup (you can more or less ignore the COLOR lines, they're there for the recoloring-in-different-themes feature that custom skills won't generally need), and there are also examples in namida_bridge, namida_basement and namida_garden - these examples don't do the recoloring, but do have other somewhat fancy effects.

NeoLemmix V12.7.0 adds official support for custom pickup skill objects. Yes, some have been created in the past, but this was done against heavy discouragement from NL's developers. However, 12.7.0 will officially support the use of custom pickup skill objects. This guide will explain how to create them.

First - why are custom pickup skill objects special, compared to any other object? It's because they need to have a graphic of the respective skill on them. Prior to NL 12.7.0, this meant that if any new skill was added - or even simply if the order of them were changed - NeoLemmix might display the wrong skill, or even crash, unless the pickup skill object had been updated to account for the change. Many pickup skill objects never got updated at all; while those that did generally lagged quite far behind the updates to NL themself.

To avoid this problem, custom pickup skill objects are implemented in a somewhat unique way, that removes the need for these kind of updates.

Here's an example of a custom pickup skill object, along with an explanation of how it works. Note that in many cases, you'll be able to use this as almost an exact copy-paste with your custom graphics substituted in (and maybe some tweaks to the primary animation's offsets and/or the trigger area).

Code: (pickup.nxmo) [Select]



  NAME skill_mask

  NAME active

  NAME inactive
    # "Don't hide" is implied.

pickup_skill_mask.png (click to show/hide)
pickup_active.png (click to show/hide)
pickup_inactive.png (click to show/hide)

Note that we have not supplied any image for the primary animation, nor any that contain the actual skill icons. These get generated automatically by NeoLemmix.

So, what does this combination of NXMO files and images actually do?

Just to clarify - the stuff at the top is just normal trigger area / effect data. If you don't understand how that works, please review the basics of custom objects.

First of all, let's talk about the "active" and "inactive" secondary animations, because they're the easiest ones to explain. There is nothing special whatsoever about these compared to any other secondary animation. The only thing that's of interest here is the particular effect being created with them - we've got one that's hidden when the pickup skill is not "exhausted", and one that's hidden when the pickup skill is "exhausted". This is in no way unique to pickup skills though - you can use this exact same setup on any object (provided "exhausted" has some meaning for that kind of object).

By specifying the name "*PICKUP"  for the primary animation, this tells NeoLemmix "don't try to load a file; auto-generate a primary animation for a pickup skill". Specifically, this is the animation it will generate:
This primary animation will always be 24x24 in size. For new objects, I recommend designing around that. However, in this case, this looks like a default pickup skill object, and might need compatibility - that's why, instead of moving the trigger area 6px right and 6px down, I've offset the primary animation in the opposite direction. The "OFFSET_X" and "OFFSET_Y" work exactly as normal here.

Note how there are two frames for each skill. The first frame is how the skill will be drawn after it's been picked up; the second is how it will be drawn before it's been picked up. Of course, you probably don't want these to be identical; and chances are you also need them to be cropped to fit your actual skill. Both of these are where the "skill_mask" animation comes into play.

The "skill_mask" animation must always be two vertically-arranged frames, 24x24 in size (per frame, so 24x48 for the whole image). These are used to erase the skill icons - the first frame erases the "picked up" graphic, the second frame erases the "not picked up" graphic. Often, the first frame will be a total erase, while the second will just crop the skill to fit your pickup skill object - but if you can find another way to use them that doesn't mislead the player, try it out!

We don't want this animation itself to actually show up as part of the object, which is why we just configure it as always hidden.

If you do not supply a "skill_mask" animation, NeoLemmix will fully erase the "picked up" frames, and leave the "not picked up" frames as-is, with no cropping / etc. I suspect there will be very few cases where this is visually desirable.

Visual example (click to show/hide)

Finally, let's look at the "DIGIT" parameters. These specify where to draw the skill count, in the case that the pickup skill object gives more than one skill. The default position, if nothing is specified, is centered above the object with a minimum length of 1 digit. The coordinates provided here instead place it right-aligned, in the bottom-right corner. In the case of pickup skills, if the skill quantity is 1 and the minimum digits length is 0, no number will be displayed. In all cases, no number will be displayed once the skill is picked up.

If you want to use outright custom graphics for your digits, you would supply these as a secondary animation with 10 frames called "DIGITS" that's always hidden, similar to how the "skill_mask" animation is. I do not have an example of this ready to show off.

Engine Bugs / Suggestions / [DISC.][PLAYER] Appearance of neutral lemmings
« on: September 27, 2019, 07:28:04 pm »
It just occurred to me that we've never actually discussed what neutral lemmings should look like. Current recoloring data has them drawing white / light-grey, actually looking pretty similar to how ghosts used to. But maybe something else is preferred - I notice IchoTolot thought yellow was a suitable color for the lemming count on the toolbar; this isn't a color I would've thought of, and I wonder if it might have come from an assumption the neutrals themself would be a similar color.

If anyone has any input here, fire away.

(Note: I won't delay the release candidate build for this. It's a purely visual detail, so it can be changed between RC and stable, or even in a styles update, if needed.)

Closed / [BUG][DEV-PLAYER] Neutral lemmings invisible in clear physics mode
« on: September 27, 2019, 12:43:46 am »
To check: What about other special states?

Engine Bugs / Suggestions / [SUG][PLAYER] Slow motion
« on: September 26, 2019, 11:40:01 pm »
We have fast forward to speed things up, but currently, no way to slow them down (other than outright pausing).

It would be very trivial to implement this. On the other hand though, I don't know if it'd be worthwhile even for a trivial feature, given that we have pause and framestepping anyway. But I'm open to implementing this if anyone thinks it'd be useful. (IchoTolot, for your solution videos, perhaps?)

I envision this being about 50% of normal speed, but other options can be considered for sure.

If the user has too few lemmings remaining to complete the level, then the lemming count should be recolored red to clearly indicate this.

Edge cases to consider:
- Cloners are left in the skillset
- Cloners are left in the skillset, but they cannot be used because only neutral lemmings remain
- Nuke has been activated, so no more lemmings will spawn

I'm not 100% sure if I've narrowed down the correct cause, but I think I have.

As of recent NL versions, in clear physics mode, objects are drawn in a solid, shifting color instead of their normal colors, to help them stand out more.

This works fine in all cases when unpaused. If you pause the game and then enter clear physics mode, this works fine. However, if you enter clear physics mode first, then pause the game, this is where it gets weird - the color doesn't update, until you advance a frame, at which point it suddenly jumps to whatever color it'd usually be at that time - but remains frozen on that one until you advance frames again. (In levels where scrolling is required, I suspect that scrolling would also have the same effect as frame-advancing if the high-quality minimap is not in use.)

If a skill is attempted to be assigned to a highlit lemming who cannot currently receive the skill, the assignment is discarded (unlike a regular assignment, which would get queued).

Closed / [DISCUSSION][PLAYER] Neutral lemmings vs nuke
« on: September 24, 2019, 08:08:10 pm »
This came up on Discord - for the upcoming neutral lemmings feature, how should they interact with the nuke?

The problem arises from this: Part of how neutrals work is that you shouldn't be able to directly make them do anything. (Of course, you can indirectly do so - they'll turn around at blockers still, for example, or you can modify the terrain to affect where they walk.) If the nuke affects them, this violates this rule, as you can now nuke them similarly to existing levels involving the nuke in the solution.

The obvious solution is "the nuke doesn't affect them, then". At least one user was opposed to this in and of itself - as the neutral lemmings are more of an ally than an enemy (unlike zombies), so should be included in the nuke. Aside from that, which is at least worthy of giving thought to; since the game should not terminate when only neutrals remain (as some of them may be able to walk to the exit still, despite no more regular lemmings existing), not including neutrals would have the effect that the nuke doesn't actually terminate gameplay on levels that include them.

It appears this is a situation where a special edge-case rule is needed. Two proposals have come up so far:

1. If only neutral lemmings remain and the nuke has been activated, gameplay terminates. This feels a bit rough (especially if the nuke is used with only neutrals remaining, in which case it would instantly exit the level), but does have the advantage of - as far as I can see - no unintended side effects.

2. The nuke affects neutral lemmings, but neutral lemmings do no damage when exploding. However, this still allows for very subtle ways of manipulating the neutral lemmings via this. The simplest setup would be to have a locked exit, which the neutral lemming will usually go past by the time it opens; however, them ohno'ing holds them in place until it opens, thus allowing them to exit through it. More complex setups could include avoiding a floater or updraft fall slowing via an ohnoer, or using the same kind of delay trick to drop a neutral lemming into a trap and thus allow a non-neutral (or just a different neutral) to pass. Giving neutrals immunity to objects after the nuke is activated - or perhaps, once they begin ohno'ing - avoids this, but then gives rise to the opposite issue - what if there's just a traditional "group up and nuke 'em" level but includes some neutrals, should they not be able to exit along with the regular lemmings that would do so here?

Given the side effects of option #2, and that any mitigation of them just raises new side effects, I want to say I'm leaning more towards option #1 - but let's see what everyone else thinks.

Closed / [BUG][PLAYER] A few bugs in test play mode.
« on: September 09, 2019, 06:09:49 pm »
Gonna keep these all in one place until I actually look into them and figure out how related they are or aren't.

All of these are discovered in current development source code, and may or may not apply to the stable version. None are critical though.

Bug 1 - It's still possible to open the level select menu at certain points during testplay mode. For example, at the preview screen.

Bug 2 - Using testplay mode appears to overwrite the last played level, meaning NL forgets next time it's run. This may be a side effect of invoking bug #1, I haven't looked in isolation to see if it occurs even without invoking #1.

Bug 3 - If you play a level in standard mode, exit NeoLemmix (so that this level is the "last level played"), then delete or rename its level file (even if the levels.nxmi files are updated accordingly, where applicable), then run NeoLemmix in test mode, you get an error message popping up before NL starts (however, it still runs as normal once the error is dismissed, as far as I can tell). This doesn't happen when running NL in standard mode.

Closed / [BUG][PLAYER][DEV] Inconsistent results from replay checker
« on: September 07, 2019, 09:13:07 pm »
This bug only seems to apply to the current in-development source code. I cannot reproduce this issue on the current stable version.

If I run a replay test without playing any level first, I get different results than if I play a level and then run the test. So far I have only confirmed this on Doomsday Lemmings, specifically the ready-for-V12.7.0 version, which means it's possible this is related to zombies. It could also be related to preplaced lemmings, as Doomsday Lemmings makes very heavy use of those.

To clarify around the release candidate build: You can use the release candidate build, once released, to create your new custom pickup skill objects. You do not have to wait for the stable release before submitting them - you may submit them during the RC phase, to be included with the initial V12.7.0 stable release. If you wait until after the stable release to submit them, they will get included in the December styles update.

Custom pickup skill objects are not officially supported, and a decision has been made not to accept any new ones until official support for them is added, which will be happening in the next major update, V12.7.0, which will release sometime in November.

Existing ones may be updated - and except for two in Plom's styles, I believe all existing custom pickup skill graphics still need to be!

No ifs, ands or buts - if your custom pickup skill object does not already exist in the NL styles download, it will not be added to the NL styles download, full stop. Do not create such objects. If you want to do something with custom pickup skill objects now, update your existing ones. I should be releasing a V12.7.0 Release Candidate build in about a month, at which point you can start preparing for V12.7.0's pickup skill system - and that should end up being the last time you need to update them, as the whole point of it is to make it so you can use custom pickups without having to update them all the time.

Additionally, I find it especially bothering that one author created a whole bunch of new ones - some for entirely new styles, some as the only new piece added to existing styles - yet hasn't done anything to update their existing ones that need it. When you do this with your own level packs, whatever, that's your choice. But when it comes to styles, which other people may be relying on, I think it's a completely fair expectation that if you have time to create new styles, you have time to maintain your existing ones at least to the extent that they don't end up not working and/or giving false information to the player.

Pages: [1] 2 3 ... 42