I think I found a bug.
Solid damage combos aren't hurting Link, UNLESS he's hitting the exact edge of the combo. It's sort of easy to replicate. It sort of breaks my quest :/
Posted 27 September 2013 - 10:48 AM
I think I found a bug.
Solid damage combos aren't hurting Link, UNLESS he's hitting the exact edge of the combo. It's sort of easy to replicate. It sort of breaks my quest :/
Posted 27 September 2013 - 11:29 AM
I think I found a bug.
Solid damage combos aren't hurting Link, UNLESS he's hitting the exact edge of the combo. It's sort of easy to replicate. It sort of breaks my quest :/
What do you mean by exact edge of the combo? Do you mean only the corner of the combo or what? I mean, isn't a damage combo supposed to damage only when link hit's it?
Theres also a quest rule for that. Have you checked or unchecked the rule "No Solid Damage Combos" under questrules -> backward compatibility?
Posted 27 September 2013 - 11:44 AM
Oh, I didn't know there was a Quest Rule for that I'll check it out. Thanks!
Posted 28 September 2013 - 04:37 PM
Posting this here, because AGN isn't being read by anybody:
The warp mixup glitch is still in 2.50stable, and I don't see a related fix in the first post, so then it's still here in 2.50.1RC1...
It means that ZQ (or ZC) randomly reassigns another warp destination (dmap and screen number) to screens on a map.
In 2.50RC2 (or even in RC4, I don't remember) I had it so in a quest that almost all of my Map 4 warps got set to the bottom row of that map, but staying on the same dmap.
Today I realized to my horror that in another, "started on 2.50stable" quest of mine, a couple of screens next to each other had their Warp A set to a nearby dungeon's entry screen. All of these mix-up warp screens led to either dmap 3 or 4 and were shops there. Warp B/C/D destiantions and non-shop destinations (even if they led to dmap 3 or 4) weren't affected. Strangely, since I never thought ZC would differentiate warps according to the destination screen had shop in there or not......
A main problem is also because I don't know WHEN it happens. In ZQ or while playing ZC? If while playing in ZC, it's catastrophe, because then the more time the player played, the bigger the chance is that some warps got mixed up.
(and no, I didn't even touch the screens and dmaps related to that bug... UNLESS... I think I copied...
Oh man, don't tell me it's because I copied those screens and set the resulting screens with "Edit -> copy certain element -> layers" or such... In this case whenever I copy a screen is a warp destination, I need to check that still the correct screen points there...
I hope it's so, because the text I lined out in this post is what is correct (so, if it's randomly happening) that's a sure destruction for huge quests that are full of warps... I sure hope it's just some copying error)
Posted 28 September 2013 - 05:02 PM
What a confusing post, Castchaos. Can you explain exactly what the bug is and how it occurs? Or does ZC do that randomly?
Edited by Avataro, 28 September 2013 - 05:03 PM.
Posted 16 October 2013 - 07:02 PM
It looks like a new version of Zelda Classic 2.50.1 RC1 is being worked on, which means more bugfixes on the way for us all. Might there be a build of it soon?
Posted 16 October 2013 - 08:20 PM
I don't know how I never seen this. I will download it so I can be up to date. lol
So, this is just me being a brat. lol. But if there is a future release this is my two most wanted things:
1. 512 pages of Tiles.... I am like out of room on Chapters of Enova... I know, I should delete some... but I have been working on this 8-bit tileset for years and I am trying to avoid it. :/ 256 pages isn't enough for me apparently. lol
2. A screen data entry: Link's position. You can manually put Link's position on the map. Thus, when using warps, Link's position actually will be in the place you want it to be.
/me runs from getting mauled.
Posted 16 October 2013 - 08:23 PM
If there is anything happening with 2.50, it should be 2.51, a bugfix or minor update to 2.50, but I have not heard anything on this beyond some talk about a 2.51 update to std.zh, the standard ZScript header. I would advise Gleeok to number it accordingly (2.51, not 2.50.1), to avoid confusion.
RC means 'Release Candidate'; 2.50 Final is past the 'candidate' series: it is a final release, and 2.50.1RC1 is too easy to confuse with 2.50RC1, whereas 2.51RC1 is notably a versioning update.
There are only a few bugs that could be easily removed from 2.5, including the arrows hex value bug, and a couple enemy (e.g. Patra hitbox) bugs. it looks as if the arrows hex value is one of the things that has been resolved. I would estimate this is a housekeeping update, and that you should (1) expect no new big features--despite desiring some--, (2) expect that some enemy changes may occur, that may change your quest difficulty if you rely on their old operation--and again I suggest making an enemy editor addition to retain these bugs if desired, to avoid this kind of problem, as I did with Lanmolas--and (3) that a build will be released, when it is released.
Most of the things targeted with this kind of update do not affect most quests, so there is no reason to avoid using 2.50 while waiting for this.
I will note that I experienced the following oddities:
(Bug) System Colours, used on subscreen counters can vanish if some enemy types are used on a screen. I know that teal was one of these, when used in combination with Gleeok, Digdogger Kid, BS Dodongo, BS Aquamentus, and some other enemies. It may be a CSet issue with those enemies, or some other oddity or quirk.
(Bug) Enemies with large segment counts: You can kill middle segments and have aft segments dangle around a room. I don't know if this is what you (Gleeok) mean by 'Parts of segmented enemies are killed in unexpected ways'.
I also will add my comments on existing changes:
Peehats are supposed to be vulnerable to clocks, in Z1. Any alteration to this should be an enemy editor selection, or a quest rule. In fact, clocks could be an enemy editor vulnerability item in general, for all enemies, to fine-tune if an enemy (even a boss) can be affected by them. I know that I rely on the peehat clock vulnerability in my game
What is the reason for this?: * - Only one instance of ZC may run at a time (Windows and Linux only so far). I intentionally run multiple instances, for testing games. Is it due to .sav file corruption from multiple resources using it?
Why do these classes exist at all?: * - Added help text for the Bow & Arrow and Letter Or Potion classes and made it clearer that they shouldn't be assigned to items (Saffith, 2013-09-04 08:51:59)
Small Requests:
It would be nice to have a feature to view what slot each FFC and Item script inhabits without recompiling. (e.g. Quest->Scripts->View Slots)..
Enemy Invisibility: Allow for the cross to reveal enemies set as Invisible in the enemy editor (either as a quest rule, or as an enemy attribute 'Revealed by Cross').
Moderate Requests:
Link->Knockback by 0-Power enemies set as a quest rule; if Link is hit by an enemy with 0-Power, should he be stunned, knocked back, make an 'ouch' noise, and flicker? Off by default; enable to disable Link HurtFX by 0-power enemies. Useful when using enemies for certain kinds of effects.
Link->NoKnockback by any enemies, set as a quest rule. Disable knockback and standard hurt effects, set to off by default; enable to disable Link HurtFX from *all* enemies. Useful for platforming quests.
Posted 24 October 2013 - 11:39 AM
Link->Knockback by 0-Power enemies set as a quest rule; if Link is hit by an enemy with 0-Power, should he be stunned, knocked back, make an 'ouch' noise, and flicker? Off by default; enable to disable Link HurtFX by 0-power enemies. Useful when using enemies for certain kinds of effects.
Indeed. Nothing more frustrating than getting killed via kinockback-into-death-pit... by a red skeleton pile!
Small Requests:
It would be nice to have a feature to view what slot each FFC and Item script inhabits without recompiling. (e.g. Quest->Scripts->View Slots)..
In the FFC properties editor and in script-related tab in Item editor each entry in script list has a number in brackets that shows which slot occupied by the script.
Edited by Alucard648, 24 October 2013 - 11:48 AM.
Posted 25 October 2013 - 01:15 AM
Actually, I've been considering having walking enemies with 0 attack power as just random people walking around in a town. My only problem was that it would show Link getting hit even though he wouldn't take damage. It seemed a little weird that all the random citizens of Hyrule would be so rude as to knock their Hero flat on his rear on a regular basis for just standing in their way, though.
Posted 25 October 2013 - 10:35 AM
Well, if you wanted you could attach a script to them to set their npc->CollDetection to false.
Posted 26 October 2013 - 12:07 AM
That one was fixed, but it's possible there's still another bug altering warp destinations. If you can confirm it, send me an affected quest and I'll see if I can figure it out.In 2.50RC2 (or even in RC4, I don't remember) I had it so in a quest that almost all of my Map 4 warps got set to the bottom row of that map, but staying on the same dmap.
You're using CSet 14, presumably. Those enemies all use an extra sprite palette CSet, and that's where it's loaded.(Bug) System Colours, used on subscreen counters can vanish if some enemy types are used on a screen. I know that teal was one of these, when used in combination with Gleeok, Digdogger Kid, BS Dodongo, BS Aquamentus, and some other enemies. It may be a CSet issue with those enemies, or some other oddity or quirk.
They aren't in the NES game. I could add a compatibility rule, I guess...Peehats are supposed to be vulnerable to clocks, in Z1. Any alteration to this should be an enemy editor selection, or a quest rule. In fact, clocks could be an enemy editor vulnerability item in general, for all enemies, to fine-tune if an enemy (even a boss) can be affected by them. I know that I rely on the peehat clock vulnerability in my game
The issue with save files being wiped was a direct result of running multiple instances simultaneously. I could make it optional.What is the reason for this?: * - Only one instance of ZC may run at a time (Windows and Linux only so far). I intentionally run multiple instances, for testing games. Is it due to .sav file corruption from multiple resources using it?
So that those things can be put into the same slot in the subscreen.Why do these classes exist at all?: * - Added help text for the Bow & Arrow and Letter Or Potion classes and made it clearer that they shouldn't be assigned to items (Saffith, 2013-09-04 08:51:59)
Yeah, it would. Probably not hard to add. For now, you can use the ASM script import dialogs.It would be nice to have a feature to view what slot each FFC and Item script inhabits without recompiling. (e.g. Quest->Scripts->View Slots)..
Posted 31 October 2013 - 03:33 AM
I will need to verify the NES release, but I am mostly sure that they do affect Peahats. I am almost positive that they do in the Japanese (FDS) release, and I don't see why they would have changed that for the cartridge version. The manual states they are affected by clocks, although we all know that the non-JP game saw some changes.
I would very much appreciate if Clocks could become an enemy editor defenses option, as this would make it much easier for the questmaker to fine-tune what can be affected by them, especially for those like myself,who use clock-item spells with a limited duration.
Is there any chance to add that 'Cross Negates Invisibility' to the enemy editor to act in conjunction with the enemy-editor 'Enemy is Invisible' option? I would really like to avoid needing to Ghost every enemy type just to have this option in quests.
Placing 'Can load multiple ZC instances' in prefs, or in ZLaunch,would be best. For questmaking, having multiple instances can be important, but not when playing games.
We really need some documentation on the Bow & Arrow, and the Letters & Potions classes. The Wiki doesn't go into detail on these... I requested to be given Wiki editing access, but received no response whatsoever, and I'd be happy to start updating and expanding topics. (I am a technical writer, after all, so this kind of work is my cuppa, and the Wiki needs fresh staff.)
The CSet 14 thing should be in the Wiki too... Does changing the enemy sprites to 8-Bit fix this issue, or is there a way to use System Colours/CSet14 without it changing colour values?
I would not have expected the System Colours CSet to change colour values like this, especially to black. It really has useful colours by default for subscreens and menus, and it's quite unfortunate that we can't actually use them. To my knowledge, there are few applications of the System Colours swatches.
Posted 31 October 2013 - 08:57 PM
The grabber.exe program used for editing sfx.dat files is kind of old (and AVG thinks there is a virus in it.) Would it be possible for its functions to be in ZQuest itself?
Posted 31 October 2013 - 09:16 PM
Why do you need sfx.dat? ZC 2.5 lets you import/modify custom sound effects and save them with your quest; no sfx.dat swapping required.
0 members, 0 guests, 0 anonymous users