Projectile spawning trouble

#1

Quote:
i believe it is a network trouble.

Do you need to up the standard network prefs? Try this and see if it makes a difference.

$Pref::Net::LagThreshold = "400";
$pref::Net::PacketRateToClient = "32";
$pref::Net::PacketRateToServer = "32";
$pref::Net::PacketSize = "450";

Also what type of multi-spawn script are you using? Does it contain "shellcount"? That's the shotgun resource that I use

#2 How did you create these 7 projectiles? The FPS kit was intended to include a "shotgun" type weapon and it spawned 12-16 projectiles. I don't recall any delays but then it's been a while since I messed with that since it got dropped.

#3 Just tried this code with the AssaultBuggy -- worked good for me.

// Fake, cheap, and very effective vector scattering functions
// Recommended entry values for amount are 0-10
function ScatterVector(%vector, %amount)
{
   return vectorAdd(%vector, ScatterAngle(%amount) SPC ScatterAngle(%amount) SPC ScatterAngle(%amount));
}

//Support function for ScatterVector
function ScatterAngle(%angle)
{
   %angle *= 100;
   return (getRandom(%angle * -1, %angle) / 10000);
}

function BuggyBlasterImage::onFire(%this, %obj, %slot)
{
   %projectile = %this.projectile;

   // Decrement inventory ammo.
   %obj.decInventory(%this.ammo,1);

   for (%i = 0; %i < 12; %i++)
   {
      //%muzzleVector = %obj.getMuzzleVector(%slot);
      %muzzleVector = ScatterVector(%obj.getMuzzleVector(%slot), 8);
      %objectVelocity = %obj.getVelocity();
      %muzzleVelocity = VectorAdd(
      	VectorScale(%muzzleVector, %projectile.muzzleVelocity),
      	VectorScale(%objectVelocity, %projectile.velInheritFactor));

      // Create the projectile object
      %p = new (%this.projectileType)()
      {
         dataBlock = %projectile;
         initialVelocity = %muzzleVelocity;
         initialPosition = %obj.getMuzzlePoint(%slot);
         sourceObject = %obj;
         sourceSlot = %slot;
         client = %obj.client;
      };
      MissionCleanup.add(%p);
   }
   return %p;
}

#4 Steve, you've got a beer.
I actually up the PacketSize today,but the problem was PacketRateToClient.
Thank you.

#5 The default packet rates are still set for the dialup age -- you can adjust those based on your network, but other connecting players may need to change their settings from your "new" defaults. Also, try not to up the packetsize too much or it could cause additional troubles.

#6 @Michael
That's a different variety of scatter weapon than I've seen.

datablock ShapeBaseImageData(ShotgunImage)
{
//.......
projectileSpread = 12/800;
//.......
}

function ShotgunImage::onFire(%this, %obj, %slot)
{
%projectile = %this.projectile;

// Get the weapons projectile spread and ensure it is never 0 
// (we need some spread direction even if it is extremely tiny)

%spread = %this.projectileSpread;
%spread = %spread $= "" ? 0.001 : %spread;
%spread = %spread <= 0 ? 0.001 : %spread;

%shellcount = 8;

 // Decrease the weapons ammo on fire
//%obj.decInventory(%this.ammo,1);//demo - infinite ammo

// Create each projectile and send it on its way 
for(%shell=0; %shell<%shellcount; %shell++)
{
// Get the muzzle vector. This is the dead straight aiming point of the gun
%vector = %obj.getMuzzleVector(%slot);

// Get our players velocity. We must ensure that the players velocity is added 
// onto the projectile
%objectVelocity = %obj.getVelocity();

// Determine scaled projectile vector. This is still in a straight line as 
// per the default example
%vector1 = VectorScale(%vector, %projectile.muzzleVelocity);
%vector2 = VectorScale(%objectVelocity, %projectile.velInheritFactor);
%velocity = VectorAdd(%vector1,%vector2);

//accuracy = 800

if($Zoomon == true)
{
%x = (getRandom() - 0.5) * 2 * 3.1415926 * %spread * 0.3;//equivalent to 240 for single shot
%y = (getRandom() - 0.5) * 2 * 3.1415926 * %spread * 0.3;//
%z = (getRandom() - 0.5) * 2 * 6.1415926 * %spread * 0.3;
%mat = MatrixCreateFromEuler(%x @ " " @ %y @ " " @ %z);
}
else
{
if($Zoomon == false)
%x = (getRandom() - 0.5) * 2 * 4.1415926 * %spread * 0.6;
%y = (getRandom() - 0.5) * 2 * 3.1415926 * %spread * 0.6;
%z = (getRandom() - 0.5) * 2 * 8.1415926 * %spread * 0.6;
%mat = MatrixCreateFromEuler(%x @ " " @ %y @ " " @ %z);
}

// Alter our projectile vector with our spread matrix
%velocity = MatrixMulVector(%mat, %velocity);

%p = new (%this.projectileType)()
{
dataBlock = %projectile;
initialVelocity = %velocity;
initialPosition = %obj.getMuzzlePoint(%slot);
sourceObject = %obj;
sourceSlot = %slot;
      client           = %obj.client;
};
MissionCleanup.add(%p);
}

return %p;
}

