899 replies to this topic

[C-Dawg]

Cool, thanks.  I can't edit the project description, it seems, but I removed the reference elsewhere.  

[ShadowTiger]

I can. I'm PMing you.

EDIT: Back from shoveling the remnants of yet another snow storm. Done and done, respectively.

[newstarshipsmell]

Pisces 60/70: F6 trap, if you bomb and fall down the hole into 70 before getting the Double Jump Boots.

[C-Dawg]

Just an update. I'm working steadily on integrating custom sidescrolling enemies into the labyrinth, which is time consuming. I tried to make code that others can easily export for their own games, if they want, without the daunting amount of customization present in ghost.zh. so, basically you assign the general enemy script a number to define the first enemy, change two lines of code to indicate where your tiles and damage combos start, and that's it. The code calculates a spawn point and all enemy characteristics based on that.

I won't update for awhile as I work on this. The shell is done, except for coding how they interact with the ice beam. So I need to do that while maintaining generality, and I need to code the behavior for more than the three or so enemies I have so far.


If you want to volunteer enemy types, now you can. Sky's the liMit. I already plan to make most of the common enemies frI'm metroid and megaman, so those tropes are covered. Any other ideas, lay me on me.

Edited by C-Dawg, 02 March 2015 - 11:59 AM.

[newstarshipsmell]

Does this mean the end of suicidal enemies falling off the bottom?

How complex can you make their movement/AI? Can you code them to shoot/move towards where your player will be vs. your present location? How reactive can they be? Can they dodge your bullets or evade when you get near them?

Also, I kept meaning to ask about the moving platforms. Is it a limitation of ZC that you don't move with them, a deliberate choice on your part, or can you fix them so that the player moves along with them instead? I can't think of one single platformer where the moving platforms functioned like that... ETA: Personally, I don't mind them/care one way or the other, but I predict future players complaining about them as-is.

Edited by newstarshipsmell, 02 March 2015 - 11:46 AM.

[C-Dawg]

To answer your questions in order:

 

1. It depends on the enemy.  So, I have a few "Pheags" coded, green and red.  The green one marches off the edges of platforms mindlessly.  The red one turns around when it hits a fall.  They work like the green/red Koopas do in Mario games.  

 

2. Generally speaking, I can do whatever I want as long as it involves making decisions based off of known quantities.  What's that mean?  Well, it means that having an enemy make a decision based on the solidity or type of combos, the location of the player, what buttons the player is pressing, all of that is easy.  

 

Making an NPC make decisions based on UNKNOWN quantities is hard.  Like, having an NPC make a decision based on the possible presence of some unknown number of LWeapons, NPCS, or other things that might or might not actually be instantiated on the screen at any given time.  In theory I would do this by making an array filled with the -whatever- on the screen at any given time and check where they are.  If ZClassic supports arrays of FFCs, NPC, and LWeapons, then this is technically possible, albiet complicated.  it would also result in a very complicated code that could scale badly.  Like, let's say you have a high level rapid fire sidearm and stick 20 shots on the screen at once.  If you have, say, five enemies on the screen, and they're each loading an array and checking collisions for each shot every frame, thats a LOT of work to do.

 

I'm sure there are easier ways to do this, but I'm bad at programming.  There would have to be a pretty compelling reason for me to mess with this!

 

3.  Nope, I could code that.  Really, the moving platform script could use an overhaul too.  At a minimum, nudging the player along with the platform would be pretty simple to implement.

 

EDIT: To elaborate a little bit on the point I made in the prior post, I'm really stretching here to make sure that the NPCS are just as simple to use as those coded into Zelda Classic.  The idea is that, from the Design side, all you have to do is set up and FFC, put a particular value into the Ax box, assign this script, and that's all.  

 

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.  But it CAN write to other fields, like Data (the combo the FFC uses), Vx, Vy, Ax, Ay, etc.  So I can "pass" variables to a newly instantiated FFC by using a field I never intend to use for anything else, in this case, Ax.  

 

