Quip
-
Posts
245 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Quip
-
-
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:
Grouped targets is selected by setting the targeting mode selector to GRUPP. In this mode, thecontacts must be within 2700 metres of each other in depth. Otherwise the missile may miss
the targets entirely. If the missile detects a grouped target, it will select one of the contacts at
random, leading to multiple missiles selecting different targets.
-
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,
-
1
-
-
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
-
Honestly, its going to take time for a small developer group like ED its not EAGAMES also the complexity of the sim and knowledge of those working on stuff would vary.
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.
-
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
Weapon selectorThe weapon types are selected via the weapons selector dial. Rather than selecting a weapon
pylon, it selects a weapon type. The knob has six positions.
Each position may select multiple types, but due to possible weapon configurations will not
clash. For the example position 2 has RB75/ MARK / DYK. Which would either select the RB
75 missile, the RB 05 in A/G mode or set the bombs aiming for dive bombing.
In case of an incorrect selection of weapon type, the HUD presentation will be turned off either
when selecting ANF on the master mode selector or opening the safety bracket.
-
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?
-
Right, but up is up on the radar scope and up is down on the Maverick sight. If I invert it so that the Maverick sight is correct, the radar scope is wrong.
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 :)
-
I stand by my observations about the rudder too. The nose wheel moves proportionally to the rudder pedal input, the rudder does not. :joystick:
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
No TILS on reverse runway?
in DCS: AJS37 Viggen
Posted
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.