Jump to content

Rezzing, travel, angles and targets


ItHadToComeToThis
 Share

You are about to reply to a thread that has been inactive for 647 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

So, my wonderful scripter friends. I need your help.

I have been trying to figure out how to solve the following issue but...I will be honest...angles and arcs have never been my thing. But...I want to get better so...

I want to make an attack for this ever elusive combat system I am working on where the avatar fires out 4 blasts at the same time. These four blasts then arc out away from the user as they travel forward and start arcing back in before striking the opponent. One blast fires slightly up and arcs over before coming back down toward the target, two arc from the left and right and the final one arcs underneath and comes back up to strike them.

I am at a loss on how to go about this. I feel there is probably some simple / mid level math that I can use to achieve this but I really don't know where to start. These objects being fired are physical objects.

See diagram if you are confused :

Demo.png 

Link to comment
Share on other sites

There is indeed a fairly straightforward way to do that, although it will take some experimentation to get it right.  Basically, fire your projectile as a physical object but include a script in it that forces a course correction, essentially making it a guided missile.  If I were doing it, I would let my launched acquire the target's position and pass that information to the projectile.  Then I would fire the projectile toward the target but with a nudge that aims it too high (or too low, too left, or too right).  Start a timer in the projectile and then, after a second or two, have the projectile's script make a course correction to the target position that it was fed by the launcher.

As I said, it will take some experimentation to get the magnitude of the force necessary, and to get the timing right, but that's the general idea.

Link to comment
Share on other sites

41 minutes ago, Rolig Loon said:

There is indeed a fairly straightforward way to do that, although it will take some experimentation to get it right.  Basically, fire your projectile as a physical object but include a script in it that forces a course correction, essentially making it a guided missile.  If I were doing it, I would let my launched acquire the target's position and pass that information to the projectile.  Then I would fire the projectile toward the target but with a nudge that aims it too high (or too low, too left, or too right).  Start a timer in the projectile and then, after a second or two, have the projectile's script make a course correction to the target position that it was fed by the launcher.

As I said, it will take some experimentation to get the magnitude of the force necessary, and to get the timing right, but that's the general idea.

Incidentally I'm working on something like this right now. It's not necessarily applicable to the original question, but I rez a physical object (with 0 weight so it's unaffected by gravity) and use llSetVelocity and llRotLookAt to keep the projectile moving at constant speed while slowly arcing towards the intended target.

The core code is essentially:

e5b957c8de.png

Edited by Wulfie Reanimator
  • Like 1
Link to comment
Share on other sites

On 3/31/2020 at 11:15 PM, Wulfie Reanimator said:

Incidentally I'm working on something like this right now. It's not necessarily applicable to the original question, but I rez a physical object (with 0 weight so it's unaffected by gravity) and use llSetVelocity and llRotLookAt to keep the projectile moving at constant speed while slowly arcing towards the intended target.

The core code is essentially:

e5b957c8de.png

I would recommend against a while(TRUE) loop, as an infinite loop like this means that the script will use 100% of the Server's CPU resource given to it, making it laggy. It also means that any other event handlers in the script (ie, touch_start, collison etc) will not run as events are queued whilst code is running and a while(TRUE) loop never stops running.

Instead you can get the same performance, whilst still letting the server process events by running the same code inside a fast running timer.

EG

default
{
	state_entry()
	{
		llSetTimerEvent(1.0 / llGetRegionFPS());
	}

	timer()
	{
		llSetTimerEvent(1.0 / llGetRegionFPS()); // Continually adjust to current simulator framerate.
		// Do the stuff inside the while(TRUE) loop here instead
	}
}

 

Edited by Extrude Ragu
Add missing adjust to region fps
Link to comment
Share on other sites

1 hour ago, Extrude Ragu said:

I would recommend against a while(TRUE) loop, as an infinite loop like this means that the script will use 100% of the Server's CPU resource given to it, making it laggy. It also means that any other event handlers in the script (ie, touch_start, collison etc) will not run as events are queued whilst code is running and a while(TRUE) loop never stops running.

Instead you can get the same performance, whilst still letting the server process events by running the same code inside a fast running timer.

Sure, timer is generally better than a loop for many practical reasons. That said:

An infinite loop won't "use 100% of the server's CPU," it gets scheduled its own time-slice (we're talking tiny fractions of a second) just like every other script. The script has no other events/interactions and needs to run "as far as possible" because it's a very short-lived object. (Moves very fast and won't exist more than a couple seconds.) This isn't my first rodeo either, I'm very aware of all the implications and timer-based updates perform much worse in the environment the code is expected to run in. Slowing down the timer is only going to make things worse because the velocity remains constant.

I might as well have written "while (llVecDist(llGetPos(), target) > threshold" and the loop would not really change. The important thing I specifically need is that the event does not exit before that or a couple other conditions are met. "while(1)" just allows me to clearly describe the flow of the loop (when each condition should be checked) without writing comments.

That's not the point of my post anyway. My case is specific, but the calculations are the generally correct answer.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

  • 2 years later...
On 3/31/2020 at 11:15 PM, Wulfie Reanimator said:

Incidentally I'm working on something like this right now. It's not necessarily applicable to the original question, but I rez a physical object (with 0 weight so it's unaffected by gravity) and use llSetVelocity and llRotLookAt to keep the projectile moving at constant speed while slowly arcing towards the intended target.

The core code is essentially:

e5b957c8de.png

Hi Wulfie, I'm trying to make a similar movement!

Are you able to share the code?

Where do you call "while (TRUE)", and what are the turn_rate values?

Ty & Hug

Edited by Creative Starfall
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 647 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...