LemmixPlayer ccexplore updates

[ccexplore]

This is less exciting than what namida did, but now that I got help from him and Eric in getting LemmixPlayer to compile, I'm finally able to make fixes to some of the game-mechanics-related issues, in particular:

1) the incorrect entrance ordering for 3 entrances for any styles besides original DOS Lemmings
2) inability to replay http://www.lemmingsforums.com/index.php?topic=34.msg1337#msg1337" class="bbc_link" target="_blank">ClamSpammer's steel-digging glitch correctly

I've attached the LemmixPlayer.exe I've compiled with the fixes, which I've also taken the liberty to update the version number from 0.8.0.0 to 0.8.0.1.  Bug #1 is N/A for this though, since it's only original DOS Lemmings; I'll try compiling the other LemmixPlayers, and the editor, later.  That said, the fix for #1 is a one-line fix so I'm pretty confident I didn't screw anything up.

Bug #2 on the other hand turned out to be a little trickier to fix than I originally thought.  The basic issue is that while the replays record the mouse cursor position when skill assignments are made, it doesn't record whether the right mouse button is held down, although it does record the exact lemming that receives the skill assignment.  The approach I ended up using for the fix is to basically have the game first "test" the skill assigment using the recorded cursor position, assuming the right mouse button wasn't down, and if the lemming it would've assigned the skill to doesn't match with the replay record, it will try again assuming right mouse button was down.

I believe I've handled the code changes correctly for this, but I would definitely appreciate some extra testing on this:

1) Make sure when NOT in replays, skill assignment are working as expected for all 8 skills, and for both with and without holding down the right mouse button.

2) Pick a bunch of your favorite replays and make sure they still play correctly.  Try to cover all 8 skills and to include ones that use the right mouse button.

=================

I've also attached my changes to LemGame.pas that fixes the two bugs noted above, in case other people are working on compiling their special versions of LemmixPlayer and would like to incorporate my fixes.  That said, it might not be a bad idea to first wait for some additional testing from other people to make sure that my fix for #2 doesn't break anything.

[edit: removed attachment, new update available in later post]

[Clam]

From reading that, it seems like you've fixed the right-click bug and not "my" steel-digging glitch. This steel glitch doesn't require the right mouse button to be used at all (it just depends on the cursor position). Or have you done both at once?

If you and Eric are in the mood for fixing Lemmix right now, I have some ideas for changes that would really help with the least time challenge. Pausing for time and the nuke glitch are the two main ones, but there are a few others as well.

[ccexplore]

From reading that, it seems like you've fixed the right-click bug and not "my" steel-digging glitch. This steel glitch doesn't require the right mouse button to be used at all (it just depends on the cursor position).

No, it is the fix for the steel-digging glitch.  I guess it's a little unclear, and it's hard to explain without pointing to the actual changes in source code.  Let me try again.  Also, note that I'm trying to fix it such that existing replays already recorded containing usages of the steel-digging glitch will play back correctly w/o needing to be re-recorded.

Now, the steel-digging glitch requires a prioritized and a non-priortized lemming being considered in the digger skill-assignment code.  However, the replay mechanism only records the lemming the skill is assigned to.  If there's a choice of 2 lemmings being considered in the skill assignment, the replay does not record the information regarding which lemming is the "other" lemming.  Also, the replay records the mouse cursor position, but not whether the right-mouse button has been pressed.

Because of the missing information, to fix the problem means I need to recover the full prioritized/non-prioritized information from what's available in the replay records.  The mouse cursor position is a big help because I can pass that in to the prioritize hit-testing code to recover which lemming (if any) is the prioritized lemming, and which is the non-prioritized lemming.  At first I thought that is sufficient, but then my replay for the 1-builder Mayhem 14 solution failed to play back correctly at a move completely unrelated to the glitch.  Turns out one of the recorded moves actually make use of holding down the right mouse button to select the non-prioritized lemming under the cursor.  Unfortunately, this right-mouse button information is not being captured anywhere in the replay, except for the fact that the assigned lemming (which is saved in the replay) would be different from the prioritized lemming based on normal prioritization calculations.

But it gets worse.  Just because the non-prioritized lemming gets selected doesn't necessarily mean the right-mouse button is down.  In particular, as you've noted, the steel-digging glitch is a case where you actually cannot have the right-mouse button down, even though it's the non-prioritized lemming that gets assigned the digger.

So the only way to fix it is to basically first test to see which lemming the skill assignment would've chosen, assuming the right-mouse button isn't down.  Only when that leads to the "wrong" lemming being chosen (as we can check against the lemming in the replay records) do we redo the skill assignment assuming right-mouse button is down.

The skill assignment code originally does not have this separation of "just test out which lemming gets chosen" and "do the actual skill assignment on the lemming chosen--decrease number of skills, change the status of the lemming, etc.".  So to implement my fix, I have to change the code for all 8 types of skill assignment, to support a usage specific for replays, where we merely wants to know which lemming gets chosen, without actually going through with the skill assignment.  Now, I'm fairly confident that I've made the changes correctly, but since the code for all skill assignments are affected, it seems prudent to have more thorough testing of skill assignment in all possible scenarios, whether in replays or not.

