weapon -> x, y problem.

[Gleeok]

I'm curious as to why these weapon values are only accessible or modifiable in ZScript as integers and not floats. I imagine these must be floating point in the code and only truncated when rendered, since step speed has become floating point for a while. (I am simply assuming this on the basis that it makes no sense to have something like int x += float x_speed)

Actually now that I think about it, it might be because this was not added until build 700 or so by _L_ I think. Is this feasible to update?

I really don't want to request anything that's not just a simple "fix" at this stage, so no worries, I'm sure I'll figure out a workaround in that case.


EDIT: okay, I am a Dumbass.

EDIT2: huh...I wonder why that doesn't work... Is there any special way weapon trajectories are stored?

[Joe123]

All values in ZScript are read as floats, and how can you have a non-integer position on a pixel grid anyway?

What do you mean by weapon trajectories?

[Gleeok]

All values in ZScript are read as floats, and how can you have a non-integer position on a pixel grid anyway?

What do you mean by weapon trajectories?

No, they are apparently not floats in Zscript.... See for yourself. As for sub pixel accuracy, that's something else altogether. I wasn't in fact referring to that.

[Joe123]

See for myself where?

In ZScript.txt?


ZScript as a language makes no differentiation between int and float, regardless of what the variables are listed as in ZScript.txt.

[Gleeok]

Well if walks like a duck and fucks like a duck... :p

You can't do this for example:


weapon->X += 1.5;

or:


Trace(w->X);


is ALWAYS an int.


so it's a duck then. =P

[Joe123]

You can do it, it's just turned back into an integer because it's stored in the system as an integer.

I still don't understand why you want float values for it though.

[beefster09]

So your weapon can go slower than 1 pixel per frame.

[Joe123]

Weapons can travel at 1/100th of a pixel per frame

Either way though, rather than bothering to get such a feature incoporated, have a go at scripting it yourself!

int counterx; int countery;
while(true){
Link->X += move(nonintegerspeed,counterx);
Link->Y += move(nonintegerspeed,countery);
counterx = (counterx+1)%(100/factors100(Abs(this->Vx)));
countery = (countery+1)%(100/factors100(Abs(this->Vy)));
Waitframe();
}

int move(int s,int c){
int as = Abs(s);
int ret;
if(as < 1){
if(c < as*100/factors100(as)) ret = 1;
else ret = 0;
}else if(as < 2){
if(c < (as-1)*100/factors100(as-1)) ret = 2;
else ret = 1;
}
if(s < 0) ret = -ret;
return ret;
}
int factors100(int s){
for(int i=50;i>0;i--) if((s*100)%i == 0) return i;
}

[Gleeok]

I'm sorry if my posts were confusing in any way, but that's not what I mean.

First of all, that script would be an exercise in futility if you did it with weapons (and not Link or FFCs as you have done), as you'd need a) arrays that store virtual coordinates , b) an algorithm for doing weapon swaps since you can't really be certain which weapon was where on screen before it was destroyed and reordered, c) update them every frame and d) a super fast computer to run it.


And also:



Weapons can travel at 1/100th of a pixel per frame


it's stored in the system as an integer.



EDIT2: huh...I wonder why that doesn't work... Is there any special way weapon trajectories are stored?

Now I'm confused. :confused: If that's correct then you'd need 2 extra variables just to move the object....which now that I think about it might explain this:

When you move a weapon what's happening is it's basically resetting it's stored velocity (or whatever it is that moves the damned things) in effect truncating it's angle. (I explained that stupidly, blah) What I'm saying is that it moves them in only 8 directions instead of 360.

Is this a bug?



edit: I'm sorry if I sound grumpy, I haven't been able to get much sleep this week. :(

[pkmnfrk]

You know, the weapon->Step variable is measured in 1/100th of pixels. Depending on what you need done, just set the ->Angular, ->Angle and ->Step variables, and be done with it.

[Gleeok]

You know, the weapon->Step variable is measured in 1/100th of pixels. Depending on what you need done, just set the ->Angular, ->Angle and ->Step variables, and be done with it.

If it were that easy this thread wouldn't exist, and I'd be done with it.

[pkmnfrk]

Lemme guess, custom movement for weapons?

[Gleeok]

No, that's not it. ..Although why even use weapons....hmmm....* ..*..

No, here's the lowdown, down low: You can't change a weapons location on screen without fucking up its Angle and Angular value for that frame. ..I'm going to repeat that just so there's no doubt as to exactly what I'm referring to.
You can't change a weapons location on screen without fucking up its Angle for that frame.


I also got some sleep. Yay! :)

[pkmnfrk]

fb = Screen->CreateEWeapon(EW_MAGIC);
fb->X = x;
fb->Y = y - 4;
fb->Angle = findAngle(x, y - 4, Link->X, Link->Y);
fb->Damage = 4;
fb->Angular = true;
fb->Step = 200;
fb->UseSprite(17);

An excerpt from my custom boss. Note that it recalculates the proper angle after moving the weapon (since it starts at (0,0), but needs to fire from (x, y-4)).

findAngle is defined in my advmath.zh file (which I just updated (http://armageddongames.net/forums/showpost.php?p=1210500&postcount=13)).