Lemmings Forums

NeoLemmix => Bugs & Suggestions => Closed => Topic started by: namida on March 06, 2016, 08:30:56 AM

Title: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 06, 2016, 08:30:56 AM

So - in the interest of getting as much physics changes as possible done in a single hit - I think a good place to start is with  the question:

When should we be able to assign which skills?

Currently, the detection for this is quite a mess, for sure. However, we'll leave it to me on tidying up how it works behind the scenes, and focus more on the end results - what should or shouldn't be possible to do? We also won't worry about what exactly happens when the skill is assigned for now - just whether it can be assigned or not.

Let's look at what current checks are applied to assigning the various skills. Note that everything mentioned here is based off the code with gimmicks (except zombies) removed.

General (click to show/hide)

In general, the approach when a skill assignment is attempted is:
1. First, find two lemmings (Lemming1 and Lemming2) - this will generally be the highest-priority and second-highest-priority lemming. Which lemmings are eligible (and prioritized or deprioritized) may be modified by things such as directional select; we will leave /that/ for another discussion.
2. If one of the two lemmings is a zombie, change the marked lemmings so that both Lemming1 and Lemming2 point to the non-zombie. (If both are zombies, stop trying to assign the skill.
3. If both lemmings are zombies, the assignment fails altogether.
4. Proceed to the skill-specific assignment code.

Note: Not all skill-specific code does actually check Lemming2. It will be specifically mentioned if it does.

Note: All skills also (obviously) have a check "does the remaining skillset have at least 1 of the skill being assigned". I won't specifically mention this during the steps.

Walker (click to show/hide)

1. Mark Lemming1 as "SelectedLemming" if it is currently performing one of these actions: Walking, Shrugging, Blocking, Platforming, Building, Stacking, Bashing, Mining, Digging.
2. If Lemming1 was not doing one of those, and Lemming2 is, mark Lemming2 as "SelectedLemming".
3. If we have a SelectedLemming, assigning Walker to it succeeds.

Permanent Skills (Climber, Swimmer, Floater, Glider, Disarmer) (click to show/hide)

1. Check that Lemming1 doesn't already have the skill in question. If the skill in question is Floater or Glider, check it doesn't have the other one of those two either.
2. Check that Lemming1 is not performing one of these actions: Ohnoing, Exploding, Drowning, Burning, Splatting, Exiting. (Exception: Drowning is not checked for assigning Swimmer)
3. If both of the above checks passed, assigning the permanent skill to Lemming1 succeeds.

Bug noticed when writing topic: The "Exploding" state is only checked for in a Bomber explosion, not a Stoner explosion. The "Ohnoing" state is correctly checked for both skills.

Bomber, Stoner (click to show/hide)

1. Check that Lemming1 is not performing one of these actions: Ohnoing, Exploding, Drowning, Burning, Splatting, Exiting.
2. If the above check passed, assigning Bomber / Stoner to Lemming1 succeeds.

Bug noticed when writing topic: Like with the permanent skills, the "Exploding" state is only properly checked for with Bomber explosions. This one is more noticable - try assigning a Bomber or another Stoner, to a Stoner, on the exact frame of the explosion (click in the upper-left corner of the explosion graphic when assigning).

Blocker (click to show/hide)

1. Check that Lemming1 is performing one of these actions: Walking, Shrugging, Platforming, Building, Stacking, Bashing, Mining, Digging.
2. Check that no blocker field already exists at Lemming1's position.
3. If both of the above checks passed, assigning Blocker to Lemming1 succeeds.

Platformer (click to show/hide)

1. Check that Lemming1 is performing one of these actions: Walking, Shrugging, Building, Stacking, Bashing, Mining, Digging.
2. Check that at least one pixel in the area the first brick would cover is currently non-solid and so are the two pixels immediately above the 2nd and 3rd pixels of the brick (relative to the lemming's position / direction).
3. If these checks fail for Lemming1, perform them for Lemming2.
4. Whichever lemming (if either) they succeeded for first, gets successfully assigned Platformer.

Builder, Stacker (click to show/hide)

1. Check that Lemming1 is performing one of these actions: Walking, Shrugging, Platforming, Bashing, Mining, Digging, or whichever one out of Building / Stacking is not currently being assigned.
2. If that check fails for Lemming1, perform it for Lemming2.
3. Whichever lemming (if either) passed the check is successfully assigned Builder.

Basher (click to show/hide)

1. Check that Lemming1 is performing one of these actions: Walking, Shrugging, Platforming, Building, Stacking, Mining, Digging.
2. If that failed, check if Lemming2 is. Whichever lemming it passed for (if any) is now "SelectedLemming".
3. If the pixel at 4 pixels in front of SelectedLemming and 5 pixels above SelectedLemming (by foot position) is steel or an incorrect one way, the assign fails (in the case of steel, a sound is also played).
4. If all of the above passed, SelectedLemming is successfully assigned a basher.

I know the steel check is weird. It's mostly a carry-over from vanilla Lemmix and probably needs improvement. The check during the actual bashing action is, IIRC, much better.

Miner (click to show/hide)

1. Check that Lemming1 is performing one of these actions: Walking, Shrugging, Platforming, Building, Stacking, Bashing, Digging.
2. If that failed, check if Lemming2 is. Whichever lemming it passed for (if any) is now "SelectedLemming".
3. If the pixel where SelectedLemming is standing is steel, the assign fails (a sound is played).
4. If the pixel 4 pixels in front and 5 above (like with the basher's checks) is an incorrect one way (but NOT if it's steel), the assign fails.
5. If all of the above passed, SelectedLemming is successfully assigned a digger.

And you thought the basher's checks were weird...

Digger (click to show/hide)

1. If the pixel where Lemming1 is standing is steel, the assignment fails (no sound is played this time).
2. Check if Lemming1 is performing one of these actions: Walking, Shrugging, Platforming, Building, Stacking, Bashing, Mining.
3. If that failed, check if Lemming2 is performing one of those actions and not standing on steel.
4. Whichever lemming the checks succeeded for becomes a digger successfully.

No, you're not interpreting that wrong. If Lemming1 is standing on steel, then the assignment will fail for Lemming2 too, even if Lemming2 isn't standing on steel. However, while these false negatives can occur, false positives cannot (as far as I can tell) - the assignment will never succeed on a lemming that is standing on steel. My only guess as to why is that it's something that slipped through from vanilla Lemmix, and since it's so obscure, never got noticed.

Cloner (click to show/hide)

1. Check if Lemming1 is performing one of these actions: Walking, Shrugging, Platforming, Building, Stacking, Bashing, Mining, Digging, Jumping, Falling, Floating, Swimming, Gliding, Fixing.
2. If not, check if Lemming2 is.
3. Whichever the checks succeeded for first, the Cloner gets assigned successfully to that lemming.

I could swear I remember making it impossible to assign a Cloner to a Digger too, but the current code - and indeed, the results from testing the latest version - contradict that.

There's some areas where there's obvious room for improvement - the first of course being fixing the bugs with permanent skills / bombers / stoners assigning to in-explosion stoners - but I'd also like to get input from anyone else who has ideas too. Fire away! :)

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 06, 2016, 08:31:02 AM

Proposed changes:

General (click to show/hide)

(None)

Walker (click to show/hide)

(None)

Permanent Skills (click to show/hide)

1. Fix the bug which allows assignment to Stoners during the explosion frame.

Bomber, Stoner (click to show/hide)

1. Fix the bug which allows assignment to Stoners during the explosion frame.

Blocker (click to show/hide)

(None)

Platformer (click to show/hide)

(None)

Builder, Stacker (click to show/hide)

(None)

Basher (click to show/hide)

(None)

Miner (click to show/hide)

(None)

Digger (click to show/hide)

(None)

Cloner (click to show/hide)

(None)

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 06, 2016, 11:43:19 AM

As weird as the checks may seem sometimes ---- they work and I don't find any of the behaviors problematic.

There is probably a lot of tidying up to do there to make the code more cleaner, but as you said that's your buisness ;)

And as I don't find any of the behaviors problematic, aside from little bugs as the cloner-platformer case and maybe some smaller things with no really big impact (like changing a assign priority): I say leave it as it is. Never change a running system :8():

Also I get really sick if I think about the consequences for already existing content (broken levels + creating new backroutes) and replays if I think about what could change here :sick::sick:

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 06, 2016, 11:52:03 AM

Quote

maybe some smaller things with no really big impact (like changing a assign priority)

Priority should be purely a UI thing. The ideal rule is - whether or not a skill can be assigned to a given lemming should not depend on whether or not (or how many) any other lemmings are near him at the time. Although perhaps sometimes complex, this is already possible in virtually any situation by using highlight.

Quote

Also I get really sick if I think about the consequences for already existing content (broken levels + creating new backroutes) and replays if I think about what could change here :sick::sick:

Yeah, I know. That's the reasoning behind wanting to do as many changes as possible at the same time, to avoid the situation we had in the early days where every update changed physics somehow. Chances are there are things that need to change, and will only be uncovered by a close look at the code (the Stoner -> permanent skill / Bomber / Stoner bug being a prime example). There's probably the odd case that doesn't make sense too, or is inconsistent.

Some things in particular that stand out are - the basher's check for steel / one-way walls. Although this is one pixel the basher checks during the actual action, it's only one of many - should we not either check all (or at least most, perhaps?) of them, or not check any at all and instead let the skill be assigned then stop on the first stroke? Likewise, the miner checks for steel and one way don't even check the same place as each other; and neither of these positions is actually checked during the miner's action. (The digger on the other hand is pretty consistent with the terrain checks during the actual digging action.)

Another one is the Platformer's extra checks compared to the Builder and Stacker. Should it really have those? I remember the reason I put them there was to avoid platforming in a position where nothing would be placed, thus resulting in turning around, but at the same time - we certianly don't prevent a Builder or Stacker assignment in such a case.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 06, 2016, 01:36:14 PM

Quote from: namida on March 06, 2016, 11:52:03 AM

Another one is the Platformer's extra checks compared to the Builder and Stacker. Should it really have those? I remember the reason I put them there was to avoid platforming in a position where nothing would be placed, thus resulting in turning around, but at the same time - we certianly don't prevent a Builder or Stacker assignment in such a case.

Well the builder always has sth to place, as the Lemming can simply be at this place. The platformer on the other hand places sth under the Lemming, where it often cannot be there.
If we allow a platformer to place a brick where it would not place anything we would have another walker type skill. So giving the player platformers will be extremely more dangerous as it has now a big backroute potential.
There is a big difference between placing builder/platformer bricks! So the "inconsistancy" makes sense here -- to avoid the platformer beeing just another walker. With the builder you cannot easily avoid this + it actually places sth.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Nepster on March 06, 2016, 02:11:45 PM

Quote from: IchoTolot on March 06, 2016, 11:43:19 AM

Also I get really sick if I think about the consequences for already existing content (broken levels + creating new backroutes) and replays if I think about what could change here :sick::sick:

I agree that we should try to keep the current checks if possible.

However there are a few more things we might consider in order to simplify skill assignments:

1) Instead of having only two lemmings, loop through all lemmings under the cursor
The algorithm would be something like: Get list of all lemmings under cursor (ordered by priority; modified by only-right, etc.). Then go through all lemmings and check whether one can give them the skill, until one has found one such lemming or the list runs out.
The reason for this suggestion is, that currently spamming builders, bashers, ... can only be done with priority-invert. The above would make this easier.

2) Ease skill assignment on steep slopes
Problem: On steep slopes the lemmings are most of the time a jumper or a faller, hence cannot be assigned most non-permanent skills.
2a) Downwards slopes
Here the skill assignment would have to be remembered for two frames (or so). If during this time, the lemming hits terrain again, he would start with the skill.
I am not sure how hard it is to implement such a thing with the current code.
2b) Upwards slopes
The algorithm would be somthing like: If a jumper gets assigned a non-permanent skill, he drops instantly back to the bottom and there starts with the work.
Unfortunately this might have some unwanted consequences:
- The skill assignement can be delayed for two more frames.
- Depending on the precise terrain layout, the drop back to the bottom, might find another different bottom and not the original one. Perhaps one can compute the original position from the frame number of the jumper animation?

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Proxima on March 06, 2016, 02:17:43 PM

