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.

Messages - namida

Pages: 1 2 [3] 4 5 ... 636
NeoLemmix Main / Re: NeoLemmix V12.6.1 Release
« on: August 19, 2019, 08:03:36 pm »
I get the following message, when choosing a level:

That suggests you don't have the styles downloaded, or they're in the wrong place. Download the styles (linked in the first post), and extract them to your NeoLemmix folder. If done correctly, the main NeoLemmix folder will have two new folders in it: "styles" and "sounds".

Alternatively, you can use the NeoLemmix installer. Make sure to leave checked at least the boxes for "NeoLemmix" and "Styles"; up to you if you want the editor and some level packs too.

Level Design / Re: Defining the classic 10 skills
« on: August 19, 2019, 07:55:57 pm »
During the days of 9 NeoLemmix skills vs. 8 slots on the panel, I frequently used to drop the Disarmer - although, historically speaking, it would have to be the Fencer, because the Disarmer was indeed among the first 8 NeoLemmix skills to be introduced.

It's a little-known point that the Cloner is slightly younger than the other 7 original NeoLemmix skills. It came one version later than the rest of them. NeoLemmix wasn't very popular yet at this point - the only dedicated content for it was Lemmings Plus III, aside from that there were just unofficial conversions from Lemmix of the earlier Lemmings Plus packs, and conversions of the official games - so this fact generally flies under the radar. (Holiday Lemmings Plus came soon after, which made use of 7 of the skills. It wasn't until Lemmings Plus Omega that the Disarmer - or as it was known at the time, the "Mechanic" - saw use in a level that didn't specifically exist to show off the disarmer.)

Closed / Re: [SUG][PLAYER] Jump guide for Shimmiers?
« on: August 19, 2019, 07:53:11 pm »
That is an intended behaviour.

My question was simply about where to put that file - in this case, the L2_Highland.nxmi. That would still go into the l2_highland styles folder, wouldn't it?

Are you talking about the source colors, ie: the ones that identify "these are the colors to change from"? That goes in the scheme.nxmi file of the lemming sprites that are being recolored, in a new $COLOR_SWAPS section.

Are you talking about the target colors, ie: the ones that are changed to? That goes in the theme.nxtm file of the respective style, in the existing $COLORS section (just with new color names).

So, using the Highland example:

styles/default/lemmings/scheme.nxmi contains the $COLOR_SWAPS section from the above post
styles/l2_highland/theme.nxtm contains the $COLORS section from the above post - it already contains a $COLORS section in current versions (for eg. minimap, background, etc colors), but the new one has even more colors listed in it

In Development / Re: Lemmings Redux (new-formats): Coming soon!
« on: August 19, 2019, 07:06:39 am »
The traps will also be more visible thanks to secondary animations.

If the pack otherwise sticks to L1 skills, I'd say don't use the shimmier for a single level.

Re: Let's Go Camping, very few levels are still their original size. You may have a point in the context of the official game conversions, but for Redux, I don't think it's a problem.

I've already fixed an issue that's the likely cause of this, just haven't released the update yet. I should get that done.

Steps to reproduce:
1. Place a pickup skill, entrance or exit
2. Edit the skill count or lemming count by typing in a value (not by using the up/down clickable buttons or arrow keys)
3. Click in the level area such that the pickup skill / entrance / exit is de-selected

The change does not get applied, and an error message pops up.

Workaround: Click somewhere that doesn't deselect the object first. This could be another edit field (like the skill checkboxes), or clicking in the level area somewhere that doesn't deselect the object.

NeoLemmix Main / Re: Planning a schedule for future releases
« on: August 18, 2019, 10:35:26 pm »
The same rule will apply to any changes to physics, except where it's fixing bugs or edge cases in recently-introduced physics - these may come in the even-numbered updates (or if they're particularly urgent, even in a minor update).

To elaborate a bit on this, with some examples, let's say...

A new skill or not-purely-cosmetic object type is added. - This is a new physics feature, so it would need to come in an odd-numbered major update.
A decision is made that a certain skill will no longer be affected by blockers. - This is a change to a well-established detail of physics, so it would need to come in an odd-numbered major update.
An edge case is discovered with a newly-introduced skill where, under a very specific and obscure setup, something happens that seems illogical and it's decided to change it. - This is a change to a recently-introduced aspect of physics, but is not likely to have a significant impact for content so is not super-urgent to get fixed. It would be fixed in the next major update, whether that's odd or even numbered. Note that if the same thing happened with a skill that hasn't had physics adjustments in ages, it would likely be held back until an odd-numbered major update.
An edge case is discovered with a newly-introduced skill where, under a setup that's likely to occur very frequently, something happens that seems illogical and it's decided to change it. - This would very likely be a candidate for a minor update.
A serious glitch is discovered with a newly-introduced skill. - This will definitely call for a minor update to fix it.