The Corridor enemies get "passed" values by being assigned to a particular Combo.  That's time consuming because it means I need to set up combos for each enemy, and its kind of a pain in the butt.  I like using Ax better and just drawing tiles directly because it omits one step from the enemy's setup.

 

When all is said and done, all I need to do is set up and FFC on a screen running "Sidescroll_Enemy_Setter" or whatever, plug in values for which enemies and how many (probably like D1 = Enemy type 1,  D2 = how many, etc).  The end result will not be as customizable as ghost.zh, at least without messing with the code, but it should be infinitely easier.

 

EDIT2 - I spoke to Gleeok about the screen transitions.  He says they are tinkering with a possible new release of ZC down the road that is either open source or gives you more access to game variables using scripting, and it sounds like allowing me to tinker with the scrolling speed is quite possible to do.  Not sure what the timetable is on that, but no one's in a rush. Anyway, just letting you guys know I hear you and it'll get improved.

Edited by C-Dawg, 02 March 2015 - 01:30 PM.

[newstarshipsmell]

As of demo 441, these are all the unwalkable bugs in Aquarius:







Scorpio 38/48: can fall into block near center
Scorpio 42/43: can jump into wall near top
Scorpio 5B/5C: can walk into block near bottom

M10 S08 Pos26 - unwalkable halftile
M10 S7C Pos26 - unwalkable halftile

The following rooms in Cancer would let you enter the walls with Dash Jets 2 and fall into top row solid combos - which you wouldn't fall out of - getting stuck/forcing F6: 02, 03, 12, 13, 37, 38, 3B

Aries 55/56: can jump into wall near top
Aires 4D/5D: can fall into block near center
 

I feel like the downside to no screen scrolling, the bumping of the heads when jumping upward, can easily be solved by extending a fully walkable background tile beneath the platforms the player is intended to jump onto. This way the player has a very clear idea of what is above them on the screen above, and where they may be able to jump.

Here's a picture.

Spoiler

Two different screens, divided by that red/orange line. Top one was unaltered. Bottom one has a hypothetical background tile altered and placed below a walkable platform. The player sees the background there, and knows exactly where they need to move in order to not bump their heads.

I'm not entirely sure if there is a disadvantage to having this. Does it add that much of a challenge to be able to bump your head in-game?

I thought about this - and it would be a good idea (though time-consuming to implement) for a No Screen Scrolling version of the quest.
Adding them to the scrolling version would look weird when you scroll up/down, since many of them would be bottom-halves of bottom-half tiles directly above. But without scrolling, you'd never see them adjacent, and the benefit they serve is primarily help the player to see obstacles in the bottom row above, which they have a hard time seeing, with scrolling off and hitting said obstacles causing near-instantaneous flicker between screens.
So if you decide to offer a modified no-scroll quest at an alternate link, and think his suggestion is good, I'd say only implement it in the alternate version. (ETA: Which, now that I'm bothering to closely read the comment I just quoted, is apparently what he was suggesting in the first place. :/)

Pisces 38/39: can jump into wall near top
Pisces 28/29: can walk into block near bottom
Pisces 0B/0C: can jump into wall near top
Pisces 5D/5E: can jump into wall near top

Gemini 09/0A: can jump into wall near top
Gemini 0F: door top unwalkable - and I believe door autowarps/does not require up to enter

The following rooms in Taurus would let you enter the walls with Dash Jets 2 and fall into top row solid combos - which you wouldn't fall out of - getting stuck/forcing F6: 0A, 0B, 32, 3F, 57, 5C

Taurus 02: missing tile in upper-right corner
Taurus 1B: unwalkable empty tile on left edge
Taurus 3B/3A: can walk into block near bottom
Taurus 54/53: can DJ2 thru Pos131/147, walk into blocks near bottom
Taurus 5E/5D: can DJ2 thru Pos1/17, walk into blocks near top
Taurus 60/61: can DJ2 thru Pos78, walk into blocks near top
Taurus 78/77: can DJ2 thru Pos98-162, walk into blocks near bottom
Taurus 7D/7E, can DJ2 thru Pos45/61 or 94/110, walk into blocks near top/center

