Hey, I have tried to make a launch function. If called, the object should be launched to the coordinates targetX and targetY. It looks like this:
But it doesn't always hit the target. Sometimes it hits, and other times, it's miles away...
I have already tried making the precision of the angle and speed both higher and smaller, but it never worked 100%.
The object has the action Float, so it isn't affected by gravity or anything.
func Launch(int targetX, int targetY)
{
var ang = Angle(GetX(), GetY(), targetX, targetY);
SetVelocity(ang, 15);
}
But it doesn't always hit the target. Sometimes it hits, and other times, it's miles away...
I have already tried making the precision of the angle and speed both higher and smaller, but it never worked 100%.
The object has the action Float, so it isn't affected by gravity or anything.
And where does targetX and targetY come from? Those must be global coordinates.
They are global. They come from the scenario script:
var clonk = FindObjects(Sort_Random(), Find_ID(Clonk));
var targetX = clonk[0]->GetX();
var targetY = clonk[0]->GetY();
And then you use
If you can't figure it out, try putting a log in there and see if it gives any clues.
For example after the calculation:
xyz->Launch(targetX, targetY);
later?If you can't figure it out, try putting a log in there and see if it gives any clues.
For example after the calculation:
Log("%d|%d to %d|%d at angle %d", GetX(), GetY(), targetX, targetY, ang);
>And then you use xyz->Launch(targetX, targetY); later?
Yes.
Aha. The angles are calculated right. But when I type in editor mode, directly into the object for example
SetVelocity(170, 15)
The object flies straight down. As if it would be 180°. And for 1 - 17 it flies straight up, as if it would be 0.
And it may have something to do with the object itself. Because if I make SetVelocity(3, 15) in a loam chunk, it get's accelerated to the right a bit, like expected. (wich is not the case for my projectiles) I think it's because of the Float action:
local ActMap = {
Float = {
Prototype = Action,
Name = "Float",
Directions = 0,
Procedure = DFA_FLOAT,
Wdt = 8,
Hgt = 8,
Speed = 1000000,
Length = 1,
Delay = 10,
NextAction = "Hold",
}
};
Looks like you found a bug. Though, the x movement for 170° with a velocity of 15 should still be 2.
So I wonder where the error lies. Perhaps it helps to put a Log into SetVelocity.
See the function definition, line 27.
math.floor(math.sin(170*math.pi/180)*15) == 2
So I wonder where the error lies. Perhaps it helps to put a Log into SetVelocity.
See the function definition, line 27.
I found out what caused this! It was SetRDir(). The object moves normal when it doesn't rotate, but as soon as it rotates, the movement gets screwed up. It works now. I have now projectiles that don't rotate. I can launch them and they always hit the target.
But when I go into editor and make SetRDir() to one of the projectiles, that already moves perfectly, the movement is screwed up.
But when I go into editor and make SetRDir() to one of the projectiles, that already moves perfectly, the movement is screwed up.
well… rotation actually changes the movement… who would've thought…
the issue is, that the moment you have an rdir, the internal fixed point position is rounded…
I don't know what this line actually is supposed to do, but imo it can be removed.
Rotating the object should never change the position, right?
or is there something I don't know about attached rotating objects?
[edit] windmills still work after removing that line…
but i noticed, that both with and without that line their center isn't always at the correct position (check out guardian of the windmills, sometimes the round center of the turning part isn't aligned with the correct position on the windmill tower)
which might be due to the fact, that attached objects are aligned to an integer position instead of a fixed point position.
the issue is, that the moment you have an rdir, the internal fixed point position is rounded…
I don't know what this line actually is supposed to do, but imo it can be removed.
Rotating the object should never change the position, right?
or is there something I don't know about attached rotating objects?
[edit] windmills still work after removing that line…
but i noticed, that both with and without that line their center isn't always at the correct position (check out guardian of the windmills, sometimes the round center of the turning part isn't aligned with the correct position on the windmill tower)
which might be due to the fact, that attached objects are aligned to an integer position instead of a fixed point position.
There was a discussion about wings not getting stuck in earth (like it was in CR); back then it was implemented. But the wheel object is invisible, so has nothing to do with visual misplacements.
> [edit] windmills still work after removing that line…
I wouldn't worry too much about windmills (they are attached anyway so they don't call that code). The dangerous parts are probably stuff like pushing of lorries and trees and whether they can get stuck in the landscape by pushing them around. For example, I could imagine that a rotated lorry falls off the elevator if you change it.
If you don't find any side-effects, I'm all for removing that line.
they work just fine… especially since that line is for when the object has NO contacts ;)
Actually, I just saw that attachment in this case is the vertex attachment to landscape. In that case, the script has to stay there. Otherwise, landscape attachment wouldn't update the fixed point positions.
I guess you could change it by adding
I guess you could change it by adding
if (Action.t_attach && !fNoAttach)
to the else clause.
> I don't know what this line actually is supposed to do, but imo it can be removed.
It was essentially added by Sven2 in 2004 with the message "+ Bottom-adjusted WALK-procedure; rotated, attached movement". (I've later touched it in 2008 when I made C4Object store its position only in C4Fixed instead of C4Fixed plus an integer, but didn't change the behaviour then. Or perhaps I accidentally did - I'm not going to go over that code again to find out whether Sven2's code managed to avoid rounding.) In the meantime, we've polished the code above not to carelessly round an object's position. The rotation code should simply get the same treatment.
Why do you convert to angle first?
var dx = targetX-GetX(), dy = targetY-GetY(), d = Max(Distance(dx,dy),1);
SetXDir(dx*15/d);
SetYDir(dy*15/d);
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill