I can see logic behing both methods:

- ASAP change is logical in the sense that RR change is imminent, but.....

- Change with the next spawning Lemming is also logical: The RR count counts not for the current spawning Lemming, but for the next spawning Lemming ----> changing it will change the rate with the the next spawning Lemming.

Also the handling of Lemming bunches is a lot better to handle this way....
EXAMPLE:
Say that you want an exactly 1RR gap and then change immidiatly to 99RR for compression....with the change with the next spawning Lemming there is zero problem to do this exactly.
With immidiate change little unpricise stituations can accour more easily....you must wait until the second Lemming spawns or you won't have an exact 1RR size gap...then turning it to 99RR will likely have a little gap (a few frames) between Lem 2 and 3, because you change it after Lem 2 and not in advance.
Also to do this as good as it gets, there is the precise moment for turning it up RIGHT AFTER the 2nd Lem, where the Change with the next spawning Lemming method leaves the whole 1RR gap to react.
-----> less precision for levels with sharp RR change timings and this is always good

So as I went from Lemmini to NL together with the change of the imminent RR change to the Change with the next spawning Lemming method, I was also a bit sceptical at first, but now as I have played lots of NL now... I see the advantage of the NL RR change!


Also: Now all replays have been made with this method and maybe this change would affect them (I have no motivation of checking+redoing quite a lot of replays ). Furthermore every player have gotten used to it by now

To end my statement: I prefer the current implementation of the RR, because of the lesser precision needed + getting more precision out of it.

Completed the pack (V2) and I must say it's one of my favorites

A lot of levels of the last 2 ranks really had my brain smoking really hard

Added a link in the description (2.) Installation) to Nepsters manual

I've implemented some changes to this; probably not to the full extent that could be done, but it will have to do for now (as the priority detection code needs major overhauling at some stage anyway, so I don't want to do too much quick-fixing in it).

Basically - I've made it so that if a lemming is in a state from which it cannot perform a skill, it will be de-prioritized (but not entirely unselectable) if that skill is selected. For example, if you have the Glider skill selected, Floaters and Gliders will be deprioritized; if you have the Builder skill selected, builders, blockers, ohnoers, etc will be deprioritized.

This also extends to a few cases that aren't strictly speaking a matter of can't be assigned, but not very logical to do so - for example, you technically can assign the Swimmer or Disarmer skill to a ghost, but there's not much use in doing so, so they'll be deprioritized.

One side effect is that this priority change based on selected skill applies even to things where the selected skill is irrelevant, such as highlighting a lemming. For now, I'm not worried about this; if people report that it's problematic, I'll do something about it.

I've uploaded a new experimental version that contains this modified prioritization behaviour.

I'll leave this topic open for further discussion on this matter.

This sounds excellent!     Catching lemming bunches with floaters will finally be easy

hmm...  to take into acc here, is that it needs to turn back, if pickups are included in the level. In a lot of level with pickup skills you can have 0 skills at all and after some time pick up new skills.

Also got Win 7 and nope. Everything fine here either.

Editor V1.38n-B added. Most significant change is it (finally) confirms when exiting if you want to save the level, if it isn't already saved. (This also applies to closing the level, opening a different level, or creating a new level, of course.)

As usual, links are in the first post.

Update causes a bug:
Can't open levels that are not in the same folder as the editor, because the editor searches for the tilesets at the position of the level and not the editor.

So it looks for the tilesets at:      Place of the level\styles\NeoLemmix\tileset.dat
If it isn't located there ---> error