Or have you done both at once?

I can't fix the right-click glitch until I fully understand what's going on, which I don't at the moment.  I'll first need to find the relevant code in the original game responsible for the behavior, in order to make sure that I can correctly emulate the behavior in all cases in Lemmix.

It's likely that to fix the right-click glitch, I'd need to expand the replay format to record more information related to the mouse.  Fortunately since there are currently no replays that make use of the glitch (since the glitch doesn't work in Lemmix outside of replays to begin with), it would be acceptable to require changing the replay format to support it in replays.  Of course, once you do that, you need to have the code being able to handle both the old and new replay formats, which can lead to a lot of messy code.

If you and Eric are in the mood for fixing Lemmix ri fght now, I have some ideas for changes that would really help with the least time challenge. Pausing for time and the nuke glitch are the two main ones, but there are a few others as well.

Thanks.  I'll take a look at that thread and see.  The nuke glitch in particular should be pretty easy to fix.  Pausing for time may take some work to fix though, we'll see.

[Clam]

For the steel-digging glitch, would it not be sufficient to just force the skill to be used in the replay regardless of whether the lemming is on steel? If it's saved in a replay, it must have been done while actually playing the level.

Remember, there's an equivalent glitch with builders near the top of the map.

Thanks.  I'll take a look at that thread and see.  The nuke glitch in particular should be pretty easy to fix.  Pausing for time may take some work to fix though, we'll see.

I didn't post them in that thread. Here's what I have thought of. I know I'm asking a bit much here, but anyway...

- pausing for time and nuke glitch
- frame advance and reverse during play (currently frame advance only functions in replay mode)
- rewind
- ability to assign skills while paused
- frame counter (ticks over once per frame, may be useful for reference)
- option to remove the "blink" on assigned lemmings in replays (would make them nicer to watch eg. on Youtube)
- option to stop the timer when the required percentage is reached
- option to view steel, triggers and terrain-detection pixels during play (where the game checks for terrain/steel on builders, diggers etc)
- double-click to switch to min/max rate
- display distance to exit on lemmings under cursor (to help with timing release when the worker is a long way from the crowd)

[ccexplore]

For the steel-digging glitch, would it not be sufficient to just force the skill to be used in the replay regardless of whether the lemming is on steel? If it's saved in a replay, it must have been done while actually playing the level.

Remember, there's an equivalent glitch with builders near the top of the map.

That sounds logical, except again, the original code has no separation between determining which lemming (possibly none) gets the skill, and the actual skill assignment to a specific lemming.  The original code handles assignments in replay by basically setting the priortiized and non-prioritized lemming both to the lemming in the replay record, and passing that to the assignment-handling code.

So even the logical change you suggest will still require basically the same code changes as my current approach, to separate out the two things so they can be done independently of each other.  Plus, the "force skill on lemming stored in replay" approach can lead to abuse, where by hex-editing the replay file, someone can assign skills to lemmings they normally can't.  My change effectively prevents this as well.

And yes, the fix should allow the equivalent builder glitch to be played back in replays as well.

[ccexplore]

I didn't post them in that thread. Here's what I have thought of. I know I'm asking a bit much here, but anyway...

 http://www.lemmingsforums.com/Smileys/lemmings/shocked.gif" alt=":o" title="Shocked" class="smiley" /> Yeah, "a bit much" sound about right. http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" />  I'll take a more careful look at the list later tonight and try to rank them by amount of effort, to see which ones to tackle first.

[ccexplore]

- option to remove the "blink" on assigned lemmings in replays (would make them nicer to watch eg. on Youtube)

I'm not entirely sure I agree.  The blink is intended to help you identify which lemmings a skill gets assigned to.  It's true that for most skills you can tell from what the lemming starts doing afterwards, but then there are skills like climbers and floaters that aren't the case.

Moreover, in my opinion the current approach may not be entirely sufficient for a Youtube video.  To make the video match the actual playing experience more closely, I believe it should actually show the pausing/unpausing, screen scrolling, and mouse cursor movement as well, or at least an abbreviated form of them.  Sometimes where you position the mouse cursor is actually critical for a solution to work.

Nevertheless, to test out the resulting experience, I could look into implementing a form of your proposal, where non-permanent-skill assignments are shown w/o the highlighting, but permanent-skill assigments are still shown with it.

[Clam]

the "force skill on lemming stored in replay" approach can lead to abuse, where by hex-editing the replay file, someone can assign skills to lemmings they normally can't.

I know. http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" /> Probably not the way to go, if you can avoid it.

Yeah, "a bit much" sound about right.

If there's no interest in speedrunning levels (which apparently there isn't right now) then none of this is really necessary. Then again, build it and they will come...

The blink is intended to help you identify which lemmings a skill gets assigned to.  It's true that for most skills you can tell from what the lemming starts doing afterwards, but then there are skills like climbers and floaters that aren't the case.

Even in the case of climbers and floaters, I think it's enough to see the result of the assignment rather than worrying about where it took place. In most cases, there's a sizeable window in which to assign the skill, and the exact position doesn't matter.

