Author
|
Topic: Ur-Quan Dreadnought to be re-named "Banana Boat" (Read 42488 times)
|
|
|
Niles
Zebranky food
 Offline
Posts: 5
|
Yeah, it should take the velocity+direction of the target into account rather than just the position. For a game set in a sci-fi future setting, the homing computers are remarkably stupid...
The game will take a bit more computing power, but that shouldn't be a problem these days.
Basically, at each "homing course change" the projectile should pick a direction that brings it into contact with the target within the projectile's remaining lifetime, taking the target's position, velocity and direction into account. The course that gets to the target the fastest should be taken.
If it is not possible for the projectile to reach its target during its lifetime at the time of being fired, it should just keep going forward (to allow defensive straight shots at long-range attacks). If inability to reach the target happens after being fired, the projectile should still head as close as possible.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender: 
Posts: 3876
We did. You did. Yes we can. No.
|
If you're in a position to get hit by this thing when you wouldn't otherwise, you were sitting pretty stationary right next to its normal trajectory.
Any ship that doesn't cross the unguided trajectory is going to have been missed; while any ship that ends up near that line is at risk from a guided shot.
Secondly, a lot of velocity doesn't do any good if it's in the radial direction, so a fast-moving ship could easily qualify as 'stationary' for these purposes.
How much lateral range are we talking, here? Well, if at the end it has a ten degree homing angle, then it will achieve a lateral offset of 8.7% of its forward range (sin(10 degrees)/2 = 0.087). This is hardly 'right next to', as the range is quite substantial. If it's not enough, we can increase the turn rate appropriately.
I don't get your point about Spathi or Supox shots. If you think the fusion blast is slow, say so. If you think you can run rings around it and confuse it, say so. If you think diving in front of a homing plasma blast is not dangerous, say so.
I'm presently working on implementing this so we can check how useful it is, practically.
Presently, my difficulty is storing the lateral velocity state. MISSILE_BLOCK is the data entry for these missiles, and it doesn't have a 'miscellaneous' entry or an 'other velocity' entry. I remember someone said something somewhere (very useful, I know!) about including some degree of shot relativity for some ship (perhaps hypothetically?). If they found a solution for that, it should be easily adapted to this.
Another solution would be to simply make MISSILE_BLOCK bigger, and have every other missile in the game carry around some state it doesn't need.
|
|
|
|
|
Logged
|
|
|
|
Elvish Pillager
Enlightened
Offline
Posts: 625
|
How much lateral range are we talking, here? Well, if at the end it has a ten degree homing angle, then it will achieve a lateral offset of 8.7% of its forward range (sin(10 degrees)/2 = 0.087). This is hardly 'right next to', as the range is quite substantial. If it's not enough, we can increase the turn rate appropriately. Considering that it turns over the course of its flight, that'd be about half what you say - about 4.4% of its range, which is 17.6 display units - less than the width of an Ur-Quan...
I don't get your point about Spathi or Supox shots. If you think the fusion blast is slow, say so. If you think you can run rings around it and confuse it, say so. If you think diving in front of a homing plasma blast is not dangerous, say so. It's slow ; you can't run rings around it ; diving into its path carelessly is dangerous but crossing its path while in flight is possible to do while paying attention, without risk.
Presently, my difficulty is storing the lateral velocity state. MISSILE_BLOCK is the data entry for these missiles no ; MISSILE_BLOCK is just for creating a new missile.
|
|
|
|
|
Logged
|
My team of four Androsynth and three Chmmr is the most unfair team ever! My mod |
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3876
We did. You did. Yes we can. No.
|
Here's a diff file that describes the changes to the code. I have verified that this correctly compiles to an object file. However, I do not have all the needed libraries, so I can't build the full game myself.
Problems may arise if the velocity values are low enough that dividing by 114 results in large rounding errors. If so, we can do larger turns less frequently than every frame.
109a110,161
> #define FUSION_TURN_FRAC 114
> #define FUSION_TURN_TRIGGER_FACTOR (FUSION_TURN_FRAC / 2)
> static void fusion_preprocess ( PELEMENT ElementPtr)
> {
> ELEMENTPTR eptr;
> SIZE delta_x, delta_y, vx, vy, re, im;
> if (ElementPtr->hTarget)
> {
> LockElement (ElementPtr->hTarget, &eptr);
> delta_x = eptr->current.location.x
> - ElementPtr->current.location.x;
> delta_y = eptr->current.location.y
> - ElementPtr->current.location.y;
> UnlockElement (ElementPtr->hTarget);
> delta_x = WRAP_DELTA_X (delta_x);
> delta_y = WRAP_DELTA_Y (delta_y);
> /*
> If we want to make it lead the target, then we'll need to add
> (target's velocity) * (time to pass) to these deltas.
> */
>
> GetCurrentVelocityComponents(&(ElementPtr->velocity), &vx, &vy);
> /*
> Next I figure out which way to turn.
> The logic here is analogous to imaginary number multiplication.
> I multiply the delta (x + iy) by the complex conjugate of the velocity (x - iy).
> (instead of dividing delta by velocity, which would take a division -- we only need direction, not magnitude)
> The result is a course correction vector.
> */
> im = vx * delta_y - vy * delta_x;
> re = vx * delta_x + vy * delta_y;
>
> // If tan of our course correction < FUSION_TURN_TRIGGER FACTOR, it's close enough that correcting would overshoot.
> if ( re < 0 || im * FUSION_TURN_TRIGGER_FACTOR > re ) // need to turn
> {
> if (im > 0) // The course correction is above the real axis, so I need to turn left.
> { // add a small orthogonal component. Failure to take away from forward component only adds 0.0008% to speed.
> im = vx - vy/FUSION_TURN_FRAC;
> vy = vy + vx/FUSION_TURN_FRAC;
> vx = im;
> }
> else // The course correction is below the real axis, so I need to turn right.
> {
> im = vx + vy/FUSION_TURN_FRAC;
> vy = vy - vx/FUSION_TURN_FRAC;
> vx = im;
> }
> SetVelocityComponents(&(ElementPtr->velocity), vx, vy);
> }
> } // end if there's an enemy ship
> } // end fusion_preprocess(...)
>
132c184
< MissileBlock.preprocess_func = NULL_PTR;
---
> MissileBlock.preprocess_func = &fusion_preprocess;
|
|
|
|
« Last Edit: May 09, 2008, 04:39:05 pm by Death 999 »
|
Logged
|
|
|
|
0xDEC0DE
*Many bubbles*
Offline
Posts: 175
|
Normal diffs make baby jesus cry. Unified diffs are better for moving targets like this one, as they preserve a bit of context, and can account for "code drift". But even then, up-to-date SVN is different than 0.6.2 (e.g., ELEMENTPTR was deprecated/removed)
If that weren't bad enough, this patch doesn't do anything.
ElementPtr->hTarget is always NULL in this context, turning the whole function into a big, complicated no-op. You'll need to walk the element list, looking for the opposing ship, or just use TrackShip() in src/sc2code/weapon.c to do it for you.
Here's a patch against "current" SVN (r2983) that's effectively a drop-in of the Cruiser's homing projectile, but with the homing aspect severely dialed-down to the point that it is a very weakly-tracking missile:
Index: src/sc2code/ships/urquan/urquan.c
===================================================================
--- src/sc2code/ships/urquan/urquan.c (revision 2983)
+++ src/sc2code/ships/urquan/urquan.c (working copy)
@@ -111,6 +111,42 @@
0,
};
+#define TRACK_WAIT 12
+
+static void
+fusion_preprocess (ELEMENT *ElementPtr)
+{
+ COUNT facing;
+
+ facing = GetFrameIndex (ElementPtr->next.image.frame);
+ if (ElementPtr->turn_wait > 0)
+ --ElementPtr->turn_wait;
+ else
+ {
+ if (TrackShip (ElementPtr, &facing) > 0)
+ {
+ ElementPtr->next.image.frame =
+ SetAbsFrameIndex (ElementPtr->next.image.frame,
+ facing);
+ ElementPtr->state_flags |= CHANGING;
+ }
+
+ ElementPtr->turn_wait = TRACK_WAIT;
+ }
+
+ {
+ SIZE speed;
+
+#define THRUST_SCALE DISPLAY_TO_WORLD (1)
+ if ((speed = MISSILE_SPEED +
+ ((MISSILE_LIFE - ElementPtr->life_span) *
+ THRUST_SCALE)) > MISSILE_SPEED)
+ speed = MISSILE_SPEED;
+ SetVelocityVector (&ElementPtr->velocity,
+ speed, facing);
+ }
+}
+
static COUNT
initialize_fusion (ELEMENT *ShipPtr, HELEMENT FusionArray[])
{
@@ -133,7 +169,7 @@
MissileBlock.hit_points = MISSILE_HITS;
MissileBlock.damage = MISSILE_DAMAGE;
MissileBlock.life = MISSILE_LIFE;
- MissileBlock.preprocess_func = NULL;
+ MissileBlock.preprocess_func = &fusion_preprocess;
MissileBlock.blast_offs = MISSILE_OFFSET;
FusionArray[0] = initialize_missile (&MissileBlock);
Now you can actually try it instead of postulating endlessly about its effectiveness. Enjoy.
|
|
|
|
« Last Edit: May 20, 2008, 09:51:33 pm by 0xDEC0DE »
|
Logged
|
"I’m not a robot like you. I don’t like having disks crammed into me… unless they’re Oreos, and then only in the mouth." --Fry
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3876
We did. You did. Yes we can. No.
|
Having finally gotten it compiled properly, I noticed what Nic noticed and came up with the same fix.
I mean, the same one he had before he totally replaced it with something that basically functions, but acts way too much lie the cruiser's missile.
Which is better than what I had up there, which kind of wiggles around and then swerves off in a random direction.
|
|
|
|
« Last Edit: May 20, 2008, 10:06:41 pm by Death 999 »
|
Logged
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3876
We did. You did. Yes we can. No.
|
I didn't notice this, but I wanted to say:
How much lateral range are we talking, here? Well, if at the end it has a ten degree homing angle, then it will achieve a lateral offset of 8.7% of its forward range (sin(10 degrees)/2 = 0.087). This is hardly 'right next to', as the range is quite substantial. If it's not enough, we can increase the turn rate appropriately. Considering that it turns over the course of its flight, that'd be about half what you say - about 4.4% of its range, which is 17.6 display units - less than the width of an Ur-Quan...
No, I already put in the half -- see that /2 in there? I know math. Plus, that was a first guess - as I said, If it's not enough, we can increase the turn rate appropriately.
I think I'll take another stab at this soon.
We could alternately bring the speed to the fusion blast up to that of the faster weapons such as Orz shots (from 20 to 30). Or both.
|
|
|
|
|
Logged
|
|
|
|
tartarus
Zebranky food
Offline
Posts: 11
|
What if the ur-quan fusion bolt would explode after few seconds (the range should stay same) and make some blast damage ? Blast effect could be as large as shofixtis explosion but with considerable less damage. Like 1 point of damage if the target is at max range.
Then it wouldnt be such as sucky ship but not overly powerful either ?
Small low cost ships wouldnt then rip ur-quan apart very easily.
And the fighter craft should be made better like there has been previously mentioned.
|
|
|
|
|
Logged
|
|
|
|
|
|
tartarus
Zebranky food
Offline
Posts: 11
|
Yeah, what do you think, is this stupid idea or not? 
|
|
|
|
|
Logged
|
|
|
|
|
|
|
