Drakkhen

Hi, I often noticed how external target tracking view can be a problem more than a solution when you totally loose view of your own plane and since I'm working on my own game engine, and my tracking camera doesn't loose neither own plane nor tracked target, even when changing focal (it was my job for eight years to code AIs and VG cams), I give you my own engine's camera ext-tracking behaviour routine source (do whatever you want with it, I'll make the engine GNU): (Alpha is cam elevation angle from [plane to target] line) (Gamma is angle between cam sight and [cam to plane] line) void DrKkCameraman::EvolveTargetTracking() { if(!(SelectedObject && SelectedObject->Target[0])) { // Here I switch cam back to plane pursuit behaviour CameraEvolve=EvolveFollowObject; return; } Vec3D LngCmp=SelectedObject->Pos-SelectedObject->Target[0]->Entity->Pos; float Dist=LngCmp.Magn(); if(Dist!=0.f) LngCmp/=Dist; Vec3D OrtCmp=(LngCmp^(Vec3D(0.f,0.f,1.f)^LngCmp)).Unit(); // ^ stands for vectorial product // Unit makes the vector magnitude 1 float Gamma=Fov*.6f; // Fov in Rad float Alpha=Gamma+Gamma/(1.f+Dist); Pos=SelectedObject->Pos+(LngCmp*cosf(Alpha)+OrtCmp*sinf(Alpha))*30.f; // The camera moves on a 30m radius circle around own plane float Delta=Alpha+Pi-Gamma*.5f; Dir.OrientateYZ(LngCmp*cosf(Delta)+OrtCmp*sinf(Delta),Vec3D(0.f,0.f,1.f)); // Dir is cameraman's orientation matrix // OrientateYZ forces dir's Y (sight) to the first vector // and brings Z as close to second as it can (two vectorial products behind) } It works with ]0;Pi[ focal angles. Never looses sight on both plane and target. The routine may be a bit heavier than yours to compute but it's only once a frame... so...

It really looks like the problem I have. I hope it's the same cause. I'll try this as soon as possible and feedback.

Okay. Tested the stick with other games and on another machine (with 1.02 only, the guy doesn't have the real stuff) and the stick works just fine. The only problem seems to be with 1.1. :(

Not only. And PK is just fine like it is. Regarding damage differences, the same happens to some gun shots. Since these events are relatively scarce, it shouldn't weigthen tracks this much.

Hmmm it seems obvious helmet aiming is disturbed by view changes... here, I describe a framerate/event relation problem. About using other radar modes, missile tracking is not necessarily a radar mode (with heat-seeking heads) and shouldn't be affected by active camera choice (longitudinal plane axis dependant). Next, since IR missile tracking mode keeps you "silent", when you compare missile tracking PK to other tracking modes PKs, you just don't care about them anymore (I get a 80% PK in this mode while 60% in bore, 30% in vertical sweeping and 20% in helmet). 'Bout the way tracks are recorded, it sure will be quite a change, but a replay that doesn't correctly replay is simply useless and, therefore, takes useless place.

Hi, I was making many fights recording replays to store some tactical examples for my team when I noticed some singular results: When shooting missiles, a replay does not ensure the recorded shots to be replayed as they occured in-game. I mean, instead of recording explosion event with actual damage amounts on target, it simply "pulls the trigger" and missile can miss or explode with completely different results on the target. According to targetting mode, it sometimes even miss the trigger pulling. i.e. When you shoot using [6]th targetting mode (missile tracking) the shooting window is very narrow and according to framerate, the missile sometimes doesn't go and keeps under wing. It was critical when switching from cockpit view, where 75% of the missiles were correctly fired, to external view where 0% were fired!!!! So, for some fights where I shot four planes during recording before I land, I have replays where no enemy plane is shot and I get shot in return. There must be a way to see in track file I currently landed, opened pit and turned engines off while no enemy behaviour is stored... I wonder. Recording missile shot, explosion and damage amounts instead of a frame-dependant triggering would ensure replays to be used for demonstrations and exercices, I guess. MP me if replays are needed.

Ok, I just tried and after four flights, the problem didn't occur. But since the joy and its configuration didn't change between 1.02 and 1.1, and since there was no problem at all with 1.0 and 1.02, I don't see how I could correct this right now. As I said, I have no view control set on the joy, I only use keyboard for this. Could be just an hint for devs. Ah... I noticed that SWFFB throttle is not a stable input (value constantly varies) maybe is there some disturbance with this or another input. Edit: Even with joy connected and configured, if we don't touch it in-game, the problem doesn't occur. Seems linked to variation of some sort of the inputs.

No. Simple 1.0 upgraded to 1.1, nothing else. No. Common keyboard numpad control. No. Didn't even tried it once.

So, is there a keyboard or joy event, which could cause this, in the file?

You'll find the track files here (v1.1 tracks, 161Ko). For these three flights, I didn't use keyboard for any view command, only lights, brakes, flaps and gears controls. View rotations for 2 and 3 occurs while no key/button is pressed. View rotation 1 occurs while holding shift to deploy flaps (shift-F). 1- View changes while making the slow right turn to join approach path entrance (when bearing arrives on 345). 2- View changes when plane stops after fake emergency landing (~60kts). 3- View changes at the very same time the plane enters the taxiway. It sometime occurs in a middle of a dogfight, often when between short beacon and runway or on final descent to Kuzy (when it's most dangerous). But it only happens on external and internal (F1, F2), never in free cam, pursuit or locked ones (to target, and fly-by) where camera sight repeatedly refreshes.

No one ever experienced such a problem? I can't figure out how to resolve this without keybord/buttons settings making any difference.

Hi, I noticed, since Flaming Cliffs have been installed, an irregular rotation of the camera (probability 80% left, 20% down-left). The rotation is continuous when started. After many flights and many flight-tests, I at last understood it was linked with the stall-speed/AOA of the aircraft. Don't know why, but whatever plane I fly 25T or MiG, when the aircraft slows two much and AOA climbs, the camera suddenly rotates [down]left. I thought the keyboard/collie-hat controls were to blame but even when removing them in view controls, the problem keeps occuring. Ah... another point: when camera commonly moves/rotates, could it be possible to make its linear and angular speeds fps dependant only and not time-factor dependant? Thanx... Even though, this sim kicks!

Aerobatics pilots can take more than 9Gs without G-suit frequently but for very brief instants. I prefer not to imagine effects on vessels and organs under maintained constraints without equipment. The point here, regarding GLOC and not airframe stress, is more a game-play issue. IMHO, considering an average pilot, good enough but not this perfect, the current G effects seem to act and balance game-play pretty well. Many 1.02 pilots used to tighten their maneuvers without any consideration of G limits (I've seen some stress their plane beyond rational structural limits) and 1.1 brings some temperance to it. That's just fine. I guess a good pilot, IRL or in virtual world, is a pilot who can adapt himself to situations. Since it's far from impossible to win a dog with an F15, I don't see much to argue about.

To devs: Does the brutality of G variation count in time to LOC? I mean that it seems normal (to me) that a pilot breaking violently looses control faster than a pilot tightening an already engaged turn. In real world, the 90s suits still had a response delay. In fact, I like the way Gs work currently since I use that to get rid of sticky enemies (bringing them to 600-700km/h and force them barrelling, which leads to LOC very quickly and gives opportunity to disengage).

Balance at last To me, the game is at last balanced. I use to play MiG and I was amazed to see how F15s were able to take turns at corner speed for minutes ending face to face or in my six. When I watched the replays, I noticed the MiG didn't brought me over 6G during these boring "merry-go-round" sequences while the Eagle was keeping its 8.5-9G circle brightly. So I waited for 1.1 to implement Gs to bring back this to balance and I am just satisfied. Yes I also can experience LOCs but since the MiG slips a bit more through air than the Eagle does, I keep experiencing less Gs thant F15's pilot and that's just fair. Facing Eagles and Flankers remains a match but I don't get that "ahead" anymore. It also forces Eagle drivers to rely on other BFMs than simple circling. I like that. Abour Groove's idea, you also can make GLOC resistance dependent on combined flight hours in pilot's log, that would give it more importance, but there still are cheaters sometimes. Same standard for everyone's just fine.

Don't forget Silent Hunter III that should arrive soon too.

Yeah, but it means another point has to be implemented first: the solution I proposed to make ground attack waypoints stand for ONE-PASS attack, otherwise your wingmen will keep flying over the target until their rests give nutriments to grass. :?

Just keep in mind to be carefull and to know how to count on emergent behaviours. It's interesting to create, on units, really basic behaviours making each of them partially rely on its neighbours ones, this creates (without materially coding it) an emergent group behaviour. The trouble is this behaviour can be eminently realistic, or eminently dumb. :D Only a shi*load of tests can ensure to keep the good results and get rid of the rest. :wink: Edit:Making both unit IAs and group AI usually only gives dumb groups... reason of my suggestion.

+1 :) Edit: in any case (broken DL line, crippled mail service,...), will there be an ID number or anything to be able to get the game without paying twice?

When you'll have one, you'll see there's not necessarily money to waste on such an interface. Enjoy daddy's funds while you still can! @coldscrew: How do you think the "natural" padlock would work for [EOS without radar] users (most of russian non-air2air flights)? Ah... forgot you don't really care about details... :? Anyway, that was funny to read. :roll:

I think there are lots of areas bare enough not to require a complex vegetation modelling and tormented enough not to be boring to patrol, Afghanistan is a good example. :wink:

Hi again. I was wondering if it could be possible to think about some feature for one of the versions to come: when you create a mission, you can see the full composition of every group, so you can choose to simply hide it. My idea was to (automatically or manually) attribute to a group a standard tactical symbol (APP-6 MapSymb) thus when you don't hide a group, if it's not the playable one, you only can see the symbols of the groups without any further information (quite like when you have a tactical situation briefing). Setting it manually would allow simulating intelligence mistakes. Maybe would it be harder for neophites to figure out what the target is even with an accurate symbology (you have to get used to first)... can be optionnal instead of obligatory. But it would be great for briefing look and immersion.

I didn't mean that, I meant in a strike "round", you would be advised to acquire one target, shoot it then quickly target and shoot a second (close enough to the previous one) not to make too much adjustments knowing the last shoot unbalanced your craft... It still means two targets=two shots, but I intended to notify that attacks would be twin-targetting sessions (a pair number in any case) instead of "who cares" ones. :wink: And do you make a real difference between a full loaded rocket launcher and an empty one too? :)

Or maybe have to think out to make two targets shots... avoiding to engage one by one :wink:

So, if I take an Su25 with 2x25MP and 2x29L, approach target and shoot one MP on the only active radar detected, then shoot the 29L on one of the main targets, since the first of each type is on the same side, I'll be just in somethin'deep!?!? :lol: