899 replies to this topic

[Lejes]

Why Ax?  It's what I've been doing to let scripts talk to each other.  So, I don't want to set a million FFCs on each screen.  I want to set a single FFC that will then set up a bunch of other FFCs according to values I give it.  As far as I know, a script can assign another script to another FFC -- but it cannot write to the variable fields of that FFC.  Bummer.

 
You actually can! The comments above ffc->Script explain how in detail, but in short, you pretty much just set ffc->InitD[] on the same frame you change ffc->Script. That will let you access the 8 D# variables whenever you change an FFC's script.
 

Aaahhh you must be on the latest 2.5. They depreciated ffc wide global variables, and now I bet they are gone. That would explain what you are seeing!

 
Could you explain what you mean by that? I don't see anything about it in the changelog.
 

I'm concerned that the hit boxes for custom enemies are a bit squirrely, though, and for some reason I can't fathom any living custom enemy on the screen prevents you from using doors until they're dead.  There's no interaction between the codes on my side, so it must have something to do with how Zquest thinks about applying Stair combos assigned as FFC->Data while other ffc scripts are running.  
 
Arrrgh.

 
I'm not sure what causes this, but I've seen a very similar problem with butterfly FFCs in Jamian's new quest, Forbidden City. They presumably have scripted movement, since they seem a bit complex to rely solely on changers, and you can't enter doorways if one is on top of you.

[C-Dawg]

It's not that.  I've known for awhile that FFCs under the player "cover up" any stair combos on the screen.  My custom enemy code should NOT be putting any combos under the player.  So... I'm really confused about why it's turning off my doors.

 

EDIT: No luck on the weirdo door problem, but I've added a few more complicated enemies and finished Aquarius up to the entrance to Scorpio.  At this rate, replacing all the regular enemies in the game alone is probably a month long job.  Yuck-o!  Oh well, at least it seems to be working ok except for the doors.

Edited by C-Dawg, 04 March 2015 - 12:42 AM.

[Solairflaire]

I had a bunch more stuff than this, but somebody posted most of them already...

 

Gemini 3,1: Switch disappears when struck.

Gemini 0,0: Could you move the Heart Tank out of the way. I always waste this one when I get here since I have 9 already.

Gemini0,4: You can still get yourself into the left wall that appears when Iron shows up and cheese out the fight. It's kinda precise now. You should make it so that the trigger goes across the screen below the entrance.

 

Libra 3,4: If you shoot the entrance on the left where the secret comes in, it blows up and reveals "secrets" in that area.

 

Cancer 7,3: Can't get out with just Double Jump.

 

Taurus 0,7: The enemies stay gone after you kill them so you can't freeze your way up. Need to damage boost from lava to move on if you do that. It's also incredibly difficult to freeze any thing in the little area you need to.

 

Leo 5,C First Screen of Cutscene: If you go left before they start talking, you end up in a blank room that you automatically go down off the bottom and end up back on that screen. Doesn't change anything, just there.

Leo 5,E Cutscene: I'm not sure which scene it was. But, I was able to scroll the screen left on one of them between dialogue. It was one of the later ones, I think when Iron takes action or around there.

 

Aries 1,C: No reference on switch.

Aries 1,A: Can't get out unless you have wall cling. Recommend a grapple point by right exit.

 

Libra Crystal weapon: Firing up has the two diagonal shots go down, not up. Also, the charge part can erase certain tiles. I only did it on corridor but I'm sure there are other tiles this can be done to. If you use it on a corridor entrance, it erases part of the entrance and prevents you from going through. Leaving the screen and coming back fixes this.

[newstarshipsmell]

Perhaps these are both intentional, and if not, acceptable/not bugs?

If you charge your Zodiac weapon with too little energy in your meter, it simply drains it to empty and then stops charging, wasting the energy. Does your energy recharge get suspended while ZW charging drains it, or does it add to your meter as the charging subtracts from it? A couple alternatives:

