This is it. No betas, no release candidates. See shardstorm.com (since build 1703) for changes since 2.50.1.
Downloads
Printable View
This is it. No betas, no release candidates. See shardstorm.com (since build 1703) for changes since 2.50.1.
Downloads
I just want to know if there's script or quest compatibility issues or if the old statue behavior can be re-enabled via a quest rule.
https://www.youtube.com/watch?v=_J6-3l3hCm0
Now if we can all just agree on what to do on encryption or those who disagree with the majority take a vow of silence we can finally open source this. "Provided we don't have a consensus yet."
Note that the text above is a joke, and I've received a PM confirming a general consensus yesterday.
That's nes behavior, so it will probably be found in NES Fixes
Actually I'm currently brain storming on doing something rather interesting about this, 2.50.x can use the quest rules that no longer exist however, there's a slight problem and it's a pain in the ass.
Problem: Backwards Compatibility
Solution: We use the deprecated constants from the enum when we run out of room however these have a purpose as they configure how the quest works until you load it ZQuest 2.50.x. That being said they pretty much become worthless at that point and we have access to them as they serve no purpose in builds after they are removed.
The problem is that things like that can seriously screw with the quest makers ability to challenge players.
@Anarchy_Balsac
Provided this is directed at me and not saffith, actually you cannot activate the deprecated quest rules in 2.50.x. They only exist for backwards compatibilty. THe ones that gave us sparkles and disabled sword beams for example still exist in quest rules.
1. Check the quest's version number to enable old feature or new feature when loading it quest in player.
2. In the editor when a older quest is loaded it must be manually saved now, as it always should be. And it re-configures the quest rules and data for the quest. "Whether sparkles are set up not for example. that was a quest rule back in the day. Actually it was four"
3. We now have access to more bits for quest rules.
Note that will be a long a tiresome process, and I sure in hell ain't started on this until we get this stuff open-sourced. Shouldn't be too much longer though.
It was directed at Saffith, LOL. But from what I gather, there is not currently a way to re-enable the old statue behavior.
That rule should be called "Benevolent Statues". :P
Actually, it might be better as an enemy misc value.
Agreed. An enemy editor value would be best, to allow selective settings, and set by default to the old behaviour. There are puzzles in several quests that require reflecting at close proximity, that this would break. I wish I noticed that sooner...on Shardstorm, as it is indeed a problem.
Random double-shot should also be an enemy setting.
Things like that are a good argument for never skipping Gamma phase.
Sounds like a fast fix is needed then.
And really, ANY enemy buff or nerf should come as an option. I don't know why it didn't occur to anyone this would unbalance quests.
These were bug fixes. They were always supposed to do those things. The distance check has been there all along; it just didn't work right. They actually have been firing double fireballs, but it's been almost unnoticeable because the fireballs have been in the same place instead of slightly offset.
Fine, I can make these rules. In the meantime, you could always script them. They're pretty simple.
If the fireballs weren't offset, and would impact simultaneously, how did the engine determine damage and priority for them?
Did both induce damage, or was there some 50/50% on which one was in charge of the collision? Seems a bit OT, I know, but it's a question that has arisen before, regarding simultaneous collision, and I don't have a satisfactory answer to give people (e.g. scripters, notably Moosh asked me out of the blue a while back).
You can override invincibility frames via scripts. I've done it, and I even made a header for it.
Nope, first collision takes priority every other weapon will just die as usual on collision except for ones that persist such as explosions.
ZoriaRPG, I believe the first collision triggers Link's "invulnerability" phase, so the second fireball strikes and does nothing because Link is temporarily invincible.
EDIT: Since the projectiles on screen are indexed just like enemies, that would mean the first fireball created gets to do damage, then invulnerability is triggered and the second fireball does nothing. This is the same as hitting a bubble to evade an enemy attack--the 0 damage hit triggers invulnerability provided it has a lower index than the enemy attack (on a one frame double collision).
Rather than make it a quest rule, could this be made one of the miscellaneous features of a shooter enemy? Maybe make it a distance variable, with 0 overlapping the two projectiles into a single shot. This would let quest makers define how much the fireballs are offset, to create some unusual 'bullet hell' situations with the build-in engine. It would also save a quest rule, which Saffith said was a nearly exhausted list.
Also, sweetness on the new version, good work ZC Development team!
It would require creating a script that times the shooting precisely to that of a shooter enemy, and must be done for every screen and every statue.
Wouldn't work for Zelda 4 anyway, because there's a weapon that can disable them. This means, if it's not done based on an NPC locations, the weapon will no longer disable shooting statues. And if IS done based on NPC locations, I'd have to first figure out what NPCs are what, and upon statue nuetralization, can actually make shots happen from a non-statue enemy.
I'm sure there's a way and all, but it would be TONS of work, what with all the testing and stuff I'd have to do. I get that this is how Z1 used to work, the problem is that ZC HASN'T done it for so long that it's now a "fix" that will break many quests.
no just ask a developer to script shooters from scracth for you.
it's 1 in 128 btw right saffith?
Even doing that creates another problem. Shooter type enemies are the only type that doesn't collide with the player. So you can make a stationary "other" type enemy that shoots, but it would either turn the statues into damage combos, or mercy invincibility exploits (if the collision damage is set to 0).
Here's another hint...
Use a shooter type but change the weapon to none.
That is what I would expect, and probably what is supposed to happen, but apparently not what Moosh experienced with simultaneous hits. I suspect that damage is calculated before the invincibility frames occur; and in some circumstances it can be applied from more than one source. In fact, I told him that the second collision shouldn't count, for just those reasons...but seemingly it can.
@CJC : That's always going to be true, because the hits do not occur in the same frame.
It's not that important, but at least I remembered to ask.
@Moosh Get your arse over here, and detail that problem you had with simultaneous collisions with your 'Death' enemy.
Okay, so it was a dark and stormy night...I was scripting a scythe swinging attack for a boss in Freedom in Chains. The attack had a slash animation made up of about 20 gradually shrinking circle draw commands. I wanted the whole thing to have collision, so I put weapons of approximately the same size under each circle and used ghost.zh to make them only last for one frame. I assumed it would only hit Link once per frame, but in testing it was an instant kill, way more than I'd set the weapons to deal. I figured ZC combines the damage of every weapon colliding with Link in the frame he gets hurt and so I switched to scripted collision instead. With only one weapon being created under Link when he collided with the attack, it worked fine.
I'm checking, as I remember something about circular collision, and I never saw your code. Often, circular collision looks like this:
...but as you say you used ew->Power, my original point stands, as this may be something that needs examination.Code:if ( CircularCollision(ew->x, ew->Y, radius1, Link->X, Link->Y, radius2) Link->HP -= val;
It's ew->Damage, isn't it? Itemclasses are the ones that use Power I thought. But anyways, yes, I did use a weapon with ew->Damage.
Also, crossposting from the PureZC thread:
I wrote a global script for the old shooter behavior in case anybody else is rustled by the change like Anarchy_Balsac was. Just set the Shooter (Fireball) enemy's weapon to none, put the function in your global script, and your shooters will once again have no mercy.Code:const int NPCM_SHOTCOOLDOWN = 0; //NPC->Misc used for fireball shooter cooldown
const int FIREBALL_SHOOTER_COOLDOWN = 80; //Duration of fireball shooter cooldown in frames
const int FIREBALL_SHOOTER_CHANCE = 64; //Chance of firing every frame
void UnforgivingShooters(){
for(int i=1; i<=Screen->NumNPCs(); i++){ //Loops through every enemy, every frame. If you have an enemy loop in your global already, you'll want to combine them
npc n = Screen->LoadNPC(i);
if(n->ID==NPC_SHOOTFBALL){ //Detect the fireball shooter
if(n->Misc[NPCM_SHOTCOOLDOWN]<=FIREBALL_SHOOTER_COOLDOWN){ //Increase the shot timer until the cooldown is over
n->Misc[NPCM_SHOTCOOLDOWN]++;
}
else if(Rand(FIREBALL_SHOOTER_CHANCE)==0){ //Once the cooldown has ended, has a random chance of firing a weapon every frame
Game->PlaySound(SFX_FIREBALL);
eweapon fball = CreateEWeaponAt(EW_FIREBALL, n->X, n->Y);
fball->Angular = true;
fball->Angle = DegtoRad(Angle(n->X, n->Y, Link->X, Link->Y));
fball->Dir = AngleDir4(Angle(n->X, n->Y, Link->X, Link->Y));
fball->Step = 150;
fball->UseSprite(17);
fball->Damage = n->WeaponDamage;
n->Misc[NPCM_SHOTCOOLDOWN] = 0;
}
}
}
}
That is correct, power is from itemclasses and it's writable too but isn't saved.
And good job @Moosh , I'll cross check it with the source for yeah.
http://2.bp.blogspot.com/-DGGcdZ4KYb...hrough-you.png
@Gleeok
Let's put my theory to the test shall we.
Code://Only new quest rules that make use of deprecated quest rule space should use this. -T
int get_questrule(byte *bitstr,int bit,zquestheader *Header)
{
if(Header.zelda_version < 0x253) //didn't exist yet, and these probably did. so we can't chance it.
return 0;
else
{
bitstr += bit>>3;
return ((*bitstr) >> (bit&7))&1;
}
}
Let's not complicate things prematurely. We don't have a lot of bits, but we're probably not going to run out.
Yeah once we run out then we can do this. This is to make sure this solution I mentioned earlier would work.
Also I guaratee you'll run out once I finish implementing the unimplemented stuff. Since some of that requires quest rules. Such as making the wand chargeable which for once does not require adding a lweapon. (don't ask)
Thank god the canes,wands, and candles are different types internally although zscript treats them as the same ID for simplicity sake.
... But all that would be a whole new version, so we could just add more rule bytes.
In any case, I'm really hesitant to add major new features right now, because it's so hard to do it without breaking things.
Yeah, me too omae, me too. Some of my plans are for when the source are released, others not so much. "most of which is bug fixing, I keep an eye on that part of the forum for a reason."
Tell me about it. It still makes me sad how much you can break something by changing just one line of code. :(
what name do I enter for the 5th quest?
where can I find the power bracelet in the 5th quest?
where in the 5th quest can I find the recorder?
i am tring to find the secret in level 4 "Zol" it says it is in the eye of zol, which one?
Full screen options not working for Mac version.
Zquest editor won't go into full screen while Zelda Classic crashes everytime I try to go into full screen. Will this be fixed before it goes on the website?