Why the asymmetry? Why not say that if a jumper is assigned a non-permanent, he starts to carry it out at the first opportunity, i.e. at the top of his jump?

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 06, 2016, 02:25:02 PM

Quote from: Proxima on March 06, 2016, 02:17:43 PM

Why the asymmetry? Why not say that if a jumper is assigned a non-permanent, he starts to carry it out at the first opportunity, i.e. at the top of his jump?

I think this would be the best solution :)   
Assigning at steep slopes was a nightmare in Lemmini without skipping backwards and i often thought: Why couldn't the jumper simply perform the task when he's able to do so again.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 06, 2016, 02:27:04 PM

Quote

1) Instead of having only two lemmings, loop through all lemmings under the cursor
The algorithm would be something like: Get list of all lemmings under cursor (ordered by priority; modified by only-right, etc.). Then go through all lemmings and check whether one can give them the skill, until one has found one such lemming or the list runs out.
The reason for this suggestion is, that currently spamming builders, bashers, ... can only be done with priority-invert. The above would make this easier.

Agreed that this makes sense, although priority invert is not really nessecary for this - if, for example, you're trying to assign builder, any lemmings that are already builders are de-prioritized (as of V1.39n). So it's very unlikely that they'll become Lemming1 or Lemming2, unless there aren't enough lemmings to choose from. Still, this is indeed not an ideal way to handle it, and is mostly a matter of "this is how Lemmix does it, and it hasn't been changed".

