Project Reality Forums

Celestial1 wrote:Is it possible to trigger the destruction of the laze object when the operator leaves the GLTDs (as in, right clicks)?

Im interested in this.

[R-DEV]Rhino wrote:Ye the relock time of an "armed" weapon that's already flying should be made to 0, at least for most Air to Ground weapons but that code might be the lock time for when your trying to lock onto a target, before launch.

The problem is that you cant set the lock time for an armed missile. If you set ObjectTemplate.seek.reLockTime in the missile code to 0, you can shoot w/o lock and the missile will search its on target. So reLockTime needs to be higher than the initial weapon controlled lock time.
So all in all, nothing on the lock system can be changed with out it becoming weird.

Is it possible to trigger the destruction of the laze object when the operator leaves the GLTDs (as in, right clicks)?

Not sure if possible (i would say no), but even if it wouldnt be worth anything as you could just stare at a wall with gltd out while the cas strikes.

[R-DEV]Rhino wrote: Ye the relock time of an "armed" weapon that's already flying should be made to 0, at least for most Air to Ground weapons but that code might be the lock time for when your trying to lock onto a target, before launch.

I'm not sure about setting re-lock to 0. Won't it allow drooping bombs from very high altitude, outside AA range like in older versions?

Mats391 wrote:The problem is that you cant set the lock time for an armed missile. If you set ObjectTemplate.seek.reLockTime in the missile code to 0, you can shoot w/o lock and the missile will search its on target. So reLockTime needs to be higher than the initial weapon controlled lock time.
So all in all, nothing on the lock system can be changed with out it becoming weird.

Ah yes your right there, forgot about that one

[R-DEV]Moszeusz6Pl wrote:I'm not sure about setting re-lock to 0. Won't it allow drooping bombs from very high altitude, outside AA range like in older versions?

Ye, as well as firing missiles out of range too just "towards" the target and them picking it up on their own.

Good job on the fast travel speed without bouncing.

The high relock time is there for a reason, like you guys discovered.

Lasing choppers is still an issue, but I think it's minor, and I'm interested in trying to decrease the laser time to live.

If the laser disappears while the bomb/missile is in the air, I'm pretty sure it just goes straight to where it got locked in the first place. If it's a moving vehicle, it will miss it, but it will hit stationary targets just fine. Honestly I kinda like that, makes it so laser guided missiles are more useful against moving targets but it's dangerous for the CAS chopper, and laser targeted are more specific for stationary targets.

If the Forward Observer is skillful and in good comms with the CAS, it could still get laser targeted missiles/bombs on moving targets, but it's harder to hit targets on the move. Would be cool to decrease the amount of super accurate chasing bombs.

One thing that should be noted is that if it looses sight of one laser target, providing there is another one in sight, it will lock onto that, in the same way as if a jet pops flares, the missile will then track the flare from tracking the jet, then after it passes the flare, it might go back onto tracking the jet if the jet is still in its "lock cone", and then if it misses the jet, it can still find other targets after it, which is why you commonly see missiles TK a friendly, if your firing at an enemy jet chasing a friendly one, and the missile misses the enemy jet, it can then hit the enemy jet in front of the enemy jet you where trying to kill as the missile has no idea what team its on once launched and goes for any target it can find

So yes, it should be possible to have shortish live times, providing the life of the lase lasts long enough for the jet to get the initial lock on it, and a new lase is on the target before the old one expires.

So to put this into a basic context, we could set the lase up with a time to live of something like 5 seconds, a time for the jet to lock the target of something like 2 or 3 seconds, and have the SOFLAM fire in automatic mode with a rate of fire of around 15 rounds per min (1 round every 4 second), and with a round travel time of less than a second to reach the target (the smaller the better) the jet then should be able to lock onto a lase target in good time, while also there constantly being at least 1 lase on the target at all times for the bomb/missile to keep on tracking the target after the old lase goes

But we would need to test that the missile/bomb is not too confused with the new lase replacing the old lase in flight, mainly at the crucial last second before impact and also it isn't too hard to lock onto a target from the air with new lases appearing too. But in theory, it should work

Mats391 wrote:even if it wouldnt be worth anything as you could just stare at a wall with gltd out while the cas strikes.

On it's own, yeah. But combining it with a few things might allow for faking the need to keep pointing on target to laze.

[R-DEV]Rhino wrote: So to put this into a basic context, we could set the lase up with a time to live of something like 5 seconds, a time for the jet to lock the target of something like 2 or 3 seconds, and have the SOFLAM fire in automatic mode with a rate of fire of around 15 rounds per min (1 round every 4 second), and with a round travel time of less than a second to reach the target (the smaller the better)

Sounds like a good idea, but i would rather decrease the lock time to something like 0.5seconds as otherwise you would have to wait 2 seconds for next lock when the laser gets refreshed. Also the projectile can travel at 1500m/s (max speed for objects) so maximum travel time on normal maps (view distance <1000m) is 0.666s.
At last i would add a laser guided compound to the lase-projectile so the refreshing one will land at same spot as the one before.

Mats391 wrote:At last i would add a laser guided compound to the lase-projectile so the refreshing one will land at same spot as the one before.

What if you miss with the first laze? This would stop you from correcting it, wouldnt it?

lucky.BOY wrote:What if you miss with the first laze? This would stop you from correcting it, wouldnt it?

