645 replies to this topic

[Lejes]

Your problem with gravity is likely due to some error in your script, because I just verified that the flags and even switching between them in real time works just fine.

[ywkls]

I'm consulting with ZoriaRPG about it currently, and he's baffled too. We think I may have to use separate scripts for each of the 9 segments. I really wish ghost.zh had an option to make easily setting up multiple ghosted enemies easy.

[Timelord]

I'm consulting with ZoriaRPG about it currently, and he's baffled too. We think I may have to use separate scripts for each of the 9 segments. I really wish ghost.zh had an option to make easily setting up multiple ghosted enemies easy.

 

For what it's worth, I was not, and still am not certain if GHF_NOFALL would affect any npcs declared in the script, except the npc with the pointer ghost. The script made around seven additional npcs, and ywkls was trying to use GHF_NOFALL to keep all of them from being affected by gravity, and manually moving them in relation to the core npc. I do not think that will work, as I'm pretty sure that the NOFALL property will only affect the core, and the rest will be yanked away from it, and their relationships broken.

 

@Saffith: A way to set ghost flags, or use ghost functions, on other npcs declared in a ghost script, would be a neat addition for the future, for people making huge, segmented things.

Edited by ZoriaRPG, 07 December 2015 - 07:57 AM.

[cavthena]

To prevent falling set your enemy to type "Other(float)" in ZC. It's like magic! (I haven't been working with flying segmented enemies! I swear!)

[ywkls]

To prevent falling set your enemy to type "Other(float)" in ZC. It's like magic! (I haven't been working with flying segmented enemies! I swea

 

Hadn't thought of that. However, I solved the problem by setting the npc->Jump attribute to zero every frame inside the custom waitframe I made for the boss. That fixed him right up.

[Saffith]

Is there any size limit on Big Eweapons? Enquiring (inquiring?) minds want to know.

4x4 tiles.

[Deedee]

Okay, I've been trying to figure out what the hell is going on with my script. At first it froze the screen like there was no waitframe in a loop, and now it just only runs upuntil a certain point (seen in allegro.log as "we've reached the else statement", etc). I am getting the following error in allegro.log:

Spoiler

We're doing phase 0, phasing.

We reached the else block, resetting values. Back to walking.
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Stack over or underflow, stack pointer = 0
Invalid NPC with UID 2450000 passed to npc->Jump
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->Dir
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->TileWidth
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->TileWidth
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->HitWidth
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->HitXOffset
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->TileHeight
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->TileHeight
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->HitHeight
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->HitYOffset
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->HP
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->CSet
NPCs on screen have UIDs 762 
Invalid NPC with UID 2450000 passed to npc->MiscFlags
NPCs on screen have UIDs 762 

 

Here is the script (minus the other scripts in file, and global):

 

http://pastebin.com/Ndyb3kbT

 

Everybody I sent it to has been stumped, and I have no idea why this is happening. No enemy shows up, before Zoria made some changes to it the screen froze, and now no enemy shows up at all!

[Evan20000]

I'd have to give it a more serious gander later, but initially my first impression is that it's a stack overflow that happens when you declare too many variables. I've run into this a few times. General tips to avoid this include using functions to retrieve values, and declaring commonly used variables for 'for' loops at the top (each declaration counts towards the stack, even if it goes out of scope). Let me know if this helps. Failing that, storing your variables into a large array should fix it too.

[Timelord]

To check that, move the declarations for MehX and MehY to be in scope of the run function, and assign them in the for loops, instead ofdeclaring them there; or make those for loops into functions with the values declared in the function body. That would allow them to pop off....

...however I did not count enough there to deplete the stack, unless the functiion calls are killing it. I doubt that, but I'll lok over it again in a while, make adjustments, and go from there.

The thing is, that script vars in the for loops should fall out of scope as those loops end, however, the 60 value declarations are not good.

Edited by ZoriaRPG, 08 December 2015 - 05:56 PM.

[Evan20000]

The thing is, that script vars in the for loops should fall out of scope as those loops end, however, the 60 value declarations are not good.

I can verify that this is not the case as declaring i at the top of my script for my for loops has saved me from the stack overflow/underflow before. I think it might not free up the memory until the function ends, even if the variable is out of scope?