To make the video match the actual playing experience more closely, I believe it should actually show the pausing/unpausing, screen scrolling, and mouse cursor movement as well, or at least an abbreviated form of them.  Sometimes where you position the mouse cursor is actually critical for a solution to work.

This will just make the video longer and less fun to watch. To me, it just looks more impressive in real time, and the details don't matter. I'd rather refer to a set of explanatory notes when needed than have the action slowed down. And I'd be happy to provide such explanations if I were to make a video.

[ccexplore]

This will just make the video longer and less fun to watch. To me, it just looks more impressive in real time, and the details don't matter.

Hmm, I see.  Yeah, I'm aware that speedruns of other games often employ interesting tricks that are theoretically possible but ridiculous for human execution, such as certain combinations of rapid button presses or something.

So I guess I see your point about looking more impressive.  On the other hand, aren't the speedrun videos you see for SNES include the cursor movements and such?  Or do they edit and cut out those stuff before posting the video?

I guess in this case, since it'd be relatively easy to do so, I can just provide options to hide all highlights, hide highlights for non-permanent skills, and show all highlights.  This gives people the full range of configuration on how they want to see the replay.  I'll probably skip the "more realistic" playback for now since it'd definitely take more work and not appropriate for speedrun videos, although I can still see certain uses for it, like the playback of a multi-tasking level where you might want the view to switch back and forth between the two lemmings you are assigning skills to, without having to manually pause and jump the screen yourself during playback.

[Clam]

aren't the speedrun videos you see for SNES include the cursor movements and such?

The SNES Lemmings TAS I mentioned does show the cursor. But I should draw a distinction here between playing for fastest in real time (which is the goal of a TAS) and fastest in game time (which is the goal of the challenge thread). I think cursor visibility is appropriate for the former, but not the latter. Real-time playing has the added element of limited cursor movement (although I don't know exactly how relevant this is with a mouse), and thus slightly more limited skill assignment possibilities, and so it's important when you watch the video that you can see the cursor and verify that the actions performed are indeed possible in real time. For a "least game time" run, this isn't the case, and having the cursor flicking across the screen all the time would just be distracting. I think the most effective video would come from playing back the replay at full speed and keeping the screen view in a good position for viewing.

Again, I don't mean to create heaps of work for you and Eric. I just wanted to get those ideas out there...

[ccexplore]

Again, I don't mean to create heaps of work for you and Eric. I just wanted to get those ideas out there...

Oh don't worry, we'll simply put off the harder stuff until eternity. http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" /> And actually, I think it's just me at the moment making these sorts of changes.  I'm just slightly surprised how many things are on your wishlist, http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" /> although a lot of it makes sense when you're trying to do a speedrun type of thing.

I just barely started looking at the code, so things will probably start off slowly at this point. http://www.lemmingsforums.com/Smileys/lemmings/wink.gif" alt=";)" title="Wink" class="smiley" />

[namida]

I think the major one is just fixing the nuke glitch and time pause, plus the ones you've already done - and you should probably combine it with my idea of adding ONML styles as well, rather than forcing people to choose one or the other.

[ccexplore]

Okay, I've attached LemmixPlayer.exe and LemmixPlayerOhNo.exe with the following updates:

1) fix the 3-entrance ordering for non-original-DOS-Lemmings mechanics
2) added support for the steel-digging glitch in replays
3) added support for nuke glitch
4) added a form of support for the time pause glitch
5) per namida's suggestion, LemmixPlayer.exe will support all 9 graphics sets (ie. 5-8 for ONML and 9 for Xmas) instead of just the 5 from original Lemmings.

#4 needs further explanation, because right now I'm supporting it a little differently from how you'd do it in the actual game, for simplicity.  Instead of making it happen through pausing, you can press 'z' (lowercase) to toggle the glitch on and off (defaults to off when you run the program).  If you toggle the glitch on, the next time you play or replay a level/replay, the game will reset the timer back to the level maximum time when the entrances start to open.

I might redo this later to support it more like the way it works in the game, but for now, what I've done is the simplest way to support the bug, while keeping existing replays compatible (as well as giving you the option to run a replay either with or without the glitch as you so choose).

I've also attached the source files I've changed, at least the ones I remember changing.  The change in GameWindow.pas is solely for checking the pressing of the 'z' key.

[edit: oops, I think there's one more time-related variable I forgot to reset, so you might still end up losing a few frames despite the time reset.  I need to head out of home soon, I'll fix it later when I'm back]

[edit2: another update posted, go to latest post for downloads]

[Clam]

I don't know what sort of priority order you have in mind, but I think frame advance and assignment while paused should be next on the list. I would consider these to be absolutely necessary for the least time challenge, my other suggestions much less so. Frame advance has already been implemented for replays, so surely it can't be that difficult to get working. (Can it?)

[ccexplore]

I think frame advance and assignment while paused should be next on the list.

I looked through more of the code just now and it looks like, at least with the code I'm working off from, frame advance seems to be already there.  You can press 'n' (lowercase) while paused and it should advance the game by one frame.  It shouldn't matter whether it's replay or normal play.  Give it a try and let me know whether it works or not.