For the avoidance of doubt, all of the above scenarios are examples only. In particular, no, there are no plans at this point in time to make the digger immune to blockers. (On the other hand, there are plans - eventually - to make it more visible when a digger gets affected by a blocker.)

NeoLemmix Main / Planning a schedule for future releases
« on: August 18, 2019, 10:04:08 pm »
Okay so - I'd like to get into a system of having a more structured release schedule, so content creators can have a better idea of whether it's worth waiting for a certain feature or whether it's better off to just go ahead without it for now, as well as plan for when they might need to make modifications to their content, and so on.

My initial proposal here, is that:
- Minor updates, eg. V12.6.0 to V12.6.1, are made as needed. These will generally only be for bugfixes, or to implement things that were really obvious oversights (such as the shimmier skill shadow).
- Experimentals for specific features are made and released as needed. These should generally be treated as "for testing / debug purposes; physics / etc may change, be very careful about creating content that relies on specific details". They'll also more often than not be closer to the previous stable release than they are to the upcoming new release, except that they include the specific experimental feature.
- Major updates, eg. V12.6.0 to V12.7.0, are made roughly three months apart from each other.
- Release candidates for each major update will be released about a month beforehand. This release candidate can be treated as "almost stable" - basically, no intention exists to make further significant changes, but it still might need more testing and bugfixes. You can use it for preparing your content for the update; just make sure to double-check the content when the stable release arrives. Basically - it's expected and intended, but not guaranteed, that anything that works in the release candidate will also work in the stable release. I will be using the name "release candidate" here to better distinguish it from the typical experimentals (as described above).
- Additionally, the even-numbered updates (V12.8.0, V12.10.0, etc) may only introduce new (or significantly changed) cosmetic or UI features. The same rule will apply to any changes to physics, except where it's fixing bugs or edge cases in recently-introduced physics - these may come in the even-numbered updates (or if they're particularly urgent, even in a minor update). The odd-numbered updates (V12.7.0, V12.9.0, etc) may introduce / significantly change both cosmetic and physics features. (Of course, I'm not going to change things just for the sake of doing so - they "may" have changes, not they "will" have changes.)

This means that cosmetic or UI additions / changes may occur every 3 months, while physics additions / changes will only occur every 6 months. Of course, these will be guidelines - if there's a really good reason to get a major release out more urgently, I'll do so. Or if there isn't enough new stuff to justify one, it might be longer until one occurs.

What do people think about the above ideas? (Maybe 3 months is too frequent...?)

Received some more replays; five backroutes - one of which was on what's probably the pack's most notorious level for backroutes so far, a late-Taxing level; and then two of which were different backroutes for the same level, an early-Mayhem one. Three of the affected levels (including both of the aforementioned ones) are fixed, but honestly, I'm having trouble seeing any way to fix the fourth - it may have to be replaced with an entirely new level. Fortunately, I've got a Mayhem-worthy idea ready if it comes to that. ;)

It's known that the editor does this - for the same reason you can create a 10-skills level using an older editor from before this feature was implemented. Not sure how feasible it is to check - keep in mind that the editor would have to also check every pickup skill to make sure of how many are being used, which would have to be checked every time a skill count is changed (or at least, every time it's changed between a zero and nonzero value). It might be simpler to just give a warning when saving.

It should be possible. The conversion formula is extremely simple - to convert one to the other, subtract it from 103 (this works for both directions). For example, RR 50 = SR (103 - 50) = SR 53. The question would be how easy it is to modify the editor's current code to add this option - I'd figure not too hard, but some parts of the editor that should be simple have managed to really confuse me at times.

Maybe we're thinking along different lines here. Let me explain in full how the new system works, then if your question isn't answered by this, please try rewording it as I'm not sure what else you might be asking?

