FFC jumps into a changer

[Avataro]

This bug involves 2 ffcs. One has the "Is A Changer" flag checked. The normal ffc jumps onto the changer for no reason. It only happens under these obscure circumstances:

The x position of the changer FFC equals it's y position.
The x position of the normal FFC equals it's y position.
The x and y position of the normal FFC is greater than the position of the changer FFC.

Weird, isn't it? xD This happens in 2.50.1 and 2.50.2 and maybe even in earlier versions.

Test quest: http://www.mediafire.com/download/g5...gerBugTest.qst

[Tamamo]

@ZoriaRPG
It appears to has to do with this function from tiles. I think the problem is that prevx and prevy have junk values.

CODE: Show

//snip from ffc
if((isonline(curr.x, curr.y, curr.prevX, curr.prevY, changer.x, changer.y) || // Along the line, or...
(curr.x==changer.x && curr.y==changer.y)) && // At exactly the same position, and...
(curr.prevX>-10000000 && curr.prevY>-10000000)) // Whatever this means

//snip from tiles
/*
bool isonline(float x1, float y1, float x2, float y2, float x3, float y3)
{
float slope;
float intercept;

slope = (y2-y1)/(x2-x1);
intercept = y1 - (slope*x1);
return (y3 == (slope*x3)+intercept) && x3>zc_min(x1,x2) && x3<zc_max(x1,x2) && y3>zc_min(y1,y2) && y3<zc_max(y1,y2) ;
}
*/

//pixel-precise version of the above -DD
bool isonline(long x1, long y1, long x2, long y2, long x3, long y3)
{
long long dx = x2-x1;
long long dy = y2-y1;

long long qx = x3-x1;
long long qy = y3-y1;

//if (x3,y3) is on the line, qx,qy must be multiples of dx,dy. Check this without division.
if(qx*dy != qy*dx)
return false;

//check for degeneracy
if(dx == 0 && dy == 0)
return qx == 0 && qy == 0;

long long nondegend;
long long nondegenq;

if(dx == 0)
{
nondegend = dy;
nondegenq = qy;
}
else
{
nondegend = dx;
nondegenq = qx;
}

//flip negatives
if(nondegend < 0)
{
nondegend = -nondegend;
nondegenq = -nondegenq;
}

//and compare
return nondegenq >= 0 && nondegenq <= nondegend;
}

[Saffith]

Not junk, just not what it expects. It's a magic number mismatch. The -10000000 values are supposed to indicate that they had no previous positions because Link just entered the screen. Problem is, the values are actually -1000.

[Tamamo]

That makes sense. Thanks for clearing that up. I'll make that change and test it.

[ZoriaRPG]

@Tamamo : You wanted to do the ffc improvements, so feel free.

