How I recall Windrobes: behave like Red Wizzrobes, but instead of a magic blast, it shoots a wind blast that sends you back to the start of the DMap.
How I encountered Windrobes in Lost Isle on build 613 (Mac): appear like Red Wizzrobe, fires EIGHT wind blasts in compass and intermediate directions at full force. It seems like it was mixed in with the Firerobe code somewhat. DarkFlameWolf has confirmed that this windrobe behavior was NOT what she meant: she wanted the original Windrobe behavior.
See more info on this, and maybe other things, here: http://www.purezc.com/forums/index.php?s=&showtopic=29884&view=findpost&p=438046
Haha, yea, fuck, I saw this happen a few betas ago. Omnidirectional whirlwind attack is a little bit unfair. Maybe add some commands to the enemy editor so that we can modify this?
I would also love the ability to use different enemy weapons like this. Like, eight-way fireballs or swords. You can script such things, but it looks like the code is already there to modify how many projectiles get shot out. Why not streamline it?
It's worth noting that since lost isle's release, the custom enemy codes have somewhat changed. Try building a test quest with a recent beta using wind robes and seeing if it creates the same problem. If it doesn't, then it's the quest not the build.
I believe if misc4 = 1 now denotes mirror behavior, and misc2 = 1 for omni-directional weapons.
Yes, and that notably applies to all weapons. It also makes the movement and firing patterns more unpredictable and random. I noticed it when I modified my quest's final boss with it.
Still, this behavior is a bug and should not be acting that way by default. I first noticed it in 584. So, I will confirm this a a bug.
Customizing the action in the editor may fix it, but, like I said, it's still a bug since the windrobe should not act like that by default.
If it's from quests from earlier versions which used a different code, then it isn't a bug. The only possible bug here is if the default coding for them(in the editor) is off. By that I mean if you start a quest in 584, their default coding should be the correct one. Can't call it a bug for quests that pre-date the current code.
I have confirmed it with DarkFlameWolf that the Windrobes I encountered were NOT what she intended. Therefore, I have to say it's a bug.
This sort of corruption (for lack of a better word) happens when you move quests from one build to another. I've been moving the same quest along the builds since the system was implemented, and it has created all sorts of problems like this. For instance, if you have a quest from before b277 but after the introduction of the enemy editor, you'll have to manually change the step speed of all Pols Voice enemies unless you like them moving twice as fast. It's a bug, but it's an easy to explain bug that will have no effect on quests created after this change was made to the enemy editor or on quests made before the enemy editor and can be fixed in all other quests by a simple tweak of a single number by the quest author.
AmazingAmpharos wrote:This sort of corruption (for lack of a better word) happens when you move quests from one build to another. I've been moving the same quest along the builds since the system was implemented, and it has created all sorts of problems like this. For instance, if you have a quest from before b277 but after the introduction of the enemy editor, you'll have to manually change the step speed of all Pols Voice enemies unless you like them moving twice as fast. It's a bug, but it's an easy to explain bug that will have no effect on quests created after this change was made to the enemy editor or on quests made before the enemy editor and can be fixed in all other quests by a simple tweak of a single number by the quest author.
Wait...so THAT'S why the Pols Voice and Tektikes were moving twice as fast! But...that still doesn't explain the Windrobe behavior...
I'll try to get a demo quest up in a few days: I have to take care of homework first.
Wolfman2000 wrote:I have confirmed it with DarkFlameWolf that the Windrobes I encountered were NOT what she intended. Therefore, I have to say it's a bug.
AmazingAmpharos is right, it's a problem with playing the quest on an imcompatible build, not a problem with the build itself.
Right right, but I thought that the builds were being made to be backwards-compatible?
yes. but making it backwards compatible with over 600 builds is a joke. its meant to be backwards compatible with the already OFFICIAL builds.
ZC is officially backwards compatible with all full releases, which are currently 2.10, 1.90, and 1.84. We try to maintain backwards compatibility in other cases as much as possible, but occasionally, such as with the enemy editor here, it's just not practical.
the 1.92 b182 and 183 are supported too right?
You'll have to ask DN, but I would think the "b"s in those versions speak for themselves.
Even if they're not officially supported, I haven't heard of any bugs affecting those versions and not 2.10 or 1.90.
well yes they are betas, but for some reason they are treated as official on the Zelda classic website... so you would think that they would also be part of this perfect backwards compatibility scheme.
In what way? There are download links of course, but that's so people can play the quests in the QDB, not an indication that they are full supported releases (it says "beta" right on the link).
Moreover now that I think about it, there are 1.92 quests (DoY comes to mind) that are hopelessly incompatible with 2.5 and probably always will be.
That reminds me. Will DemoEX be included in the 2.5 lineup? Because some months ago I played through it and noticed that the clock bug was present in it. Should be easy to fix though.
DemoEX's clock issue is a quest problem though, not a ZC bug. I suppose it's up to Nightmare if he wants to fix it or not.