Firstly - as mentioned above, if you have existing custom sprites, they will continue to work almost as-is. The only thing that you will need to change - and this will not need to be changed right away, I will leave backwards compatibility code in place for a few versions - is that if you make use of the "xxxxxx_mask.png" files (often used for destruction particles in particular), you'll need to replace this with acheiving the same effect via the recoloring feature. Likewise, new ones can be created in the same way, minus the change to how masking is done.

Lemming sprites can have (and in the case of "default" and "xmas", do have; for custom spritesets, it's up to creators if they want to add support) extra metadata in the scheme.nxmi file that allows them to be recolored. This data specifies a list of source colors, and their associated names. For example, a lemming's hair in the default sprites, without any recoloring, is (RGB hex) 00B000. So there'd be a line in styles/default/lemmings/scheme.nxmi: LEMMING_HAIR x00B000. (Note that the name "LEMMING_HAIR" is arbitrary here, I could have just as easily written "FLAPPY_BIRD x00B000" and it would work, as long as theme files trying to recolor it used the same name; but of course, meaningful and relevant names are a good idea.) These lines go inside a "$COLOR_SWAPS" section. (The name "$RECOLORING" was already in use for the conditional recolors, eg. athlete, zombie, etc colors.)

If a style's theme.nxtm points to "default" for lemming sprites, and doesn't specify any recoloring animation, it will still get the default sprites, as-is. But, style creators will likely already be familiar with specifying a few other colors in the "theme.nxtm" file, such as MASK, MINIMAP, etc. You simply specify lemming recoloring colors in exactly the same way.

For example - whereas currently l2_highland points to its own custom lemming sprites, in the next update it can have the following theme.nxmi file, which points to "default" for the actual sprites, but contains recoloring information:

L2_Highland's theme.nxmi (click to show/hide)

Remember, once again - the actual color names are arbitrary. If you're setting up recoloring with custom sprites, you can use any names you want; all that matters is that the same name is used in the source style's "scheme.nxmi" and the target style's "theme.nxtm". I could have instead used the name "BIG_DUCK" instead of "LEMMING_HAIR", and as long as that name was used on both sides (default's scheme.nxmi "$COLOR_SWAPS" section, and l2_highland's theme.nxtm "$COLORS" section), it would work.

In terms of replacing the "xxxxxx_mask.png" files - you'd copy/paste them onto the main graphic, in a unique color (perhaps death magenta, FF00FF). You'd then define a $COLOR_SWAPS entry for this color, using the name "MASK" - yes, you can use "standard" color names as part of this too, although MASK is probably the only one you should do so with (but maybe there's a creative idea I haven't thought of for doing this - at any rate, it would have been extra work to forbid it, so the option's there if anyone finds it to be useful).

So -
If you want a custom set that's just a recolor of default (or xmas) - for example, the L2 sets as they currently are in NL, or Arty's "underwater" or "silhouette" styles - you nuke your "lemmings" folder with the custom sprites, and use the above system instead. You don't need to change anything when a new skill (like the Jumper) gets introduced, because it's just based on recoloring the default ones - and it can easily recolor any new ones that get introduced too.
If you want a custom set that's actually custom - for example, GigaLem's Millas sets - you do things exactly the same way they're done now. The only difference would be that you get rid of the "_mask.png" files, and use recoloring to "MASK" in their place, as described above. Again, support for _mask.png files will be kept (but considered deprecated; so don't use it for any new content after V12.7.0's release) for a few versions to give people time to switch over - it doesn't cause much mess to the code to keep this in place, so it's no problem to do so for a little while.
If you want a base custom set with unique shapes, that's then recolored for several of your styles - my suggestion here would be to create a base style that just has lemming sprites, for example (if we were creating sprites that replaced the lemmings with ducks) you might call this "author_ducks_sprites". This would likely be a style consisting only of lemming sprites; it might not even have a theme file. You'd set up the $COLOR_SWAPS section as above for this style's sprites. Then in your other sets - "author_shadowducks", "author_egyptducks", etc, you'd point to "author_ducks_sprites" for lemming sprites, and specify recoloring in pretty much the same way you would when recoloring from default.

NeoLemmix Main / Re: NeoLemmix V12.6.1 Release
« on: August 18, 2019, 07:17:00 pm »
I prefer to avoid automatically downloading and installing the update, but old NL, when online features worked, was able to inform users that an update exists.

Closed / Re: [SUG][PLAYER] Jump guide for Shimmiers?
« on: August 18, 2019, 09:38:43 am »
Attachment says it all. ;)

Pages: 1 2 [3] 4 5 ... 636