M25 S22: This is that annoying Stomp Boots boss, right? So, not sequence-required. You could avoid him, come back later with Dash Jets 2, and dash through the door on left, enter wall in adjacent room, yeah? Of course, this would apply in general, to any boss room on another map you warp to, with doors that leave gaps along the room border behind them, and are only one tile thick. Wouldn't matter with any bosses that are sequence-required, and must be passed prior to gaining DJ2, obviously.
Also obvious, you can't go anywhere besides inside a wall here, and that boss would already be beaten (I think?) but other instances could possibly allow going somewhere else/fighting some other boss out-of-turn.

ETA: I'm including every instance where I see you can DJ2 into a problematic space - some of them include 1-tile-high gaps on the top/bottom row. With DJ2 requiring perfect row alignment, presumably the room scrolls would make entering these gaps extremely difficult/impossible, but if you recode it/relax the alignment as suggested by solairflaire (I think?) and I, then entering these gaps on the bottom and/or top would become feasible.

Edited by newstarshipsmell, 03 March 2015 - 01:03 AM.

[C-Dawg]

Good reports.  Will catch them next go around.

 

I uploaded a version of the QST file showing you the custom enemy system I've been working with in action.  You'll only find new enemies on the way to the Pulse Hammer at the moment.

 

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.

Edited by C-Dawg, 03 March 2015 - 02:04 AM.

[newstarshipsmell]

Leo 0B/0A: can walk into block near bottom
Leo 46: still can't reach missile upgrade, afaict ETA: suggest you replace the powerup with a door... that goes nowhere!
Leo 2C/2B: can jump into wall near center
Leo 4D/4E: can jump into wall near top/can walk into wall near bottom

Libra 01/00: can DJ2 thru pillar on left, walk/jump into wall
Libra 55: unwalkable door top
Libra 15: unwalkable door top
Libra 47+57/46+56: can jump into wall near bottom+center/top
Libra 08/07: can DJ2 thru pillar on left, walk/jump into wall
Libra 0C: unwalkable door top
Libra 5F/6F: can DJ2 thru pillar on right, fall into blocks/force F6

Virgo 33/43: purple wall/vines misalign on left side. Can DJ2 into right space and fall into block
Virgo 0D: unwalkable door top

Capricorn 33: upper platform erases the pipe corner when it touches it (from what I remember before) so probably just need to move the left end of its path to the right a bit

M35 S32 pos171 unwalkable half-tile
M35 43/53: pillar/rock misalignment
M35 1C/1B: can walk into block near top

M37 S16: floating vine at pos54

As far as room border mismatches, I completely ignored all the bottom row blocks with spaces below them, since that's all obviously intentional, and you just bounce off them.
I also ignored (entirely, I think) single blocks along ceilings on room sides, since you'd just fall out of them. But if you jump up and are slightly inside the ceiling above you and scroll into an adjacent room and into a single block like that, so you aren't aligned on the block, will you still fall out, or get stuck and have to scroll back? Should I point those ones out too?
And I may have overlooked some Secret blocks here and there rendering some of my DJ2 bugs non-bugs. Not sure. I tried to check the Secrets when it seemed like there might be one I hadn't found/had forgotten.

RE: Demo 443
The custom enemies alternate their sprites between Randars, Guardians and big X's with weird colors. Wasn't sure if that was what you'd intended or some glitch.
Also, swapping the demo set my Power to 2, Speed and Energy to blank. So I can't resume the previous playthrough with this QST, in case there were other bugfixes you made between quests. Swapped back to 441 (started on 440) and it restored my sidearm levels to what they were previously (P13 S03 E13).

Edited by newstarshipsmell, 03 March 2015 - 03:27 AM.

[C-Dawg]

What....? My enemy sprites are not doing that. Did you swap a save file?