Quote

2) Ease skill assignment on steep slopes
...

I'm not so sure about this one, especially the instant-drop-and-perform. If anything, I prefer Proxima's suggestion here, but I'm not sure about this as a whole, especially given that we do have frame-by-frame control. It should also be considered that currently (by design), it is impossible to assign more than one skill in a single frame (now whether or not it should stay that way is another matter); the suggestion of delaying the assignment rather than preventing it leads to another situation that has to be examined, and could possibly lead to unexpected behaviour.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Nepster on March 06, 2016, 02:31:12 PM

Quote from: Proxima on March 06, 2016, 02:17:43 PM

Why the asymmetry? Why not say that if a jumper is assigned a non-permanent, he starts to carry it out at the first opportunity, i.e. at the top of his jump?

Good question. I just thought first about upwards slopes, where the idea was to start the skill as soon as possible. But your suggestion is probably better and easier to understand for new players.

Quote

It should also be considered that currently (by design), it is impossible to assign more than one skill in a single frame (now whether or not it should stay that way is another matter)

Apply the same algorithm that you already have for the case that the player and the replay want to assign skills during the same frame, i.e. prioritize new assignments.

Edit: Remove incorrect parts. Thanks namida.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 06, 2016, 03:17:01 PM

Quote

Apply the same algorithm that you already have for the case that the player and the replay want to assign skills during the same frame, i.e. prioritize new assignments.

