PDA

View Full Version : FFC jumps into a changer



Avataro
03-16-2016, 05:06 PM
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/g5g0wtq5eggwbxy/ChangerBugTest.qst

Tamamo
06-20-2016, 02:09 PM
ZoriaRPG
It appears to has to do with this function from tiles. I think the problem is that prevx and prevy have junk values.

//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
06-20-2016, 04:45 PM
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
06-20-2016, 10:10 PM
That makes sense. Thanks for clearing that up. I'll make that change and test it.

ZoriaRPG
06-20-2016, 11:17 PM
Tamamo : You wanted to do the ffc improvements, so feel free. :D

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
06-21-2016, 10:18 AM
Tamamo : You wanted to do the ffc improvements, so feel free. :D

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
06-21-2016, 10:08 PM
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
06-21-2016, 10:31 PM
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
06-21-2016, 11:08 PM
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
06-22-2016, 02:10 AM
Deleted

ZoriaRPG
06-22-2016, 04:49 AM
I personally think the 2.x branch is a waste of time. But that's just me. And no, we don't need you anymore Saffith if your going to make comments like that. I'm more then happy to pick up where you left off. :-/ To be honest if Gleeok hadn't push the damn source code (whose makefile didn't even compile on windows mind you nor does it remove encryption like planned) out so early there wouldn't be a need for a fucking 2.x branch. But that's just me being optimistic I guess. I'm equally to blame for the Nuclear fallout though. Since I sort of kept bugging him about it. Not to mention I suggested to both of them in private messages over purezc a LONG time ago. And I regret it everyday. In otherwords the 3.x branch is going nowhere fast. Because nobody is doing shit. It's suppose to be community driven. That was the original intent. Or has devs forgotten that. Anyways, I'm done being a megabitch for now. It's probably entirely all my fault anyways The three of us have had a lot of private conversations the past year or so I'm not sure how much influence I actually had, but perhaps my ideas where not as brilliant as I though. My bad guys. :(

Actually, the 2.x branch is what you get, when five out of the six people interested in working on this, who weren't core developers, prefer to evolve 2.5, and add in the things we feel are missing, toward a definitive 2.x core, before working on 3.x, which (for the record) still has no roadmap...

There is no reason that anything we want to add to 2.x can't make its way into 3.x, nor is there any reason that anything that has been considered for either is set in stone. The git repo is still a mess, too, and our group was hoping to put together a 2.53 release, with all clean code in its own repo, to fix this issue.

For the most part, no-one is going to work on an open source project that they can't download and compile; nor do most users want to start working based on unstable stuff. If you want more people involved, then the foundation should be 2.50.2/2.50.3-ish, stable, equal to what they have available as bins, or very close; and something they can compile without jumping through flaming rings, off of the backs of rabid leopards, whilst singing 'Daisy, Daisy'.

I'd say that the way it's packaged now is a prime reason that no-one is working on it except for a few zealots who want to add in all of our 'dream features' as our highest priority.

I'm certainly not here to dissuade any of you from working on 3.x. My main point is that the 2.future group doesn't ultimately care if it's an official release, or a fork. We just feel that by making an official 2.x series of releases, we'd be doing a greater service to the userbase, by not having two different ZCs with similar versioning.

Saffith, I personally don't want to lose the bloke who's done almost all the debugging for the last four to five years, either. I just don't comprehend your objections to what we're doing, unless you just haven't read any of the threads, or PMs? We primarily discuss our agenda in a Skype channel, and then I handle documenting it, and presenting it to the public, so this isn't all simply a list of stuff that we expect you, or anyone else to do.

I really have no idea what you want to do, as everytime I ask, you don't answer. We all have better things to do with our time than argue about this though, which is why I told Gleeok back in January (?) that if we couldn't settle on a plan, our group would just work on 2.53, 2.55, and2.6, and release them on our own, user confusion be damned, because kicking a can back and forth for six months with no finality in decisions on what's going on, is about as close to pure timeiwasting as is possible.

i.e. It's time we could use to make this thing, instead of debating a 'plan', when we have a solid model that clearly differs from the deprecation philosophy. In a few months that we waste debating this, wasting mental energy to stress, and thus losing interest due to the conflict, we could have been at 2.55 with all the new drawing features, and new other things that people want.

Instead, whenever we make progress, this argument resurfaces, and honestly, as I've said before, we'll just do our own thing and release it if this continues. At least that means that something will be released in the next three to ten years. Do we really want 2.11 / 2.50 all over again?

P.S. The five of us involved with 2.future never have arguments like this. We all have similar interests in wat we wsh to accomplish, and are all in the loop. More often than not, problems like this arise from LoC. That's why we all stay in touch constantly, and why we actually plan out our goals in black and white.

Gleeok
06-22-2016, 07:08 AM
Are we still going on about this? -Because I could of sworn that the horse had a proper funeral already, you know, with bagpipes and jets flying overhead and all that crap.


Saffith basically gets to do whatever he wants because he knows what he's doing and he is a respected developer for many, many years throughout the 2.5 process. If you or anyone else can even get close to that level then you can maybe try and talk about how all your ideas are good and everyone else's are shit. That said, Saffith was nice enough to help set the working repository to a more sanitized state (essentially it is currently 2.53+) so that there would be a good jumping off point for everyone that was wanting to work on it. There's really no justification for this type of bickering any longer.


In the past ZC devs would discuss "plans" or ideas on IM, chat, or the forums. Currently we have weird schedules and are only active enough to use the forums. If anyone wants to work on zc and has an idea to improve upon or create a new a sub-system or feature then I reckon the "ZC Development" forum is a good place to work out the logistics of any particular problem or idea with the code.

Tamamo
06-22-2016, 09:46 AM
Okay, so I deleted my above post I'm going to start a new thread and post a link here so we can get this one back on topic.

Tamamo
06-23-2016, 01:36 PM
Fixed

edit: Let's try this again.

Tamamo
07-08-2016, 09:56 AM
Confirmed fixed by Saffith, in fact i didn't have to do anything. It was done in the latest.

Saffith
07-13-2016, 12:35 AM
Oh, this thread still exists, doesn't it?


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.
My only goal right now is to clean up the code so that it's possible to make bigger changes without everything falling apart. Anything else comes after that. Even the AngelScript integration was meant to be to that end.


If what we make works, and people like it, then you can decide if you want to use any of it for zc3.
I don't consider backward compatibility optional. I don't want to put out 3.0 and have it be unable to play a large subset of quests, especially recent ones. If it goes into 2.x, it goes into 3.x.


I just don't comprehend your objections to what we're doing, unless you just haven't read any of the threads, or PMs?
I don't even see PMs here half the time. vB isn't so good with the notifications.


More often than not, problems like this arise from LoC.
... Lines of code?

Gleeok
07-13-2016, 01:41 AM
Do you have notifications turned on under settings?

Saffith
07-13-2016, 02:05 AM
Yeah. They just don't seem to clear properly, so I've got 189 of them. There's a prompt that comes up, too, but not reliably.

Gleeok
07-13-2016, 02:14 AM
"You have 1,309 messages stored, of a total 10,000 allowed"

I'll trade you. :P