If you still feel up to tacking bool solid (I'd do int solid, for varying levels), that's going to be a nightmare. The other big/popular request seems to be to upgrade ffcs to permit more than 64x64 pixels of area, which would be a moderate rewrite. I'd also give ffcs an genuine hitbox, instead of relying on their drawn sizes.

Changers in general, are very finicky: I've found that they require spot-on collision, at a pixel level, to work at all, at all. If you want to address the changer bugs, making them less st make them earict, or allowing the user to select what changers can affect 'this ffc' with a checkbox list or something, would possibly make them more user-friendly.

IDR if I added anything ffc-related to zscript yet.I was goin to try to make a new class of objects that functioned like ffcs, but at a global / on-demand scope, which sort of falls in-line with another idea, but at present I'm trying to add some things to the lexer (flex files), for things like switch-case. I need to find out if the code that I added to do comment blocks works, too. I used some flex references and just popped it in there, but the flex set-up for ZScript isn't precisely typical, so..

{{ Getting back on topic... }}

Let me know what you're thinking of doing, or planning to do with ffc objects, and if you'll need anything on the ZScript side to support it.

[Tamamo]

@Tamamo : You wanted to do the ffc improvements, so feel free.

Yup, still do.

If you still feel up to tacking bool solid (I'd do int solid, for varying levels), that's going to be a nightmare.

Yeah, probably going to use my "call a friend" life line for that one.

The other big/popular request seems to be to upgrade ffcs to permit more than 64x64 pixels of area, which would be a moderate rewrite. I'd also give ffcs an genuine hitbox, instead of relying on their drawn sizes.

I think it may be possible, but i could be wrong. Depends on bunch of stuff, tiles, combos,

Changers in general, are very finicky: I've found that they require spot-on collision, at a pixel level, to work at all, at all. If you want to address the changer bugs, making them less st make them earict, or allowing the user to select what changers can affect 'this ffc' with a checkbox list or something, would possibly make them more user-friendly.

I hate changers with a passion. I know ffcs that are linked are not effected by changers though. But there is no way to make a ffc only effected by certain changers or to change a changers variables without a script. No figure eight skating traps.

IDR if I added anything ffc-related to zscript yet.I was goin to try to make a new class of objects that functioned like ffcs, but at a global / on-demand scope, which sort of falls in-line with another idea, but at present I'm trying to add some things to the lexer (flex files), for things like switch-case. I need to find out if the code that I added to do comment blocks works, too. I used some flex references and just popped it in there, but the flex set-up for ZScript isn't precisely typical, so..

That would be nice, but very difficult to pull off.

{{ Getting back on topic... }}

Let me know what you're thinking of doing, or planning to do with ffc objects, and if you'll need anything on the ZScript side to support it.

For starters do you use windows? I have a makefile that compiles The 3.0 master branch.
https://github.com/ArmageddonGames/ZeldaClassic/pull/20

I also plan to restructure ffc->Flags[] so it's more similar to the others. So it uses two bitmask. One for normal flags and one for changer flags.

[ZoriaRPG]

Yup, still do.



Yeah, probably going to use my "call a friend" life line for that one.



I think it may be possible, but i could be wrong. Depends on bunch of stuff, tiles, combos,



I hate changers with a passion. I know ffcs that are linked are not effected by changers though. But there is no way to make a ffc only effected by certain changers or to change a changers variables without a script. No figure eight skating traps.



That would be nice, but very difficult to pull off.



For starters do you use windows? I have a makefile that compiles The 3.0 master branch.
https://github.com/ArmageddonGames/ZeldaClassic/pull/20

I also plan to restructure ffc->Flags[] so it's more similar to the others. So it uses two bitmask. One for normal flags and one for changer flags.

That makefile sounds extremely useful for the 2.55 group, but I suspect I'll need to rearrange things to use the 2.6 files. Did you set it up to include Boost and all those fun files? I know that Dimentio had woes stemming from that.

I pretty much expect a lot of stuff regarding ffcs to be a pain, although adding hitboxes shouldn't be too bad. I've been pecking at the list on and off, but I was overtaxed with normal work, for between three, and five months, so I'm only now returning to it, where I left off.

I haven't really tested any of my additions, but I'll get round to it. I'll drop the lexer files, and the 2-55 additions somewhere if you have any desire to try them out, but I should have a bunch of it integrated soon, at which point I'll need to compile with all the changes, and see what works, and what does not.

Anyhow, solid ffcs are probably the most desired feature request, by users, even if they don't know that they want it.

I need to decide if I'm going to add function pointers to the parser, or let Grayswandir do it. He wants them pretty bad. He also wants all var types at a global scope, and I was thinking that we can do thatby prealocating some pointers for global typed declarations,such as npc, the same way that we reserve pointers for global arrays.

One quick and potentially easy change that I want to get into the next build: Enlarge all object arrays obj>Misc[] Screen->D, and so forth) to a size of 255. That'll give people far more freedom.

Do you think you could implement all ten script types into npc defences? I was going to add those, and plot them on the zscript side, but then I'd need to add them into the engine, which is quite another matter. I think that even when it's not needed, just make all the arrays (including defense[]) a size of 255.

That'll allow users to make custom scripted defs.

Some other things that I want to add soon:

npc->Vars[1024] : Store all those internal vars used by hardcoded npcs in an array thatis r/w from zscrit.
This would be a step towards npc scripts.

Make quest rules r/w. I believe that I have a practical way to do this.

Make all game engine bools available to zscript. I may be done with this soon, as I already made all the script functions, I think. bool Throttle is my chief reason for doing that, so that a questmaker can detect uncapping.

Add lit modes and a light table for drawing, so we have more than one transparency level. Allegro supports 255 levels in 8-bit. Not sure why this was never done, although mayhaps Gleeok already finished it.

Typecast pointer ids from npc, *weapon, item, to float.

and...finish itemdata. Want to work on that one with me?

[Saffith]

Are you guys making a fork, or are you taking over ZC? If you don't need me anymore, let me know, 'cause I've got other things I could be doing.

[ZoriaRPG]

Are you guys making a fork, or are you taking over ZC? If you don't need me anymore, let me know, 'cause I've got other things I could be doing.

Are you guys making a fork, or are you taking over ZC? If you don't need me anymore, let me know, 'cause I've got other things I could be doing.

As we've discussed with @Gleeok many times, our group only wants to work on the 2.x branch, for now. If things we do there end up being pulled into 3.x, so be it. If it forks, so be it. I believe that we laid out our objectives quite clearly, and if they're incompatible with your plan, then the user can pick their version, 2.x, or 3.x.

It's pretty clear, at least to me, that these changes are too radical, and rooted in the past, to fit into your plan; which is precisely why we proposed to keep it as 2.x while you work out the 3.x engine the way you want to do it. We were invited to maintain, and update the 2.x branch, after all, when we stated our intent to make a perma-fork of 2.x on Pure; so that we'd be responsible for 2.x.

I really have no idea what your plans are, and you've never really spelt them out for anyone: I've asked you in the past, and never received an answer. If you feel that we shouldn't be adding features like these, then aye, it's a divergence. I've said many times that the ZC3 stuff should be filed under a 3.x version heading, purely for this reason.

We planned to do releases as 2.53, 2.55, and 2.60, with specific benchmarks for each, reserving 2.6 to 2.9x for this stuff, and allowing you to do what you want with 3.x. I stil get the sense that you aren't interested in anything that we outlined in the 2.future topics, and this post just stresses that what we want to do isn't on your agenda.

There's nothing any of us can do about that, so if it doesn't suit your tastes, we won't block you from doing the rewrite with whomever is interested in that, merging to ag5, deprecating zscript, and making all the AS stuff. In the meanwhile, we can get out new versions to users, with the features they've been crying over wanting for years, and prevent further stagnation from lack of interest.

New stuff promotes activity, and invites new users to the pool. If what we make works, and people like it, then you can decide if you want to use any of it for zc3. TBH, itks also clear that you're far more interested in rewriting the engine, and tying npcs and objects all into the AS engine, than expanding what we have, so again, our goals are at odds in several areas; which is why Gleeok proposed the rollback plan.

Every time I confirm that this indeed what's happening, it seems as if you feel out of the loop, and upset about it. Is Gleeok not discussing this with you, or copying you on things? I copied you on quite a lot, and you didn't respond, so I really have absolutely no idea what's going on over there. ?

P.S. Hit 'edit' instead of 'reply qith quote'. Fixed.

[Tamamo]

Deleted