The opposite actually - the already-existing assignment is prioritized. This has been criticized (http://www.lemmingsforums.net/index.php?topic=2509.0), but won't be changable without some major overhauling. Which is something that's ideal to do after any physics changes have been, at the very least, decided on.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 09, 2016, 11:30:31 PM

So, I think the questions that remain at this stage:

1. Should a change be made in regards to assigning skills to jumpers? I'm not sure about the whole thing of delaying it, but a more-radical but perhaps practical idea - should we simply allow most (if not all) skills to be assigned to them just like it would be with walkers (subject to other conditions that are usually required for the skill)?
I think for this one, rather than discuss it theoretically, I should upload a modified version that allows this so it can be tested in practical situations. I'll do this later today.

2. Should the one-assignment-per-frame limitation be kept?

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Simon on March 09, 2016, 11:57:27 PM

About (1): Queuing skills are executed at what time? Do you want to allow transistions that are impossible right now?

When a jumper finishes jumping, and would become walker, will he start working instead? When (1) is not implemented, the earliest you can click the jumper is after becoming walker. Then he starts working one frame later than what (1) implies.

I don't want to decide whether (1) is good. Framestepping makes queuing less urgent. Queuing can be useful with many skills, it's not jumper-exclusive.

About (2): If you implement (1), we have to redefine what an assignment is before answering (2). Is an assignment the act of queuing, or is it the queued transistion later?

You advance physics when assigning during pause. This is good from a UI standpoint, because the assignment is carried out immediately, giving maximum feedback for the click. When you want to allow multiple assignments, should we advance (then how to assign several skills?), not advance (skimping on great feedback), or have extra UI to choose the behavior during play (feature bloat, undiscoverable keys, etc.)?

-- Simon

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: ccexplore on March 10, 2016, 01:04:05 AM

Perhaps instead of tackling through queueing assignments, the game could provide some form of "smart frame advance" that advances time until, say, the selected lemming underwent certain kinds of transition like landing or finishing a jump.  Though it does feel like too much effort for something that usually can be achieved manually with a small series of forward and backward steps.

I do want to point out that another compelling case for queueing would be for skills like builders and platformers, specifically being able to tell the lemming to build several times on the outset rather than having to keep watch to assign the next one.  Maybe this already exists in NeoLemmix but if not, it's worth considering.  This is not really about game mechanics though, it's really a UI feature around skill assignments.

Finally, I'm sure Simon knows this already, but advancing physics is not the only way to provide visual feedback about a skill assignment.  I think Lix's "skill assignment bubbles" may have an excellent use case here for multiple assignments per frame.  The discussion around multiple assignments per frame should be more about pros and cons as regards to level solving and designing.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 10, 2016, 01:53:08 AM

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

Re 2, let's decide whether to allow it at all first. Then we can consider visual feedback etc.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Proxima on March 10, 2016, 02:08:06 AM

Quote from: namida on March 10, 2016, 01:53:08 AM

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

In mid-air? That just sounds really weird.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 10, 2016, 02:30:18 AM

He's not really midair, more on the side of a slope - essentially, the logic here is to think of the jumper as just an extension of the walker.

Here's an experimental version that implements this change:
https://www.dropbox.com/s/py0b8txofap3vip/NeoLemmix_V1.44n_1603101522.exe

(Note: When loading any NXP, you'll get a warning that it may be incompatible. As long as it doesn't use gimmicks, secret level triggers, or non-standard teleporters, you can ignore this warning.)

In this test version, Walker, Blocker, Platformer, Builder, Platformer, Stacker, Basher, Miner and Digger can be assigned to jumpers, provided all other conditions usually required to assign them are met.

So, let me know whether you think this change should be kept, or dropped.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: ccexplore on March 10, 2016, 05:20:01 AM

Quote from: namida on March 10, 2016, 01:53:08 AM

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

Nepster mentioned downward slopes as well, for which jumpers are not applicable.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 10, 2016, 10:39:05 AM

I sense a big backroute potential in this experimental version. Through this skills can be assigned at new (not originally intended) heights.
But i cannot proof it without testing 1000 different scenarios for hours + having other testers run through it again. But beeing in the heat of of finding a solution to a level you will use this to fiddle sth out that works but is not intented for sure.
Also performing a task while mid jump still seems very weird und unlogical.

If this is dropped again it wouldn't be a huge miss either, because of already existing frame forwards/backwards.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 10, 2016, 11:13:32 AM

Quote from: ccexplore on March 10, 2016, 05:20:01 AM

Quote from: namida on March 10, 2016, 01:53:08 AM

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

Nepster mentioned downward slopes as well, for which jumpers are not applicable.

That's a good point. Assignment to fallers is much more game-breaking than assignment to jumpers...

Quote from: IchoTolot on March 10, 2016, 10:39:05 AM

I sense a big backroute potential in this experimental version. Through this skills can be assigned at new (not originally intended) heights.
But i cannot proof it without testing 1000 different scenarios for hours + having other testers run through it again. But beeing in the heat of of finding a solution to a level you will use this to fiddle sth out that works but is not intented for sure.
Also performing a task while mid jump still seems very weird und unlogical.

If this is dropped again it wouldn't be a huge miss either, because of already existing frame forwards/backwards.

It's very much an experimental feature at this stage. If it's not liked - which it doesn't seem to be - I just drop the branch that has the code for it, and we never see skills assigned to jumpers again (except those which have always been possible to assign to jumpers - the permanent skills, plus Bomber and Stoner).

Are there many levels which rely on a jump to avoid a backroute? I can't think of many; I can think of more cases of the opposite to be honest (avoid jumps in order to avoid backroutes - usually via building against the terrain that would otherwise result in a jump).

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Nepster on March 10, 2016, 05:57:06 PM

Quote from: namida on March 10, 2016, 01:53:08 AM

Re 1, my proposal was to no longer disallow assignment to jumpers in the first place. ie. if you click a jumper with Builder selected, he immediately starts building just like a walker would.

This is a very bad idea due to the reasons ccexplore (no improvement for downwards slopes) and IchoTolot (more backroutes) mentioned. Moreover allowing to start builders, platformers and especially stackers mid-jump has the potential for lots of incredibly annoying tricks/glitches (I can provide example levels if needed). I would rather keep the old handling than allowing to start skills at some intermediate height.

Perhaps I should have given more background on the reason, why I made this suggestion in the first place:
When already pausing, the frame advance options are already good enough so that further improvements are not really needed. But when I play an easy level where it doesn't really matter where I assign a basher/builder/whatever, I just want to assign the skill. Currently I have to pause the game for this (or hope to be lucky), which I find dissatisfactory. Even if there is no big slope, but only some bumpy terrain (grass in the Dirt style or on rocks in the Rock style) it sometimes happens that a skill doesn't get assigned, due to unlucky timing. When this happens during fast forward or when I press 10sec-skip directly afterwards (without double-checking the assignment), it is very annoying.
So I definitely don't want to add new positions where non-permanent skills can be started, but only ensure that those unlucky skill assignments will still be executed at the earliest moment, when such assignments are regularly allowed.

Quote

Assignment to fallers is much more game-breaking than assignment to jumpers...

That is the reason why I suggested to remember the skill assignment for a few frames until the lemming reaches again solid ground, where he can regularly start working.

Quote from: namida on March 09, 2016, 11:30:31 PM

2. Should the one-assignment-per-frame limitation be kept?

I would put removing this limitation as [LOW-PRIORITY]. While it would be nice to remove the problems with colliding assignments from player and replay, it is not really game-breaking. I cannot think of any (non-artificial) level, where changes here create new backroutes.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 15, 2016, 11:11:48 AM

Here's another question which a recent post raised: Miners on wrong one-ways.

Currently it is possible to assign a miner when they're standing on a wrong-direction one way wall. The result is that they take a swipe, remove no terrain, and turn around.

Compare this to the following cases (which themself may definitely be questioned too):
a) Basher vs wrong one-way. Depending on the exact positioning, the assignment may be disallowed.
b) Miner vs wrong one-way in front of him. This will generally disallow the assignment - including even if an already-mining lemming at the same position may be unaffected by it.
c) Miner standing on steel. This will disallow the assignment (on the other hand, steel in front of him does not, even if a one-way at the same position would).
d) Digger on top of steel. Once again, this prevents the assignment.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Simon on March 15, 2016, 12:18:50 PM