Suppress the charging ability while the current energy level is below the required amount - either it begins charging as soon as you recover enough energy and button state is down, or you must release/depress the button again after it recovers past the threshold?

Have it count how much energy it's drained, and if your meter reaches 0 before finishing, abort the charge as it does now, but add the drained energy back to your meter. If the meter isn't recharging at all while charging the weapon, this would force the player to avoid spamming it while low on energy, as this could effectively put them in a loop of continuously trying to use it, failing, trying to use it again, and massively slowing how quickly they regain energy. Not quite as effective if the meter recharges (slowly) against the ZW charging drain.

You cannot shoot your charged Zodiac weapon while suspended from a grapple hook. You can charge it up, but you must release the Grapple Beam to fire it. Releasing the ZW button after charging it will maintain the charge, until you release the grapple, when it immediately fires. Not sure if it fires in the direction you aimed when releasing the ZW button, or in the direction you aimed when releasing the Grapple button.
ETA: Hrmm, it's more complex than this. Testing...

B: Zodiac A: Grapple
Aim and press/hold A to grapple a hook.
Press/release B to shoot your ZW. You'll fire a regular shot AND begin charging. You can continue firing regular shots as you charge, as well as after you've finished charging, and you'll retain the charge, so long as you're still holding A to grapple the hook.
Once you've charged, if you hold B down and release A, you'll fire your charged shot, while remaining grappled. Releasing B at this point will release your grapple beam and you'll fall. If, instead, you hold A again before releasing B, you'll remain grappled, and you can press B again and release it to fire a ZW shot and begin charging it again.
Similar behavior occurs if you begin charging, or fully charge it, before grappling. If you're holding B down when you press A, you do not have to hold A to maintain the grapple beam, so long as you keep B depressed.
If you charge up, and fire your charged shot by releasing A, it'll fire in the direction you're aiming at the time you release A, rather than the direction you aimed when you released B while charged up.

B: Grapple A: Zodiac
Similar behavior as before, with some differences:
You must hold A to charge it - you cannot simply fire a shot and have it autocharge for you, as it does above.
Once you've charged, you'll fire the charged weapon as soon as you release A, rather than when you release the grapple beam (assigned to B).
As above, holding A allows you to press B without holding it to grapple, or release B while grappling, and remain grappled.

ETA: Regarding the above, I vaguely recall noticing other bugs with various weapons/items, by pressing/holding A, pressing/holding B, releasing A, and vice versa. So presumably this is due to how ZC works, rather than how you've designed your inventory items, and you may be limited in addressing this issue.

ETA2: Actually, that reminds me of another bug that I'm not sure I mentioned. Sometimes when I press a button, it either triggers the item assigned to the other button, or the item that I've just swapped out on the subscreen. It happened semi-frequently to me before, and if I remember, seemed to mainly happen right after exiting the subscreen, or right after closing a message string or YES/NO prompt. It didn't happen too frequently, and I couldn't reliably reproduce it, so I forgot about it. Not sure if that's an engine bug, or a quest bug.

Edited by newstarshipsmell, 04 March 2015 - 02:13 AM.

[Lejes]

It's not that.  I've known for awhile that FFCs under the player "cover up" any stair combos on the screen.  My custom enemy code should NOT be putting any combos under the player.  So... I'm really confused about why it's turning off my doors.

How are the doors implemented? Are they an FFC script? Does it use a stairs type combo? If both the doors and the enemies are FFC scripts, is it possible they're overwriting each other by trying to use the same FFC?

[Jamian]

 
I'm not sure what causes this, but I've seen a very similar problem with butterfly FFCs in Jamian's new quest, Forbidden City. They presumably have scripted movement, since they seem a bit complex to rely solely on changers, and you can't enter doorways if one is on top of you.

 

I've noticed that as well and will release a small update to fix it. Checking the FFC's ethereal flag does the trick. It makes ZC ignore the FFC's combo type and therefore it can't accidentally cover other combo types (like stairs) anymore.

Edited by Jamian, 04 March 2015 - 07:10 AM.

