590 replies to this topic

[Avaro]

Is it a bug that push blocks can change layer 3 combos into undercombos? This happens if the rule "layer 3 is background" is checked. Normally it should only change layer 0 combos.

Also, there seems to be a graphical glitch sometimes, when showing the walkability, pressing "W".

Edited by Avataro, 24 March 2012 - 11:16 PM.

[Mero]

Strings can't be deleted anymore? Is this a bug or what?

EDIT: Collision and LinkCollision are missing a -1 as far as the right and bottom definitions go for the collision box.

Edited by blackbishop89, 24 March 2012 - 02:57 PM.

[XMSB]

Strings can't be deleted anymore? Is this a bug or what?

Read this:

String Editor: Deleting a string now just clears the string instead of physically removing it and decrementing the IDs of all strings after it (which, in this age of ZScript, might be more trouble than it's worth). Since you can re-order the string list at will, you can shuffle this empty string to the end of the list as you will.

It's an adjustment that was made for RC2.

[Mero]

I don't think AtfronX and AtFrontY are written correctly. Since they should do what InFrontX and InFrontY do with a dist argument of 0.

CODE

//Returns the correct offset to be at the front of a sprite facing in the direction 'dir'
int AtFrontX(int dir) {

    int x = 0;
    if(dir == DIR_UP || dir == DIR_DOWN) x = 8;
    else if(dir == DIR_RIGHT) x = 16;
    return x;
}

int AtFrontY(int dir) {

    int y = 0;
    if(dir == DIR_DOWN) y = 16;
    else if(dir == DIR_LEFT || dir == DIR_RIGHT) y = 8;
    return y;
}

EDIT: Also InfrontX iand InfrontY is not written correctly either since it doesn't work unless dist is negative.

CODE

/Returns the correct offset to be 'dist' pixels away from the front of a sprite facing in the direction 'dir'
int InFrontX(int dir, int dist) {
    int x = 0;
    if(dir == DIR_LEFT) x = -16+dist;
    else if(dir == DIR_RIGHT) x = 16-dist;
    return x;
}

int InFrontY(int dir, int dist){
    int y = 0;
    if(dir == DIR_UP) y = -16+dist;
    else if(dir == DIR_DOWN) y = 16-dist;
    return y;
}

Edited by blackbishop89, 27 March 2012 - 09:32 AM.

[Avaro]

In build 1330 there is the following change:
"* Push blocks' combo types should no longer be ignored in on sideview screens."

Does anyone know, what that means? Push blocks are still not affected to gravity. They don't fall down. I'd call this a bug

[Saffith]

Are the shielded in front back left and right flags suppose to be checkable in the enemy editor for other and other floating enemies?

Yes.

May I give my opinion about Missing Combo Types? Here are all combo types that are missing in my eyes:

We're definitely not adding more combo types at this point.

I have also found a bug, where you can move through unwalkable push blocks while they are moving from one combo to another. This only works when you push the block in the Up direction.

That probably won't get fixed; it's fairly difficult, and it doesn't matter much in practice.

Is it a bug that push blocks can change layer 3 combos into undercombos? This happens if the rule "layer 3 is background" is checked. Normally it should only change layer 0 combos.

The undercombo should be invisible if you're pushing a block over a background layer. It's not changing layer 3, it's changing layer 0 and covering it up.

Also, there seems to be a graphical glitch sometimes, when showing the walkability, pressing "W".

Also more trouble than it's worth to fix.

I don't think AtfronX and AtFrontY are written correctly. Since they should do what InFrontX and InFrontY do with a dist argument of 0.

Maybe. They return the point at the front and center. Not good for positioning sprites, but it's fine for, say, solidity checking.

EDIT: Also InfrontX iand InfrontY is not written correctly either since it doesn't work unless dist is negative.

Yeah, those are definitely wrong.

In build 1330 there is the following change:
"* Push blocks' combo types should no longer be ignored in on sideview screens."

Does anyone know, what that means? Push blocks are still not affected to gravity. They don't fall down. I'd call this a bug

The heavy and wait types were previously ignored on sideview screens.
Push blocks aren't supposed to be affected by gravity. That's not something we could easily implement.

[Mero]

Oh so that's how atfrontx and atfronty work. They're working as should then.

[Avaro]

Also, there seems to be a graphical glitch sometimes, when showing the walkability, pressing "W".

Also more trouble than it's worth to fix.

It shows the walkability completely wrong, sometimes. This only happens at the bottom half of the screen (and only on a certain row)..
I'm okay, if it's not going to be fixed. It's not that this will stop any questmaker from making his quest. This did not happen in RC2 though.
Look at this thread: http://www.purezc.co...showtopic=54059
This is what I am talking about.

Edited by Avataro, 28 March 2012 - 01:20 PM.

[Mero]

Would it be possible to make it so the canwalk function from std uses floats for x, y, and step. It'll allow more precise collision detection for things such as ffcs.

[Xenix]

Because it seems my post was missed.

I may have found a bug. I had a script that would disable all of link's inputs but start, and ever since I switched it has stopped working. Is there something wrong with Link->Input?

Edited by Sepulcher, 28 March 2012 - 10:34 PM.

[The Satellite]

Might as well post this... I actually got it to work in windowed mode, in aero, without it crashing. And strangely, it was that "zc_win_proc_fix" thing. It wouldn't work even when I had it set to zero, but then I only did some minor aesthetic differences in the spacing... It was this before: "zc_win_proc_fix=0" but when I changed it to "zc_win_proc_fix = 0" with spaces, it actually worked. O_o

So... no problems here now.

[Gleeok]

Because it seems my post was missed.

Check and make sure you aren't disabling input and then checking it again later on in a different function. ex:

CODE

Link->InputUV = false;

///code....

if(Link->InputUV)
  something();

Or in your case the opposite of this. Link->Input seems fine.

Would it be possible to make it so the canwalk function from std uses floats for x, y, and step. It'll allow more precise collision detection for things such as ffcs.

They are the same thing.


..Also, was there ever a definitive method recreating the crash in the tile or combo page? I couldn't get it to happen.

[Saffith]

Might as well post this... I actually got it to work in windowed mode, in aero, without it crashing. And strangely, it was that "zc_win_proc_fix" thing. It wouldn't work even when I had it set to zero, but then I only did some minor aesthetic differences in the spacing... It was this before: "zc_win_proc_fix=0" but when I changed it to "zc_win_proc_fix = 0" with spaces, it actually worked. O_o

So... no problems here now.

Could I ask you to recheck that? The spacing shouldn't make any difference.

[blue_knight]

Because it seems my post was missed.

I use a function to disable Link input in the MotM quest and the MotD (raycaster) and it works fine. In one case it's in a global script and in the other an FFC script.

[Mero]

We so need a Link->Tile function. Or would it just make a mess of things?