We've discussed this when Nepster was here.

Assignment prevention is extra complexity, my first hunch was always-allow. But I give in to Nepster's and Icho's recommendation to keep assignment prevention. Turning a lemming on steel should continue to cost more than one miner.

a) need to investigate
b) sounds inconsistent, but need to investigate
c-on-the-one-hand) good
c-on-the-other-hand) inconsistent
d) good

We'd like to treat wrong-faced OWWs exactly like steel. Make a dedicated function for steel and wrong-OWW checks, and re-route through this function all the manual reads from the special map within the assignment prevention and the skill performance.

Need to investigate: What skills cancel when touching steel (miner), what skills cancel when they would move into steel (maybe the digger?).

-- Simon

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 15, 2016, 12:23:06 PM

Under current behaviour, the miner and the basher have multiple checks. Under the proposed new basher behaviour, well, you can see for yourself above.

The digger behaviour is - and always has been, even back in L1 - stop if either (a) there's a steel pixel immediately below the digger at any time (so the transition to walker happens immediately after digging out a row), or (b) the digger has nothing to cling on to. NeoLemmix only slightly adjusts the latter part, in that steel pixels don't count, nor does the outermost pixel on each side.

Using a common function to check for these is an excellent idea.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 15, 2016, 02:22:06 PM