[C-Dawg]

RE: The Door Problem

 

So the way I have doors implemented right now is that there is an FFC on every screen of every sidescrolling level of Zodiac running a script called "JUMP,"  It has Data (combo) set to 1. This handles all the sidescrolling mechanics like jumping, wall clinging, sand-falls, and doors.  When a player is in front of a door combo and pushes up, the script moves the FFC on top of the player and changes its Data (combo) to be a stair combo.  It does not mess with any other FFCs  for this purpose.

 

The general enemy script functions this way.  Each screen runs a script that has data fields allowing me to specify enemy IDs and the number I want to spawn.  That script runs once when the screen loads and then terminates.  It goes to look at all the FFCs, starting with FFC 2, and looks for one that has a Data (combo) of 0.  In other words, one that is not in use.  When it finds one, it takes that FFC and assigns it the "I'm a sidescrolling enemy!) script and tells it what enemy ID it should be.  The newly reborn FFC now begins to run its own code, finding a spawn place and then performing the blocking assigned for that character.

 

There SHOULDN'T be any way for the scripts to interact.  JUMP only modifies its OWN FFC, and the enemy script only modifies FFCs with Data->0, which JUMP does not have.  

 

...with one exception, perhaps.  The enemy FFCs are designed to be whatever shape I want.  To do this, I handle hit detection this way.  Each enemy consists of one FFC that functions as the enemy itself, and a second one that is an invisible damage combo.  Every frame that the player is not within the hit box of the enemy, the damage combo is stashed offscreen.  Once he is there, the damage combo is moved on top of the player.  That doesn't appear to be a problem because (1) I'm not taking damage when I try to go in the door and (2) the damage combo is being moved off screen on all frames except the one where it's hitting her.

 

Nevertheless, obviously something is gone awry.  I think the first thing I'll do is change the way the door code works to simply warp you where the tile warp data tells you to go.  Then, we'll see if it's really just something getting in between the player and the door combo.

 

RE: Passing Variable Fields

 

Really?  You can do this now?  When I revamped the code to re-start development on Zodiac last summer, I was told assigning a Script wiped the variables clean and you could not assign them using a script.  If that's changed, awesome!

 

RE: Charge Weapons and Grappling

 

Interesting stuff you're finding there, Starship.  I suppose this is more than a corner case, because there's one boss in particular who expects you to be firing while grappling.

 

So here's how the charge code works.  When you fire a Zodiac weapon, the script that fires the bullet also sets a few variables.  It sets one saying which weapon you fired, one saying you've fired SOME weapon with a charge, and another one saying whether you are pressing A or B.  Then, the global script constantly checks to make sure you're still holding down A or B, whichever you were when the charge started, and fires only when you release that button.

 

What you've done is tricked the code because you're holding both buttons down at the same time.  So it's not clear which one is being passed to the global function to watch for.  

 

I could fix this IF I was able to check which slot - A or B - the Zodiac weapon was assigned to when it was fired in addition to which button was pushed.  I think I have a way to do that.  I'll check zscript.txt and get back to you.

 

RE: Changing How the Charged Weapons Use Energy

 

Yeah, I had this thought.  The way it works now is that you just dump energy into your charge, and if you run out before the charge is done you waste the energy.  There's an argument to be had for keeping it that way, namely, that it requires the player to be spending some brain power paying attention to the amount of energy they have before beginning a charge.  

 

The counter-argument favors not letting the charge start unless your energy was sufficient to charge it in the first place or, as you say, giving energy back if the charge fizzles.  Two problems with that.  First, because it charges over time, having enough energy to start with is no indication that you will have enough when you're done.  You might dash or fire an Ice Beam or something in the midst of the charge.  Second, if you get the energy back if the charge fizzles, you can game the system by starting your charge, using your energy for something else like a dash, then fizzling it to recharge your energy in a flash.

 