Shotgun Resource modded to use my zoom function for ADS accuracy.

#7 Yeah, I came across those vector "helper" functions a few weeks ago and ended up liking them -- a lot! I used to use something similar to that Shotgun Resource and it does work well. I like what you did there with the different amounts of scatter whether you're zooming or not.

It looks like you're spreading around a circle more than once though. Anything greater than pi in radians simply loops back around... so you might actually be doing a few calculations more than you need. 0 = 0 degrees, 3.141592 = 360 degrees.

I've condensed those three lines (X Y Z) into one by using a for loop in the FPS Genre Kit -- take a look at weapon.cs.

for(%i = 0; %i < 3; %i++)
   %matrix = %matrix @ (getRandom() - 0.5) * 2 * 3.1415926 * %this.projectileSpread @" ";
%mat = MatrixCreateFromEuler(%matrix);

You've kind of given me an idea with your ADS accuracy... you can also do all kinds of crazy things by adjusting spread when you're running and especially jumping :D

#8 The reason I increased beyond pi was that I found it would distort the shape of the matrix on things like the z axis (a hack to get the muzzle just fake an upward jump when fired). I guess I should have altered the * 2 * part instead.

Also I found that whilst X is left and right, Z was up and Y was down. I did work out why this was but have forgotten right now. Hence why I keep Y lower to reduce the downwards vector chance of a projectile, guns jump up (press back) and usually don't recoil downwards. I haven't tried the new "push arms up recoil" in the FPSkit on my custom stuff yet.

#9 hmm i learned something new, i didnt realize torque truncated the pi value in radians to pi=360 degrees which is weird, since basic trig says 2pi radians =360 degrees...i will have to play with that on my own shotgun..

#10

Quote:
I keep Y lower to reduce the downwards vector chance of a projectile, guns jump up (press back) and usually don't recoil downwards.

You know, I never really thought about that before in terms of recoil -- I just think of it as simple bullet skew -- so I can see why you wouldn't want to "condense" it.

I actually don't like the "push arms up recoil" myself -- it annoys the crap out of me. I found two other uses for it though that aren't related to recoil, if it wasn't for that I would have already removed it ;)

Oh yeah, the "bullet skew" projectile spread doesn't really play all that well with the "push arms up recoil" effect -- and it can be downright dizzying and disturbing using the faked recoil with on a weapon with a high rate of fire.

About radians I was way too sober earlier :D I misspoke about the actual ranges. 360 degrees is 2pi radians, sorry about that. What's happening is that since random numbers are being used the relevant angles end up being positive 0 to 180, and the inverse of that -- it seems to actually be 0-240 degrees and I'll explain that too. So for the purposes of projectile spread you end up with a range of 360 degrees that covers the values between -180 degrees to 180 degrees (-3.14 to 3.14). But, there's always a but, you can actually go upwards to 240 degrees (4.18879 radians) but anything larger will (appears to) revert to a negative number. So instead of adjusting or checking for a cap I've always went with 0 to 180 degrees and an inverse value to cover 360 degrees -- it somehow seems simpler to me... and come to think of it you probably aren't doing any extra calculations by using larger values because I'm almost certain that a modulo operation is probably being done when it hits the engine.