difference in wall growth rate?
Moderators: Flumminator, Zomis
Re: difference in wall growth rate?
Well, looking at the commit descriptions narrowed it down, looking at diffs narrowed it further, then I got suspicious of one change, edited src/game_em/input.c:readjoy() to act like 'use_single_button' was always false, and -- the tape worked.
Holger, I've died many times because I hit left-ctrl ('snap') intending only to advance the clock, and instead laid a bomb. Now we see this feature causes old tapes to malfunction. What was the reason for adding it? So far I've only experienced it as a negative.
Holger, I've died many times because I hit left-ctrl ('snap') intending only to advance the clock, and instead laid a bomb. Now we see this feature causes old tapes to malfunction. What was the reason for adding it? So far I've only experienced it as a negative.
Re: difference in wall growth rate?
Don't worry, the bug preventing this tape from playing back in 4.0.1.0 and 4.0.1.1 is already fixed. I think I will throw out a new patch version 4.0.1.2 in the next few days.
I thought I already fixed this bug before, but yesterday I found out that the fix was broken and did not work... Not sure how I managed to mess up here.![Surprised :-o](./images/smilies/icon_surprised.gif)
Fixing this bug fixes most of the broken EMC tapes as reported by Ryan in this thread. But not all of them. I've managed to track this bug down to being introduced with R'n'D 3.3.1.0 (as the remaining broken tapes still work fine with 3.3.0.1).
Finding the commit that caused this problem could be a bit tricky, as this is still the old 32-bit code, which refuses to compile out-of-the-box now, I think, so quickly using "git bisect" won't work as easy as it did for the problem mentioned above...
Hope to find and fix it soon, anyway, and release both fixed with 4.0.1.2.
I thought I already fixed this bug before, but yesterday I found out that the fix was broken and did not work... Not sure how I managed to mess up here.
![Surprised :-o](./images/smilies/icon_surprised.gif)
Fixing this bug fixes most of the broken EMC tapes as reported by Ryan in this thread. But not all of them. I've managed to track this bug down to being introduced with R'n'D 3.3.1.0 (as the remaining broken tapes still work fine with 3.3.0.1).
Finding the commit that caused this problem could be a bit tricky, as this is still the old 32-bit code, which refuses to compile out-of-the-box now, I think, so quickly using "git bisect" won't work as easy as it did for the problem mentioned above...
Hope to find and fix it soon, anyway, and release both fixed with 4.0.1.2.
Re: difference in wall growth rate?
When loading a tape, should the initialization of this setting depend on tape.game_version ? I see hex bytes 04 00 01 01 in my tape, 04 00 00 00 in RAP's.
Re: difference in wall growth rate?
I want to re-emphasize that I've experienced it as a negative in interactive play, nothing to do with tape bugs. Maybe it's a bad habit of mine using l-ctrl as a clock advancer, but it's deeply ingrained and keeps killing me...
Re: difference in wall growth rate?
Yep, you nailed it -- it's exactly this change that caused the problem.
The reason for adding this change was to be able to play EM/EMC levels using a single-button joystick again (or use a multi-button joystick, but use the same button for snapping and dropping, just like in the original game on the Amiga).
This indeed caused some problems with the single-step mode, which I thought I had fixed (together with some other nasty bugs and mis-behaviours of the single-step mode, depending on game engine, where it sometimes worked wrong).
Advancing the clock with the snap key in single-step mode is a well-known technique I also use every now and then. But I cannot reproduce the mis-behaviour you described (nor with plain 4.0.1.1, neither with my working version which already contains the bugfix). Just tested this with Classic Emerald Mine, level 59. Collected some dynamite, then released a falling rock and watched it falling step by step by pressing the snap key, without dropping a bomb. The dropping a bomb with the drop key. This is because snap and drop key work a bit differently in single-step mode, to still be able to advance the clock without dropping dynamite.
Could you please describe in detail how to reproduce this bug with plain 4.0.1.1?
The reason for adding this change was to be able to play EM/EMC levels using a single-button joystick again (or use a multi-button joystick, but use the same button for snapping and dropping, just like in the original game on the Amiga).
This indeed caused some problems with the single-step mode, which I thought I had fixed (together with some other nasty bugs and mis-behaviours of the single-step mode, depending on game engine, where it sometimes worked wrong).
Advancing the clock with the snap key in single-step mode is a well-known technique I also use every now and then. But I cannot reproduce the mis-behaviour you described (nor with plain 4.0.1.1, neither with my working version which already contains the bugfix). Just tested this with Classic Emerald Mine, level 59. Collected some dynamite, then released a falling rock and watched it falling step by step by pressing the snap key, without dropping a bomb. The dropping a bomb with the drop key. This is because snap and drop key work a bit differently in single-step mode, to still be able to advance the clock without dropping dynamite.
Could you please describe in detail how to reproduce this bug with plain 4.0.1.1?
Re: difference in wall growth rate?
Yes, exactly. And it indeed works like this in 4.0.1.1 -- unfortunately it (the single button setting) then gets unconditionally overwritten afterwards. That's the bug that I've just fixed.When loading a tape, should the initialization of this setting depend on tape.game_version ? I see hex bytes 04 00 01 01 in my tape, 04 00 00 00 in RAP's.
![Smile :-)](./images/smilies/icon_smile.gif)
Re: difference in wall growth rate?
And it definitely should work that way! Apparently I'm just unable to reproduce this...I want to re-emphasize that I've experienced it as a negative in interactive play, nothing to do with tape bugs. Maybe it's a bad habit of mine using l-ctrl as a clock advancer, but it's deeply ingrained and keeps killing me...
![Sad :-(](./images/smilies/icon_sad.gif)
Re: difference in wall growth rate?
I will report if it still happens once I've built the latest. (Apparently not checked in yet?)
Suppose that, in the process of advancing the clock with 'snap', I sometimes lean on that key for a second or longer? I expect that to have no more effect than tapping it for an instant -- either way, advance the clock one 'tick'. I think that's probably where it goes wrong for me, but I'd have to have it happen again to be sure.
Suppose that, in the process of advancing the clock with 'snap', I sometimes lean on that key for a second or longer? I expect that to have no more effect than tapping it for an instant -- either way, advance the clock one 'tick'. I think that's probably where it goes wrong for me, but I'd have to have it happen again to be sure.
Re: difference in wall growth rate?
Well, in a quick test, leaning on l-ctrl doesn't blow me up in single-step; but it does in realtime play. It's possible (let's say 'likely') that I also sometimes lean on l-ctrl in realtime play, knowing it is a 'do-nothing' key. Only it isn't, any more.
Re: difference in wall growth rate?
Well, I'm talking about plain 4.0.1.1 -- nothing else is commited or pushed yet on top of that...I will report if it still happens once I've built the latest. (Apparently not checked in yet?)
Perfectly fine in single-step mode -- press it as long as you like, it won't drop dynamite. (At least, it shouldn't!)Suppose that, in the process of advancing the clock with 'snap', I sometimes lean on that key for a second or longer? I expect that to have no more effect than tapping it for an instant -- either way, advance the clock one 'tick'.
Ah, OK, yes. That's the new single-button mode I was talking about! That is, the EM engine now behaves exactly like on the Amiga in this regard: Press any button, and it will either snap (together with a direction) or drop dynamite (when held a bit longer without an additional direction key). However, in single-step mode, it still separates between the snap and the drop key, just to be able to do that "advance the frame counter" thing, and to have more control over what's going on.Well, in a quick test, leaning on l-ctrl doesn't blow me up in single-step; but it does in realtime play. It's possible (let's say 'likely') that I also sometimes lean on l-ctrl in realtime play, knowing it is a 'do-nothing' key. Only it isn't, any more.
But I can see clearly now that single-button mode for the EM/EMC engine needs a setup option to turn it on or off.
![Very Happy :-D](./images/smilies/icon_biggrin.gif)
Re: difference in wall growth rate?
Make it a tri-state all-engines setup option:
( ) off for all
(*) on for EMC engine, off for others (like the respective originals) (default)
( ) on for all
( ) off for all
(*) on for EMC engine, off for others (like the respective originals) (default)
( ) on for all
Re: difference in wall growth rate?
The possible option "on for all" would not work with the R'n'D engine, as there is no delay when dropping dynamite (so it is possible to "walk and drop" multiple pieces of dynamite, which is not possible in the EM engine.
On the other hand, we have the same scenario with the SP engine, as it behaves just like the EM engine in this regard.
Another possible solution would be to only use single-button mode when using a joystick, as that's what it was designed for at a time when joysticks like the Competition Pro for C64 and Amiga had two physical buttons, but which were wired as one single button (so it did not make a difference if you used the left or right fire button).
But this wouldn't work, as it is possible to switch input devices in single player mode (like using the keyboard and a joystick in parallel within the same game), so when replaying the tape it would not know from which input device the input actions came, not being able to use the correct processing in the game engine. So a global setup option to turn it on or off would be needed anyway.
So, if I did not miss anything, it's effectively only "on" or "off" for all engines that support single-button actions (that is EM and SP).
On the other hand, we have the same scenario with the SP engine, as it behaves just like the EM engine in this regard.
Another possible solution would be to only use single-button mode when using a joystick, as that's what it was designed for at a time when joysticks like the Competition Pro for C64 and Amiga had two physical buttons, but which were wired as one single button (so it did not make a difference if you used the left or right fire button).
But this wouldn't work, as it is possible to switch input devices in single player mode (like using the keyboard and a joystick in parallel within the same game), so when replaying the tape it would not know from which input device the input actions came, not being able to use the correct processing in the game engine. So a global setup option to turn it on or off would be needed anyway.
So, if I did not miss anything, it's effectively only "on" or "off" for all engines that support single-button actions (that is EM and SP).
Re: difference in wall growth rate?
Oops, I totally forgot for a moment that there's EM style dynamite also in the R'n'D engine, which does not support single-button actions due to the reasons described above (R'n'D style dynamite without delay).
But I think it does not change much (if we don't want to support esoteric cases like "R'n'D levels using only EM elements", which would be possible to be played with single-button mode)... correct me if I've missed something; I might be suffering from tunnel vision again. :-/
But I think it does not change much (if we don't want to support esoteric cases like "R'n'D levels using only EM elements", which would be possible to be played with single-button mode)... correct me if I've missed something; I might be suffering from tunnel vision again. :-/
Re: difference in wall growth rate?
When recording a tape in which two buttons' actions are conflated, the button whose action was actually executed should be written to the tape. Then there is no playback ambiguity.
Re: difference in wall growth rate?
This does not work, I think: Imagine playing an EM level in single-button mode, and pressing one button for about half a second (therefore already recording that button to the tape): At this point, it is not yet decided if the player's intended action is snapping (by adding a direction key to the already pressed button) or dropping (by keeping that button pressed without pressing an additional direction key).When recording a tape in which two buttons' actions are conflated, the button whose action was actually executed should be written to the tape. Then there is no playback ambiguity.
So I think the best solution would be an on/off setup option/flag that then gets stored to the tape.