Our logic here was simple:   Miner isn't allowed to assign on steel (a too easy turn around) ----> one-ways in wrong direction should be the same

So only one check for one-ways and steel nessecary.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Nepster on March 17, 2016, 05:42:24 PM

OK, here a proposal for a more radical change:
  Only allow assigning bashers, miners or diggers, if applying the terrain removal mask would remove at least one terrain pixel.

Please tell me, why this suggestion is an incredibly bad idea ;).

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 17, 2016, 06:04:59 PM

Quote from: Nepster on March 17, 2016, 05:42:24 PM

OK, here a proposal for a more radical change:
  Only allow assigning bashers, miners or diggers, if applying the terrain removal mask would remove at least one terrain pixel.

Please tell me, why this suggestion is an incredibly bad idea ;).

This can be bad for backwards compability.

The basher swing is used sometimes for delaying (LP 1's "Lightspeed Lemming" comes to my mind) + appyling a basher a few frames before a wall so that it takes longer could be affected.
Furthermore it would prevent the usage of the basher most of the time in a level, which is very weird overall. So it would nearly be the only skill which can be only assigned in certain spots.
Also why is a basher that swings 1 time in mid air a bad thing?

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Simon on March 17, 2016, 06:28:07 PM

I'd like to allow assignments that don't remove any earth.

New suggestion (One-Function): When trying to assign skill X, run X's terminate-due-to-steel function. If that function would abort the skill, disallow the assignment.

Definition of terminate-due-to-steel function: Right now, each skill X terminates on touching steel, or when falling, or when running out of material. Move X's steel checks into a separate function particular to X, so each destructive skill has its own function. That function runs whenever the lemming moves. Steel remains fixed in place, so it doesn't matter whether we run the terminate-due-to-steel every frame, or only after the lemming moves.

This simplifies the rules: One rule governs both assignment and termination.

-- Simon

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Proxima on March 17, 2016, 06:34:53 PM

But that gets rid of the extremely common build-then-mine to turn around on steel.... :lem-shocked:

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Simon on March 17, 2016, 06:39:12 PM

Build-then-mine: Do you wait until the first step is built? With my proposed One-Function, you can mine, after building and stepping onto the first step.

Or can you assign miner to a builder standing on steel? That would be questionable behavior by itself.

-- Simon

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: namida on March 17, 2016, 11:19:58 PM

Quote

Or can you assign miner to a builder standing on steel? That would be questionable behavior by itself.

You cannot. However, the inconsistency here is that you can assign them to a lemming (builder or not) standing on a wrong direction one-way-wall. The result being a single swing that doesn't destroy the terrain below (of course, it might destroy terrain above the lemming if there's any and it's not also one-way), followed immediately by the lemming reverting to a walker and turning around. I believe that, apart from the lack of any terrain removal, this is identical to L1 behaviour.

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: Nepster on March 23, 2016, 01:06:24 PM

Things get even weirder with the miner assignment: If you want to assign a miner, a check for OWWs is made 4 pixels in front and 5 above the current lemming position (same as for bashers!). Neither is this check made for steel, nor is this OWW-check repeated anytime during the work (where OWWs are checked for a few pixels below the lemming).

Looking at the code, I suspect that someone just copied the basher assignment code and forgot to change the position of OWW-checks. :-\

Title: Re: [DISCUSSION] [PLAYER] Let's discuss skill assignments.
Post by: IchoTolot on March 23, 2016, 01:11:06 PM

Quote from: Nepster on March 23, 2016, 01:06:24 PM

Things get even weirder with the miner assignment: If you want to assign a miner, a check for OWWs is made 4 pixels in front and 5 above the current lemming position (same as for bashers!). Neither is this check made for steel, nor is this OWW-check repeated anytime during the work (where OWWs are checked for a few pixels below the lemming).

Looking at the code, I suspect that someone just copied the basher assignment code and forgot to change the position of OWW-checks. :-\

Another reason to make  wrong facing direction OWW = steel area ;)