Given all of that I think I like the current set up best.  Besides, it seems more flavorful - do you want to dump your energy into your main weapon?  Okay, go for it, hope you did the math right.  Nothing more embarrassing than launching your rocket HALFWAY into orbit, eh? 

 

Never fear, though.  The rate at which your charge weapon charges is actually canceled out almost entirely by the Level 3 Energy Dynamo.  Once you get that, you should be golden.

Edited by C-Dawg, 04 March 2015 - 11:36 AM.

[newstarshipsmell]

Yeah, I was just brainstorming with alternate charge fizzles - there's nothing wrong with it now, and the points you raised (and I hadn't considered) are good ones.

Anyways - as far as other A/B glitches like that, the only one I could think of is the Ship Cannon - it autofires, so if you depress the other button and release the cannon button, it continues firing until you release the other button.

Also, I remember that the Grappler 2 lets you zip across the corridors near instantly - just shoot it at the opposite wall (or top/bottom) and hold R. You'll grapple to the side of the corridor and dash across.

As I'm sure you know, Grappler 1 does similar things with L / R depressed, in the Labyrinth. Holding L will cause you to ascend faster (possibly only on shots straight up) and R will add your dash to the speed the grappler pulls you in. Not sure if that was intentional, something you're fine with, or got overlooked.

