Quip

I know all of that, which is in the manual. But it's not stated if or not switching runway "moves the truck". IRL you wouldn't switch runway without coordination with the ground, who would then move the truck accordingly. In the game, I can switch runway, but "the truck doesn't move" (I know it doesn't exist other than a set of coordinates). So that is my "bug" I guess. That IRL if you're asked/told to switch runway it'll come with the move of the truck, or rather the position of the TILS emitter. In the game, so far, it doesn't.

So I don't know if this is per design or a limitation or a bug. And I don't know if it's maybe the same basic issue that's discussed here But here goes... So if I select the opposite runway for L1 *) than the one given to my when loading the data cartridge I don't get proper TILS. I get TILS, but it guides me to the far end of the (now) selected runway, in fact to the point where I would be landing if I had remained on the original runway heading. So if this is a bug, well er... If it's by design, let me know and us know by documenting it. Or is it already documented but it's me who's missed this? *) Done by selecting AKT POS -- L -- BANA -- L -- AKT POS Cheers

EXCELLENT drawing!! :thumbup:

What I think could be done about this is to let the AC "auto-repair" Engine damage if you stay on the ground for X minutes, or with the "Repair" ground crew option. I know that's not entirely as it works IRL, but hey, is the "repair" realistic? What I'm saying is that I'm OK with the engine actually getting the odd damage as it is currently doing, but I would like to be able to take-off again. At least after a repair... Any thoughts?

Haha, well, guess what? BUMP!! I have the same problem. So here they've stopped. But I can manually as GAME MASTER add SET TARGET and they will resume... For while, then stop again... See attached image.

Sound is excellent. The sound may be the generator if it's on?

My friend I flew with today had the same experience.

It is in the manual in fact:

I think this is unreported. Situation: AJS37 at Tbilisi airport code 18 (hot or cold). See this link for image Case 1 - Normal Situation: AJS37 at Tbilisi (hot or cold) Parking on main apron. When in Cockpit, CK37 displays airport reference code 18 the code for Tbilisi This is the expected behavior Case 2 - FARP Situation: AJS37 at Tbilisi (hot or cold) FARP added inside 5km radius. When in Cockpit, CK37 displays airport reference code 22, the code for the FARP This is wrong Case 3 - "Soganlug" Situation: AJS37 at Tbilisi (hot or cold) Parking on far parking When in Cockpit, CK37 displays airport reference code 19 the code for Soganlug This is wrong Findings: When the AJS is set to takeoff and there's another aiport or FARP within 5km, depending on the exact positions between the aircraft and the other field, the navigation system will boot with up the other fields reference code. This is not "fixable" from the cockpit, you can not change the LS reference code: when the aircraft is subjected to this bug, the navigation seizes to work properly at all I hope this hasn't been reported previously,

What keeps surprising me is how accurate F-14 Fleet Defender was back in the mid 90's; hardly anything Heatblur has shown us was wildly wrong or un-implemented in that game!

Hello Topic spells it out. I've searched but not found anything. I play on 3 screens, so the Overlay Radar ends up on the far right, which isn't great to say the least. Does anyone know what to edit to move it around, where is it defined?

OH?? Is that a bug or a real life limitation? Seems rather suspicious that it'd be like that IRL, as how can you know if there are 2 or 3 ships for certain? Other possible "error" is that we re-armed. If I understand the current state of affairs correctly, most missiles miss(*pun*)behave if you rearm.

Tjena RagnarDa Don't know if this helps at all, but Iäm posting this as much to understand myself and to aid you in ironing out the bugs. Setup is as follows: Multiplayer mission, 2 AJS37 Default arming Rb04 Remarmed to Rb15 BX8 given in mission, but the automatically generated BX6 and BX7 were really off Edited BX6 and BX7 manually (by LOLA taken from F10 view) as to have all points within 60 km from BX8. Setup Rb15 with 811110 and 841011 Fired Rb15 in ANF, VALB, SERIE well inside RMax The missiles flew to BX7, turned and then towards BX8. But at the instant when I think they were supposed to enable the radar and search, they turned north and missed. So, RTB, and loaded up with Rb04 No changes to CK37 (!!) Fired missiles at 130m weill inside RMax The missiles flew true to the target area and never went into terminal mode, so they overflew the ships and missed. Link to TACVIEW file for reference. https://www.dropbox.com/s/1yj815dvqryl04e/Tacview-20170523-215716-DCS-PlantingTheSEAD.zip.acmi?dl=0