small lock cone + lock on time. When tweak correctly it will be easy to correct it.

Found some more problems.
1. The laser guided lase projectile didnt turn out as a good idea. Sometimes there is still a gap between the target and the laser so all following lasers would miss
2. Sometimes it seems like the lase flies through a vehicle if it is moving.
3. Sticky projectiles (no matter the speed or physics type) and rotational bundle dont mix well. This most visible on tank turrets. On those the lase can still stick to air very far from the target

Couldnt test if the low lase lifetime works, bots dont like to use them

Mats391 wrote:Sounds like a good idea, but i would rather decrease the lock time to something like 0.5seconds as otherwise you would have to wait 2 seconds for next lock when the laser gets refreshed. Also the projectile can travel at 1500m/s (max speed for objects) so maximum travel time on normal maps (view distance <1000m) is 0.666s.

As for lock on time, would have to see what works, don't want it too short but ye, don't want to have to wait if you time it wrong which is quite likley.

Mats391 wrote:At last i would add a laser guided compound to the lase-projectile so the refreshing one will land at same spot as the one before.

I think this will work very well as like lucky said, if you miss with the first one then you will have to wait some time to correct and the nice thing about updating lase targets is that you can change the location.

Mats391 wrote:3. Sticky projectiles (no matter the speed or physics type) and rotational bundle dont mix well. This most visible on tank turrets. On those the lase can still stick to air very far from the target

Is this just with the laser targeted lases or in general? Is it any better or worse than the current system?

Really this is the thing I would like to see fixed the most here. Dose toning down the speed with the new physics system help with this at all?

Mats391 wrote:Couldnt test if the low lase lifetime works, bots dont like to use them

Ye that's something we are going to have to test with multiple players.

[R-DEV]Rhino wrote: Is this just with the laser targeted lases or in general? Is it any better or worse than the current system?

Really this is the thing I would like to see fixed the most here. Dose toning down the speed with the new physics system help with this at all?

Fast projectiles in general + sticky comp + moving target = bad physics. It gets better the slower the projectile is but even with 250m/s (current lase speed) it still happens. It is however better than current, especially when it comes to stationary targets.
The best thing would be to get lases that dont rely on sticky comp. The only thing i can think of that stays with a moving target are the bullet holes, but so far i didnt manage to add a laser target to it.

Mats391 wrote:Fast projectiles in general + sticky comp + moving target = bad physics. It gets better the slower the projectile is but even with 250m/s (current lase speed) it still happens. It is however better than current, especially when it comes to stationary targets.

ye, well if worst comes to worst we could just slightly improve our current system by changing the physics type

Mats391 wrote:The best thing would be to get lases that dont rely on sticky comp. The only thing i can think of that stays with a moving target are the bullet holes, but so far i didnt manage to add a laser target to it.

Ye this is pretty much what db originally looked at afaik, with trying to attach a laser target to the explosion effect of the soflam projectile, although don't think he tried doing it to the decal but it all comes down the same basic problem of networkables

It may be possible to try and add an object spawner, which then spawns a laser target to an effect but I doubt that's possible either.

[R-DEV]Rhino wrote:Ye this is pretty much what db originally looked at afaik, with trying to attach a laser target to the explosion effect of the soflam projectile, although don't think he tried doing it to the decal but it all comes down the same basic problem of networkables

It may be possible to try and add an object spawner, which then spawns a laser target to an effect but I doubt that's possible either.

Tried all of that already and none work
I guess the projectile could be sped up a bit, just no where near the 1000+ speed that i wish it had :/

the low velocity was done as lastertargets stick for 30 secs, it is not really a new discovery.
the spotter needs some time to lase a moving target which is much harder on a great distance with a low speed of the laser. otherwise you can instant lase, duck and cover and wait for cas taking out targets. which is unrealisitc as you need a constant lase connection.

if you can manage to get a wire connection working on a dedicated server, that would be awesome ofc.

Hey Mats have you made any more progress on this? Even if we just get our lasers sticking on targets better that would be a massive improvement alone

[R-DEV]Rhino wrote:Hey Mats have you made any more progress on this? Even if we just get our lasers sticking on targets better that would be a massive improvement alone

I didnt really continue to work on it as K4on said it was already known to you, but just using RotationalPoint instead of Point as physics type seems to be a huge improvement.
For example i tested Point vs RotationalPoint both with the current 250m/s

The RotationalPoint ones stick tighter to where you aim and are more consistant. With Point they sometimes didnt stick at all while RotationalPoint did just fine.

I think K4on might have been talking about the low velocity although the main reason that was in so it would stick on the object and not bounce off.

The example you posted is excatly what I was hoping to see

So all I need to change is the projectile's ObjectTemplate.physicsType from Point to RotationalPoint from the current v1.0.36.0 code and this will drastically improve how well the projectile sticks on the target as well as work on dedicated etc without any errors etc? If so will commit that now to the next build

Cheers!

[R-DEV]Rhino wrote: So all I need to change is the projectile's ObjectTemplate.physicsType from Point to RotationalPoint from the current v1.0.36.0 code and this will drastically improve how well the projectile sticks on the target as well as work on dedicated etc without any errors etc? If so will commit that now to the next build

Cheers!

Yep, thats all i did and in my tests it always sticks better or same place as current physics type. I couldnt find any errors and it works the same on local and dedicated.