Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Intel Edition
I just experienced the tank backing into a corner bug for the very first time. I decided to play a bit of the main scenario again for old times' sake, especially now that it runs so smoothly on my new MacBook Pro. Aaaand....tank bugged!
The issue seems to be that the forward motion is cut short, so that, no matter which direction it faces, it will always back up and into a wall from whence it can't be extracted.
Who has experienced this bug? What is your machine configuration? Could it be an Intel-only issue, or only experienced by users of higher-end machines? Could it be an artifact of certain video cards?
How often do you experience the bug? Have you found a way to make it stop?
I've not been able to figure much, besides that it was system-dependant. The situation actually improved for me when I got this MacBook during the beta.
I never experienced it on the MacBook, but I haven't tried it that far on the Mac Pro. Let me go through and replay the area again on both machines and I'll get back to you.
Well, I just tried it out on my new G5 at the bug disappeared! Maybe it's due to the computer change (older one was G4) or due to Mac OSX Leopard.
So the bug is neither created-only by high-end machines and nor created by Intel ones. Current garphics card: ATI Radeon 9600 Pro.
I haven't had any problems playing on my macbook, though I haven't played too much since I got my macbook.
I've never had this bug. I'm running a 12" PowerBook G4, PowerPC processor.
Okay, I have definitely experienced this bug over the holidays (not that I didn't believe it, but it was painfully obvious this time). You see, I gave SF4kA as a gift to my cousin (I knew he would like it as he did like it when I showed the game to him two years ago, back in the beta), and since he's a PC user I gave him a MacMini as a gift too, so that he could run it (and perhaps to convert him to the Mac too, muhahahaha! ;)). Anyway, when he met the Tank Boss it was pretty clear it wasn't behaving correctly, it was only going forward for an instant before going again in reverse, making it pretty much impossible to destroy, while on my MacBook it was behaving very well. We switched places so that he could vanquish a normal Tank Boss on my MacBook (which he did without problem), while I tried to take on the buggy Tank Boss, which I eventually defeated by going behind it right at the beginning and pouding it (while that might sound easy, it required all of my skills). What is interesting is that this bug affects, though to a lesser extent, the Ice Caves Boss as well, which on his computer did not pursue him nearly as much (for instance it was nearly impossible to be crushed by it against a wall), and as a consequence, since that portion was shortened, it fired its missile pair relatively more often, both things which made it slighly harder overall, though not nearly as much as the Tank Boss. To the best of our knowledge (we ended up completing the game on his computer), no other boss or enemy behaved any differently between the two computers.
What is more puzzling is that there is little significant difference between my MacBook and his MacMini: my MacBook is the first (non-pro) MacBook, the base (1.83GHz) model, bought in mid-2006 so that I could program and test Universal Binaries, while his MacMini is the base (1.83GHz) model of the currently shipping MacMinis; as you can see they are pretty similar, with the obvious exception of the processor which is a Core 2 Duo in the Mini. In both cases the OS is a fully upgraded Tiger so that is out of the equation, too.
My cousin's theory (he is a programmer as well) is that the two movements of the Tank Boss (forward and reverse) are driven by two different script actions, which themselves are handled by two different code paths which end up relying (after burying yourself a few levels deeper in the code) on two different timing methods, and depending on the hardware different actual timing results, leading to different behaviors.
Interesting. Well, this bug is understandably a brick wall for most players who encounter it. I assume the difficulty in fixing it is reproducing it, since you seem to need certain hardware. Since I can reproduce it 100% of the time, maybe I could be a guinea pig and run a test suite or something. Get some useful data in Ambrosia's hands so they can get this fixed.
I know such offers are pretty much useless when made in forums like this, since they aren't read by anyone who would be able to take advantage of them. My offer is serious, but I don't know what better channel to post it to. Maybe a beta tester in the audience would like to pick up the torch and carry it for me?
Is it related to the electrode enemies only rotating a few degrees at a time?
No. This is the tank boss. It's not related to the electrodes.
@bo-lindbergh, on Jan 2 2008, 07:33 AM, said in Revenge of the Tank Bug:
Probably, since I also have seen that one appear since I got a new computer. They may even have the same root cause.
@zacha-pedro, on Dec 31 2007, 01:43 PM, said in Revenge of the Tank Bug:
They both use the "Set Speed Forward" action, but the forward charge is a single action in a loop, while the backing up is a set of eleven actions in a row. It may be that the loop action for the forward charge is being skipped- I haven't yet worked out just how the loop action works, and that seems like a reasonable failure mode.
Quite possibly- the Electrode also has a loop for the spinning, followed by the zapping actions, so if the loop is failing, it would only shift a few degrees per zap.
I'll look through the AIs and try to find any others that should be broken if this is actually the cause of this bug.
(EDIT) Here's the list of scripts that might have problems if this theory about the Tank Bug is correct. The described behavior is what I would expect to happen if the loop in the script only ran once (unless otherwise noted). Given the lack of widespread reports of massive AI failure, I suspect that most of these scripts are not having problems, but some might.
Edwards
----------
Attack Bug: Should make 90-degree turns about twice as often as it should.
Boss 3 Wall: Should act wrong. It looks like (on all systems) it should go "open-close-fire three-open-close-fire three-open-close-fire seven-repeat", but that isn't what it does even on my system, where I've never seen the bug under discussion. I will admit that I haven't tested the loop command enough to be certain of my reading of this script, though.
Boss 4: Known to be buggy Should fail to go forward.
Boss 5: Known to be buggy Should move forward for about 2-4 seconds less time than normal (220 ticks, but I don't know how long a tick is- I think it's between 60 and 100 per second). Also, it looks like (on all systems) it should be drifting very slowly in a random direction while firing the missiles, but I can't recall seeing this.
Boss 4 Cannon: Should only fire once or twice between mine-drops, rather than five times.
Boss 6 Tentacle: Should only wave once or twice before stretching towards the player.
Pusher: Should fail to turn more than 2 degrees before charging.
Electrode: Known to be buggy Should only turn a few degrees between zaps.
Spider: Should only go through one cycle of the walking animation before changing direction/jumping, instead of four cycles.
Angry Cutie: Should only turn up to 10 degrees between charges, rather than up to 200 degrees.
Little Blob Find Friends: Should be able to switch between targets (other little blobs) several times per second, rather than about once per second. Likely undetectable.
Big Blob: Should fire about four times faster than normal.
Tank Turret: Should only turn up to ten degrees between shots; should fire several times per second.
Skull Turret: Should only turn up to ten degrees between shots; should fire several times per second.
Mess: Should change direction to chase the player several times per second, rather than about once per second.
Guardian Retreat: While the player is out of proximity range (1000 pixels? Likely out of culling range- try to test this in a boss battle, if at all), it will fire its spread of three round bullets about three times per second, rather than once per second.
Preboss 1: Should fire every 50-100 ticks, rather than every 350-400 ticks.
Preboss 1 Escaping: Should change direction about one-third more often. May be undetectable.
This post has been edited by Edwards : 04 January 2008 - 01:18 AM
I'll test as many of these as I can. I'm testing in the editor when possible, which I don't think should affect things since it's the same engine, right? The electrode bug is there in the editor, at least.
Attack Bug I don't remember how often it should turn, but it now walks for a bit more than a second (call it 1.5 seconds) between turns. Also, the "Idle Bug" script walks for less than a second between turns.
Boss 3 Wall Here, boss 3 (tested in-game) goes open-shift-close, pause, shoot three, pause, shoot seven, pause, repeat.
Boss 4 Canon I gave this script to a skull turret sprite in the editor. Its behavior is erratic, not regular at all, and hard to describe. The intervals between shots and mine drops appear to be random, and they seem to be on different timers. Shots are often grouped so closely together that they appear as one long shot.
Boss 6 Tentacle Tested in editor. Waves anywhere from 1 to 5 times between stretches, number of waves apparently random (and by "wave" I mean "rotates away from starting position, then rotates back"). Not sure if the absence of the player affects this script.
Pusher Tested in-game. Pusher can turn nearly 180 degrees before charging.
Spider Tested in-game. Spider goes through 3-4 walk cycles (looks like 3.5) before jumping.
Angry Cutie Tested In-game. Appears bugged - turn capacity is limited, about 10-15 degrees.
Little Blob Can't tell.
Big Blob Tested in-game. Fires twice in rapid succession (about 3/4 seconds between shots), then waits 1.5 - 2 seconds and repeats. This feels much faster than it used to be, but my memory is rusty.
Tank Turret Tested in-game. Assuming I've correctly identified this as the script for the turrets-on-tank-treads, then they appear fine. They don't fire several times per second, and they spin freely between shots. I gave the script to a turret in the editor, and it fired occasionally but didn't turn. This is probably to be expected due to the absence of the player.
Skull Turret Tested in editor. Fires once every 2-3 seconds. Does not rotate (no player to track).
--------------------
Now, for these:
@edwards, on Jan 3 2008, 06:04 PM, said in Revenge of the Tank Bug:
...I'll need to make a map and load it up, and I'm too tired right now since it's 2AM. Later. BTW, what do the "Preboss 1" scripts do?
This post has been edited by cheleball : 04 January 2008 - 04:26 AM
Oh, also. One of your (Edwards') PMS bosses doesn't behave as you'd like. It's the turret room from hell, and the boss with far too much health for its brutally short hit window. (I mean, sure, you can sit in the safe zone and shoot at it endlessly, but how much fun is that? But, that's the only way I can beat it, since as soon as I try and get more aggressive I am summarily owned by the many turrets.)
Anyway, the round shields that shoot out to allow you to hit the boss don't return to the same place every time. Over time, they recede further and further towards the center, until the boss can be damaged even when they are retracted. I consider this a feature, not a bug.
I also noticed, as I was playing through to the third boss, that the crab's arm didn't quite stay put. It was always in a different spot relative to the crab's body, and even overlapped the head a time or two.
I think I was going to say something else, but my fatigue-clouded brain can't remember.
@cheleball, on Jan 4 2008, 02:22 AM, said in Revenge of the Tank Bug:
On my system, Attack Bug walks 5-6 seconds (23 sprite cycles, although you'll need to test on a big map to slow things down enough to check) between turns.
The absence of the player only affects the script to the extent that it will not turn towards the player before stretching. Other than that, that looks half-bugged, as if it's only skipping loops some of the time. The correct number of waves is five.
Erm. That's weird- it should fire absolutely regularly, with a period of around 2 seconds (four sprite cycles).
All right, having just checked it again, I was wrong about how it acted on my system (it's been too long since I last played the single-player scenario). On my system, it goes: open-shift-close, shoot three, open-shift-close, shoot three, stop rotating, shoot four, repeat. The bugged version should go: open-shift-close, shoot three, stop rotating, shoot four, repeat, but that doesn't look like what you're seeing.
That actually sounds about right. The time variance between shots is 132 ticks +/- 120 ticks, so to test it, I'd suggest dropping a whole slew of other critters in a map to slow everything down, and carefully counting the number of shots between mine drops- it should always be five, no matter what the actual time involved is.
Your descriptions of these past five seem to imply that the bug is more complex than simply "skip all loops"- each of these descriptions matches up quite well with the expected behaviour if some-but-not-all of the loops are skipped.
Yep. That's buggy. On my system, it can do at least a 180-degree turn.
This one really is undetectable. I'm not entirely sure why I bothered to include it.
Tank Turret Tested in-game. Assuming I've correctly identified this as the script for the turrets-on-tank-treads (Ed: Yes, you have.) , then they appear fine. They don't fire several times per second, and they spin freely between shots. I gave the script to a turret in the editor, and it fired occasionally but didn't turn. This is probably to be expected due to the absence of the player.
All of these look to be bug-free. For the Spider, on my system, in the editor, the upper-right leg kicks out four times between direction changes, so you might want to look at that. It looks like the bug is not appearing in that script, though.
Preboss 1 is the script for the grey Sketchfighters that chase you just before the Pen battle. Preboss 1 Escaping is the script for the grey Sketchfighter that you need to shoot.
@cheleball, on Jan 4 2008, 02:40 AM, said in Revenge of the Tank Bug:
Sitting and shooting from a distance is the recommended method of killing that boss, unless you're über enough to charge out, hit it with the Beam, and retreat to the safe doorway during its vulnerability period ( I can manage that occasionally). As for the retreating shields, that is not good- it's using the Pen Cap AI, which in my experience is the most regular AI in the game. Could you check to see if the Boss 7 Cap AI drifts at all when used not as part of a boss?
With regards to the Crab boss, it looks like there may be some issue with the timing in the script, as that one is simply a long sequence of carefully-timed commands, with no looping. Given that the Pen Cap AI is also based entirely on careful timing, there may be a second bug here.
Anyway, thank you very much for testing all of these. Given this list of buggy and semi-buggy scripts, it's definitely looking likely that there's some problem with the "loop" script action, although the cause is apparently fairly complex. If someone on the beta list could forward this discussion to Lars, this might help him to track down the bug in the code.
Quote
The seven-shot is probably four. I admit I didn't count the shots, I just noticed that they came faster the second time around, and since you said seven I thought it must be seven, even though that seemed a bit much.
I also don't remember if they stop rotating for the four-shot or not. But the sequence and timing of these events is as I described on my machine.
I'll try and drop enough critters to slow down enough to test the tank turret. I'm sure it's possible, but I haven't yet seen this computer choke or even really hiccup on anything SketchFighter throws at it. Even the editor runs smoothly while editing huge maps (which, by huge, I mean PMS Part 1).
ATTEMPT AT A PATCH Attached to this post is a file that, if this theory about the bug is right, should get the Tank boss to work properly. It's basically a replacement script with the loop unrolled all the way. I don't have a bugged computer that I can test it on, but it acts almost identically to the original Boss 4 script on my system (it goes forward for about an eighth of a second longer, but is otherwise the same). Installation is manual- instructions can be found with the file.
Disclaimer: This patch is entirely unofficial, and is in no way endorsed by Ambrosia Software. Use at your own risk.
@cheleball, on Jan 5 2008, 11:38 AM, said in Revenge of the Tank Bug:
Have you tried the fully-spliced-together version that I think I sent you? If that doesn't work, SMM a huge map with itself a few (dozen) times- I doubt that even a current-generation Mac Pro could handle a 30-50MB map smoothly.
Edwards, you astonish me man. Nice work.
The tank's motion is a little jerky, and it eats its own mines (they literally evaporate after a short period of time), but at least the boss is passable. I recorded a video so you could kinda see what's going on. It's pretty jerky (that's Jing's fault, but every other movie capture utility costs money and puts horrendous watermarks on your videos until you register. I'm all for paying for shareware, but I have so little need for this sort of program I can't justify it). So, you can't really see what's going on that well. But I hope it's better than nothing.
Check it out.