Pre scriptum: this post is not aimed against Wraith. I just took what you said as a spring board. The first time I reported this was i a separate post in April 2014. I think 3 years is ample time. I don't understand why it's so common to want to defend the dev team. Either they have what it takes, and we salute them (they seem to "have it" wrt graphics), or they don't and we rightfully criticize them. Also this: It seems to me we are constantly asked to prove the exact bug. I.e, we're to unconditionally and exactly explain when the bug happens, and exactly when it doesn't happen. Well, surprise: this is not the best approach in development (yeah, I have credentials). Ideally, we should be encouraged to find bugs. The exact "when what how" etc are often most easily found by the dev looking into the code. The way this community works, we are asked to black box the bug, before it eventually gets fixed. Really really strange position as far as I'm concerned.

Well, several versions later, I have just come back here to say that the bug is ever present. Really really annoying. To clarify: nothing has changed at all.

I don't think this has ever been reported. And I don't know how old the problem is. This bug is reproducible. V 1.5.6.1938.247 Edit: Just tested in v2.0 Alpha and the bug exists there too. Added this mission to this post too. New Map Add 3 ground units ARMOR, any country and type. For one of these, add TRIGGERED ACTION: ACTION: Fire at point Stop Condition USER FLAG=100 (or any number) Now you have triggered the bug. If you click on "View Unit List", you can cycle between the two other (unchanged) units, but you can not cycle to the unit with a STOP CONDITION. The edited unit's behavior gets unpredictable. Some actions are possible, some aren't. I haven't looked exactly at what's possible or not. but it's not important since the behavior isn't expected anyway. So: Normal unit = OK Add Fire at point = OK Add Stop condition = Broken Attached mission you can click in to test. Fire at point bug.miz Fire at point bug v2.miz

Place the view.lua in Saved Games/DCS etc. That works. The only thing I have not been able to get working is the kneeboard postions. That file won't work from Saved Games/DCS and generates an IC error

p277

My TRK's in the AJS don't work. I don't know if it's the AJS or the 1.5.6 Beta (as I haven't tested other AC lately), but the playback is incorrect

Agreed. There should be a addition to the game (selectable in the settings) for a Radar Altitude Marker, which although not there in the real Viggen, could aid for us simmers. Please?

CONFIRMED: I have this exact same problem too

CONFIRMED this in several tests: Mission loaded with flight plan. CK37 loaded. REF shows 9024 The problem is that I'm at 18; it should show 9018. So I have to go to IN, type 9018 + LS, and same for landing site 9018 + L Once that's done, the runway alignment is correct, NAV SYST os off etc. Note that there seems to be a secondary problem too, or if I'm not understanding this part correctly: Sometimes I'm unable to set load landing site, so after setting 9018 + L, checking on AKT POS for L, the display blinks 9018/9028. But maybe it's something else the CK is trying to tell me :)

Actually I think this is correct or could be correct behavior. Before I go on, check in-game, you'll see rudder output is proportional to rudder input as long as SPAK is OFF. But with SPAK ON, while standing still, the rudder will deflect to maximum with even the slightest input. And this I think could be correct. SPAK is trying to make the A/C turn using the rudder, but is not succeeding, since there is no air moving over the control surface. So it progressively (quickly) adds more and more output to do its best. After a certain amount of time (quickly) it will be at maximum deflection. Ragnar Da, I have a theory that partly can explain the behavior during take-off. It goes something like this: When you start rolling, the nose wheel steering is in fact "OK". It's once you get above a critical speed that the aircraft gets erratic and starts swaying. I think that happens at/after the cross-over point when the rudder control surface starts getting really effective (around 100 km/h it seems). Once you get to that speed, the rudder input will generate a rotational output in the from (NWS) as well as a twisting motion in the rear (rudder). This would really make the AC unstable. Of course changing NWS sensitivity to radians etc will help, but the question is this: Shouldn't SPAK try to keep the AC aligned during runway operations using the rudder control surface? So in fact, once the rudder gets effective, if the pilot inputs a slight right rudder, thus turning NWS slightly right; shouldn't SPAK add a small amount of *left* output to keep the AC stable? This should be theoretically possible, since SPAK in fact (stated in SFI and manual) tries to keep the AC aligned during reversed landings (failing at this time). This bring me on to a question (I can report this as a bug if you want to): The manual and SFI state the AJ has a sort of ABS. So why do I get severe (up to) three wheel lock-ups all the time?

What I need now is a USB button to glue to the bottom of my chair ;)

I have seen this too