[Timelord]

I can verify that this is not the case as declaring i at the top of my script for my for loops has saved me from the stack overflow/underflow before. I think it might not free up the memory until the function ends, even if the variable is out of scope?

 

I think you're right. Zi usually put for loops inside functions, so they fall out of scope when the function that contains them pops off. I also usualyly reuse vars inside them with:

int abstract_example(ffc f, npc n){
    int x;
    int y;
    for ( int q = 0; q < 120; q++ )
         x = Rand(1,4)
         y = Rand(0,3);
         f->Vx = x;
         f->Vy = y;
         if ( x > 2 ) n->Dir = DIR_UP;
    }
    return n->Dir;
}

In this silly example, the registers should be freed when the function returns. The only time I tend to declare a var inside a for loop, is if it is also inside a statement that is unlikely to evaluate.

 

What I initially fixed in the script, was a statement conflict. One if that was supposed to run if a condition as >= 3, and another that was an else if that was supposed to evaluate if the same condition was > 0. The problem, was that the other statement was an else if, as part of a series. If both were if statements, that would be fine, although in the code itself, they would still have been doing naughty things; but a quick change it if val > 0 && val < 3 was all that needed.

 

Admittedly, I was in the middle of something else when this was placed in front of me, and Dimentio had issues with other scripts that he included, causing havoc. I suggested testing only this script, and its dependencies, with nothing else, to prove it, rather than trying to sort out a can of worms that could be caused by any number of factors; and I'm pretty sure I asked for a quest with the tiles, and enemy set up, so that I could run it through its paces on my end; but I had to do something that took me away from Skype, so I'm not sure if i got that.

 

I sent a patched version a few moments ago, but with the time difference, I have no idea if this is even still something I should be doing.

Edited by ZoriaRPG, 08 December 2015 - 09:03 PM.

[Saffith]

I can verify that this is not the case as declaring i at the top of my script for my for loops has saved me from the stack overflow/underflow before. I think it might not free up the memory until the function ends, even if the variable is out of scope?

That does indeed appear to be the case. As a quick test:

global script test
{
    void run()
    {
        Trace(444);
        
        if(true)
        {
            int x=1234;
            int y=5678;
        }
        else
        {
            int x=91011;
            int y=121314;
        }
        
        Trace(555);
    }
}

compiles to

test
 SETV d2,0
 PUSHR d2
 PUSHR d2
 PUSHR d2
 PUSHR d2
 PUSHR d3
 SETR d4,SP
 PUSHR d4
 SETV d2,14
 PUSHR d2
 SETV d2,444
 PUSHR d2
 GOTO 50
 POP d4
 SETV d2,0.0001
 COMPAREV d2,0
 GOTOTRUE 27
 SETV d2,1234
 SETR d6,d4
 ADDV d6,4
 STOREI d2,d6
 SETV d2,5678
 SETR d6,d4
 ADDV d6,3
 STOREI d2,d6
 GOTO 36
 SETV d3,0
 SETV d2,91011
 SETR d6,d4
 ADDV d6,2
 STOREI d2,d6
 SETV d2,121314
 SETR d6,d4
 ADDV d6,1
 STOREI d2,d6
 SETV d3,0
 PUSHR d4
 SETV d2,43
 PUSHR d2
 SETV d2,555
 PUSHR d2
 GOTO 50
 POP d4
 SETV d3,0
 POP d3
 POP d3
 POP d3
 POP d3
 QUIT
 POP d3
 TRACER d3
 POP d3
 GOTOR d3

That shows it's pushing all four variables onto the stack at the start of the function and popping them off at the end. for loop counters show the same behavior. ZScript's scope rules apparently don't carry over to ZASM too well.
That means every single instance of i, MehX, MehY, M1..M8, and all the rest in that script occupy separate stack elements for the duration of run(). That will overflow in no time.

[cavthena]

Is it something that can be fixed in a later version of zc or do we have to with it?

[grayswandir]

Since it's just the compiling, it shouldn't affect anything else if you fix it, right?

[Saffith]

It could theoretically be fixed, but I don't know how. I never really got into the compiler much. jman or DD may know how to do it, but I wouldn't count on it happening even if they do.