ETA: I've also seen a weird glitch with the Aries entrance, that I believe I vaguely recall also experiencing a while back.
In Aries 77, if I approached it and jumped up, bouncing off the top of the entrance, and holding up while I fell into it, I would warp either next to the Aries entrance at Aquarius 36, or directly on top of it (not sure which, as I can't reproduce it now.)
The Aries entrance would then fail to warp me to Aries 77, regardless of whether I walked across it, stood on it and pressed up, and left/returned to the screen. The only way to restore it was by F6/continuing.
I was able to do this over and over, but I could not cause the Aquarius entrance at Aries 77 to do the same thing.
I tried it on the Scorpio entrance at Aquarius 0B/Aquarius entrance at Scorpio18, and was unable to replicate it.
So I returned to Aquarius 36, and was also now unable to replicate it there either.
I had (probably) enabled Cheats when the bug first appeared, but I wasn't actively using any cheats when it happened. I tried enabling Cheats again to see if that let me replicate it, but I still can't.
Weird.

Edited by newstarshipsmell, 04 March 2015 - 01:24 PM.

[Lejes]

RE: Passing Variable Fields

 

Really?  You can do this now?  When I revamped the code to re-start development on Zodiac last summer, I was told assigning a Script wiped the variables clean and you could not assign them using a script.  If that's changed, awesome!

 

I think the order on this is:

1. ffc->Script is reassigned

2. ffc->InitD[] is wiped

 

InitD[] apparently is only read when the script starts, and those values get stored somewhere else for later use (i.e. changing InitD[] will have no further effect). You can reassign values in the InitD[] array immediately after ffc->Script is changed and it will work.

ffc f = Screen->LoadFFC(1);
f->Script = 10;
f->InitD[0] = 140;

This is a bit of code I used to change the string argument on an NPC script after a certain condition is met, and it works. 10 was already the number of the script it was running, but you need to reassign anyway if you want InitD[] to be useful.

[justin]

 

I think the order on this is:

1. ffc->Script is reassigned

2. ffc->InitD[] is wiped

 

InitD[] apparently is only read when the script starts, and those values get stored somewhere else for later use (i.e. changing InitD[] will have no further effect). You can reassign values in the InitD[] array immediately after ffc->Script is changed and it will work.

ffc f = Screen->LoadFFC(1);
f->Script = 10;
f->InitD[0] = 140;

This is a bit of code I used to change the string argument on an NPC script after a certain condition is met, and it works. 10 was already the number of the script it was running, but you need to reassign anyway if you want InitD[] to be useful.

 

that's exactly what the RunFFCScript from ffcscript.zh is doing.  you can write to InitD in the same frame that you load the ffc and apply the script.  an ffc can't write to its own InitD array while running, nor can other ffcs pass data that way.  while an ffc is running the best way to pass data to it is by using the ffc->Misc[] array.

I could fix this IF I was able to check which slot - A or B - the Zodiac weapon was assigned to when it was fired in addition to which button was pushed.  I think I have a way to do that.  I'll check zscript.txt and get back to you.

 

 

from std.zh

 

int GetEquipmentA()

 * Returns the item ID of the item equipped to Link's A button

 

int GetEquipmentB()

 * Returns the item ID of the item equipped to Link's B button

 

check if either of those is your item number, and that you are pressing that button.

[newstarshipsmell]

(I'm still playing on Demo 441, so ignore anything you fixed since then.)

Leo 62: Some of the boss's magnetic ball projectiles do not come to a stop inside the room, and some travel at slower speeds than most of them. Is this intentional?
Anyways, with the new Aries Saber, I can't just spam this boss to death. Had to actually learn how to fight him, finally.

Also, the ZW shots no longer persist across room scrolls, but when you use a door, it freezes the shot in place and you can see it during the warp transition on the far end - then it disappears when you regain control.

Gemini 5E: The bombable block in the lower-left - it remains on the explosion graphic indefinitely.

Edited by newstarshipsmell, 05 March 2015 - 01:11 AM.

[C-Dawg]

Uploaded new version.  Custom enemies implemented up until the explosives in Scorpio.  I also got the doors working again, even with the custom enemies running around.  Check em out.  Let me know if this is having a negative impact on difficulty. too.

[newstarshipsmell]

Demo 441

Taurus 15: This still has enemies that spawn above the top row, don't attack, can only be shot with Ship Bomb, and die off after awhile.
Some of the ships that scroll down the sides occasionally disappear for no apparent reason, partway down the screen.
The enemy with two options circling it - I killed one, and one of the options remained, stationary onscreen, until it disappeared a while later.
The boss still explodes into alphanumerics.

Taurus 68: Stationary fireball enemy.
Taurus 77: Stationary fireball enemy.

Taurus 3D: When boss died, one explosion remained stationary, where it was when it died, and another explosion moved along the path it was taking, and quickly moved off the left side of the screen.
Also, I think after it died, the room I was in lacked the metal platforms on the left/right sides, which are present when you enter, and while you fight the boss. When I moved left, it warped me back to the Labyrinth room with the item, and they were there.

Cancer 42/32: Can still dash/jump from ? block onto low block above, and access the area past the mouth without gaining the Double Jump Boots, which leaves a bunch of F6 traps past it in the following rooms: 43/33, 52, 6C/5C, 7A/6A, 7B/6B.
ETA: You <em>cannot</em> reach Libra entrance without DJBs, though (unless, perhaps, you can damage-boost past where it's required - I didn't try) so you can't wreck the game simply by coming down here and setting the continue point past a point you can't backtrack from.

Cancer 73: F6 trap without the Wall Cling Boots.

Demo 445

Intro Boss: You don't have to hide on the bottom to avoid all his shots - you can hug his nose and also stay out of the path of all his shots. When he shoots the purple orbs at you, you just have to move up/down out of their way. Suggest redrawing his nose/hitbox so it fills the safe spot right below it, unless you want it there. (Keep the first boss with an easy strategy?)

Doors: Room warps no longer switch the music at the beginning of the warp wipe, but switch at the end now. Kind of strange.

Aquarius 6C: This room either spawns one or two flower enemies onscreen. If it only spawns one (onscreen) and I kill it, I can here the other one intermittently firing afterwards.

The walking box enemies that split - the TLOZ enemy they replaced <em>used</em> to drop items from the lesser enemies, but stopped a few demos back, nor do these drop anything. Is this intentional? Does killing them without splitting drop items?

Aquarius 3B: The megaman 3-spread enemy - normally spawns reasonably, but on this screen, it spawned on the bottom row, in the left pit, when I entered from the right. Some enemies, like these, might be put to better use with preset locations per room, rather than spawning semi-randomly.

If you haven't already done so, I'd recommend coding the metroid-droppers so they don't spawn over door exits (or far left/right columns) - would be unfair to come out of a cave room and have one immediately descend upon you (or upon scrolling into a room.) Or not. Also, they seem to sometimes spawn on top of each other; probably would look/sound better if they didn't. They also probably shouldn't drop when you cross their column above them, especially since they don't fire straight up.

A lot of these enemies that walk left/right and won't drop, end up spawning on short stretches that make them kind of lame. Is it possible for them to detect whether dropping off the edge of a platform would drop them to another platform, rather than off the bottom of the screen, and let them drop in the former case?
ETA: The giant robot that drops more robots is especially bad looking when he spawns on a 1-tile-wide platform, as he spastically faces left/right over and over again.

Aquarius 49: I killed the boss while standing between where the two bottom blocks form - so I got stuck after he died. If you move them up and left one tile, they won't be on the floor; you'll simply fall out of any that don't have a floor directly underneath them.

Aquarius 35: This room has no enemies in it now.

Aquarius 47: This room has a mix of old and new flower enemies - which looks/sounds weird, since the old ones shoot silently, and straight, and can't penetrate walls with their shots. Not sure if you meant to get rid of all the old ones - not sure if I've seen any others in the area.

Aquarius 40: Still cannot backtrack here without High Jump, descending here forces you to explore Scorpio or F6.

Aquarius 38: Still has a couple invisible half-tiles on the left side.

Scorpio 17: Upon purchasing the item in the cave room, the glass container disappears, rather than breaking open (the item still drops properly.)

Scorpio 13: Screen only has two sand vortex enemies on it, nothing else.

Scorpio 23: Cave room warp exit on top of half-tile cactus near right side. F6 trap.

Scorpio 20: Cactus enemy. Potential, but lame as-is. Bug: each time you destroy a segment, he drops a half-tile downwards, and becomes stuck, if he even had any room to move left/right before.
Suggest saving him (and/or editing this room's layout) for wider, open spaces. Maybe code him to ignore/move through the cacti? Perhaps make the cacti and this enemy look similar, and have him dormant like the metroid-droppers, and triggered by player proximity? (So that the only difference would be the heads look different, and triggering him would cause him to open his eyes and shoot upwards to his full height, and begin attacking?)

Edited by newstarshipsmell, 06 March 2015 - 01:33 PM.

[C-Dawg]

So I coded up a few new enemies but then I had some wine for the first time in a million years.  So, now I'm gonna call it an early night.  More tomorrow!

 

EDIT:  Uploaded new version with lots of new enemies.    No bugfixes, but I'll catch up with you this weekend.

Edited by C-Dawg, 07 March 2015 - 01:29 AM.

[newstarshipsmell]

EDIT:  Uploaded new version with lots of new enemies.    No bugfixes, but I'll catch up with you this weekend.

Hasn't gone live yet, but I'm looking forward to it! The new enemies are okay to good so far; overall, an improvement over the previous default enemies.

Demo 441

Libra 34: Shooting the hole on the left side causes it to explode, and all the slippery blocks to vanish.

Libra 10: F6 trap, possibly. The warp hit me as I was right next to the left alien. It warped me inside the 1x2 ice pillar below the alien in 22. I walked out to the right - not sure if walking left would let you walk underneath the tail, fall a block, and end up stuck.

Libra 42: Triggering switch causes all the slippery blocks to explose/disappear. Intentional?

Libra 4E/4F/5F: F6 trap. You can jump/dash through the spikes in 4E, then fall down 4F into 5F; without WCBs, you cannot backtrack to 4F.

ETA: So swapping 443 (first demo w/custom enemies) in place of 441 screwed up my Sidearm upgrades. I started a separate gamesave on 445, and got as far as the explosives. Can I swap 449 in place of 445 and resume, or am I going to need to start fresh gamesaves on each subsequent demo as you add new enemies?

Edited by newstarshipsmell, 07 March 2015 - 11:03 AM.