Edit: you did. All kinds of unusual stuff can happen. Try a new save and see if it happens.

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!

Anyone know if I can return an array using a scripted function?

Edited by C-Dawg, 03 March 2015 - 08:47 AM.

[newstarshipsmell]

What....? My enemy sprites are not doing that. Did you swap a save file?

Edit: you did. All kinds of unusual stuff can happen. Try a new save and see if it happens.

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!

I am and have been using the Zelda Classic v2.50 - Windows Version linked on http://www.zeldaclas...m/downloads.php, which according to its About popup, is v2.50 Build 24.

I downloaded the 2.50.1 version linked in the forum thread you linked to on TIGSource (which is v2.50 Build 28), but I'm not using it.

I did in fact swap Demo 441 with Demo 443 (after previously swapping 440 with 441.) Per your suggestion, I started a new gamesave on 443 and their sprites displayed normally.

So I just made it to Leo on 440/441. I'll try to finish playing through that to find any more bugs in 441 (they're so much fewer and further between now, which is always a good sign!) Hopefully by the time I'm done, you'll have added some more custom enemy stuff to the most current demo, and I can start over on it.

Edited by newstarshipsmell, 03 March 2015 - 03:10 PM.

[C-Dawg]

So I think the problem is that, in the latest build of ZC, ffc-wide global variables are depreciated (slated for removal).  That might mean there are problems.  In order to avoid using them, I need a function to return an (x,y) coordinate instead of a simple int.  I'll see if that's possible later today.  

 

If this were a quantum computer, I could just do this with a single int and some Godel numbering, but, uh, it's not.

 

EDIT: "Wat" you say?

 

Well, my enemy FFC script has a function called "find_spawn."  I pass it an enemy ID number, and it then will locate an appropriate place on the screen for that kind of enemy.  It should return spawn_x and spawn_y but I've only ever returned single variables before, and I dont know if I can return arrays.  So my crappy programming solution was to just make spawn_x and spawn_y into global variables within the custom enemy FFC.  That means all the functions in the FFC share and have access to those variables.  Not the entire game.  

 

This resulted in some warnings from the devs saying that this practice is depreciated (going to be phased out) but it worked, so I shrugged and continued.  I wonder if it's doing wacky things in the meantime.

Edited by C-Dawg, 03 March 2015 - 12:37 PM.

[justin]

I do this from Saffith's advanced zcript tutorial when I want to return two numbers (typically xy)

int x = 53; // 00110101
int y = 20; // 00010100

int combined;
combined = x << 8; // 0011010100000000
combined |= y;     // 0011010100010100

// These are spaced out for clarity; this would more likely be a single statement:
int combined2 = (x << 8) | y;

// When you want to get the original numbers back...
// 0xFF is the same as 11111111b
int x2 = combined >> 8;   // 00110101
int y2 = combined & 0xFF; // 00010100

[C-Dawg]

I have no idea what that is.  Is it masking?  So ZClassic is not capable of returning two variables.  I suspected as much.

 

EDIT: In the meantime, are these scripted enemies adding anything to the game?  Im not sure it's worth the effort if they're just minor tweaks to the normal LOZ enemies to blast past on your way from point A to point B.

Edited by C-Dawg, 03 March 2015 - 12:38 PM.

[justin]

I have no idea what that is.  Is it masking?  So ZClassic is not capable of returning two variables.  I suspected as much.

 

it is just a method to combine two integers into one using bitwise operations.  basically one integer is getting a bunch of zeros added, and then added to another integer.  then afterwards you can separate them again.  here's how i use it when i want to return x/y coordinates...

 

// this would be the return part of one function.
// you don't need to edit anything here but the variable names.
return (nx << 8) | ny;   // where nx and ny are my x/y variables.  
 
// then in my code that is calling that function...
int newxy = Function();  // Function is the function that is returning above (generic name is generic)
int newx = newxy >> 8;  // again you only need to change your variable names here.
int newy = newxy & 0xFF;  // and here.