Not logged inOpenClonk Forum
Up Topic General / Help and Questions / [Script Question] SetVelocity()
- - By Pyrit Date 2013-02-25 22:46
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:

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.
Parent - - By Newton [de] Date 2013-02-25 22:50
And where does targetX and targetY come from? Those must be global coordinates.
Parent - - By Pyrit Date 2013-02-25 23:04
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();
Parent - - By Zapper [de] Date 2013-02-25 23:18
And then you use 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);
Parent - - By Pyrit Date 2013-02-25 23:45 Edited 2013-02-25 23:53

>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",
  }
};
Parent - - By Newton [de] Date 2013-02-25 23:59
Looks like you found a bug. Though, the x movement for 170° with a velocity of 15 should still be 2.
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.
Parent - - By Pyrit Date 2013-02-26 01:10
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.
Parent - - By ker [de] Date 2013-02-26 11:10 Edited 2013-02-26 11:24
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.
Parent - - By Newton [de] Date 2013-02-26 13:39
What, since when is the windmill wheel an own object?
Parent - By Clonkonaut [de] Date 2013-02-26 13:48
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.
Reply
Parent - By ker [de] Date 2013-02-26 14:12
ok, my error :) I thought it was
Parent - - By Sven2 [de] Date 2013-02-26 16:15 Edited 2013-02-26 16:18

> [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.
Parent - By ker [de] Date 2013-02-26 16:22 Edited 2013-02-26 16:25
they work just fine… especially since that line is for when the object has NO contacts ;)
Parent - - By Sven2 [de] Date 2013-02-26 16:22
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 if (Action.t_attach && !fNoAttach) to the else clause.
Parent - - By Sven2 [de] Date 2013-02-26 16:24
...plus only do it if Shape.Attach actually changed the coordinates.
Parent - By Günther [de] Date 2013-05-25 14:11
Done.
Reply
Parent - By Günther [de] Date 2013-02-26 16:56

> 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.
Reply
Parent - - By Zapper [de] Date 2013-02-26 07:35
Do you set SetComDir(COMD_None); after setting the action?
Parent - By Pyrit Date 2013-02-26 15:44 Edited 2013-02-26 15:50
Yes, but after SetRDir() the movement is still corrupted.
It doesn't seem to have anything to do with the float action, btw. Same is for a simple rock in zero gravity. When it has RDir, it can only move at a few angles.
Parent - - By Sven2 [de] Date 2013-02-26 01:27
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);
Parent - By Pyrit Date 2013-02-26 01:51
Because even that didn't work with SetRDir() :(
Up Topic General / Help and Questions / [Script Question] SetVelocity()

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill