Project Reality Forums

Can we talk about this in a constructive manner?

working as intended

The video says pretty much everything. I don't understand if it's a dedication problem, programming logic related or just not simply interested enough to fix it for once or come up with a more generic solution. It would've been a hotfix next day if it was a infantry related issue. The flare issue has been going on for years now. like no fucks given

Not exactly easy to fix something we didn't write. I have no idea why it behaves differently with Jets.

Gib source code.

AlonTavor wrote:Not exactly easy to fix something we didn't write. I have no idea why it behaves differently with Jets.

Gib source code.

Nah, easier to just re-write the lock-on system from scratch. I expect it to be done by 1.6. Get to work Alon

If someone wants to implement missile logic in python it might be doable. I'll help with the API, any volunteers?

When the changes were made that led to this issue, helicopters had exactly the same problem, missiles completely ignoring flares. Then people pointed it out and it was fixed, while the problem remained for jets. Therefore, wouldn't it be possible to do the same for jets?

Holy shit yes me. I'd be interested in doing it. But total noob 3-4 months in python. If anything I wana do it for experience.

AlonTavor wrote:If someone wants to implement missile logic in python it might be doable. I'll help with the API, any volunteers?

So that is actually possible? Also define that pls. You mean the missile movement and rotation and their changes depending on the target that is selected? And also the algorithm of which target is being chosen?

-You can control objects by setting their position and rotation every game tick. When using the engine's default prediction mode (networkableInfo.setPredictionMode PMLinear) they'll be smoothed nicely as long as the object keeps moving (It bugs out if you stop moving the object, which is why we had to make the new laser system look choppy.)

-You can get a list of flares in the air every few game ticks (that query is super unoptimized, takes like 2-4ms, possibly double on linux. Use a system I implemented that synchronizes heavy "tasks" and allows only one heavy "task" per game tick). There's an unused BF2 system that allows you to see how many bullets of what template a player fired that was used for BF2 stats, can maybe use that to figure out if any pilot pooped a new flare and only then do the checks.

-Can cache flying vehicle list, no optimization issues here.

-Check which objects are in the missile's cone using M A T H (Angle between vectors). I would do one "task" for query and another "task" for target acquisition. 5 (x2) ticks a second should still leave 20 ticks a second for other tasks, more than plenty.

-Every game tick check distance to target. Delete projectile if its too close. I am not sure if python-deleting projectile objects triggers the explosion component, we'll have to figure that out, worst case we'll have to setDamage through python to nearby targets, or better I'll memory hack it and edit the part of the projectile that is used for TimeToLive so it artificially times out and explodes.

-Biggest technical problem: have to implement a Python-controlled warning system and locking system. Fortunately Mats has been working on something that can allow us to do these. Though I have no idea how we're going to do the HUD showing "Locked" on a target.

Wow this sounds cool and has a lot of potential to deliver an awesome AA/flare system. I am also interested in at least trying this. Where does a total nub that never used this language start?

You don't.

I'll discuss it with some people internally and then if we find someone willing to work on it. I really don't have time for more tasks.

Maybe I'm wrong,but...
By the way, one question.Does this always happen, or has it started from the last update?

I doubt the missile used has that much impact on it since they all use the same tracking logic. The only real difference would be the speed and turn rate of the missiles but they are more or less the same for the most part and the speed of the aircraft would probably play a bigger factor than the speed of the missile, other than possibly missiles like the Starstreak which are super fast.

close range with rackets.

lakinen wrote:By the way, one question.Does this always happen, or has it started from the last update?

Well, afaik the flares "distraction" towards missiles was made a bit weaker (might be wrong here), but to balance it they were supposed to explode on flares. This definitely would have made jets and helis more skillful, as you would have to know how to utilise your flares and their launchers (are they launching up? down? side?) correctly for maximum survival.

And it seems to work, on the client side atleast. Missiles do go for flares relatively often (I would say less than before the update) and seem to explode on flares. But jets die afterwards anyways often, by missiles. So they seem to explode on a flare, but actually they go through the flare (exploding there and becoming invisible) and then redirect onto the next target and kill it.

Redirects happened before the update, too. Pretty often even. I once sniped a friendly jet 1.3km away from me with a missile going for an enemy jet. Which is another of those weird cases. The enemy jet started burning, yet I also hit a friendly jet far behind him. All with one missile.

The best thing would be to test if missiles behave that way in vanilla BF2 already, I guess.

(everything here reflects my personal experience with AA and such, DEVs might have a different point)

Redirects are an intended vanilla feature.

The rest are shit dice code.

-If someone has time to test, let him try with several different AA systems(not counting on the map

Once again you are way out of your depth here. Even before i made the video me and others did extensive testing on multiple maps with multiple AA systems and jets and let me tell you the result is the same as in my video everywhere with every system type.

Your defintion of active and passive guidance is wrong too and reads like you just made something up that you assumed must be true.

I don't understand why you suddenly claim khami is not a good map for testing? Anyway like i said we tested this on basically every major jet map and one map specifically made for testing with 3km view distance.

Also, if you had read the changelogs you would know that the visual HUD indicator was removed from all AA emplacements, only the audio cue is still there, it doens't have anything to do with the map.

I would assume the flare settings are the culprit here (your info about jets and helicopters using different flares is very telling), but i still don't understand exactly what makes emplaments and AAVs behave differently, meaning pre-flaring is somewhat effective against emplacements trying to shoot through flares while AAVs can just shoot and hit any jet regardless of any kind of pre-flaring being done.

But I give up, I will no longer interfere with this topic.