AvroLanc
-
Posts
1323 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by AvroLanc
-
-
Any ideas on when the very important CCRP Release Angle Scale is going to be implemented? Is it planned, very odd if it were not?
Please see shot I've grabbed off YouTube to avoid posting docs.
The elements are:
Range Scale
Range to Target Carrot
Maximum Release Range Tic
Predicted Climb Angle at Weapon Release
Level Release Range Tic
Predicted Altitude at Release (Hundreds of feet)
It would be great if this pretty basic addition was made to CCRP. Thanks.
-
4
-
-
So it looks like the M282 Multi-Purpose Penetrator have lost their (admittedly non-functional ) Penetration settings on the Weapons Page.
Before, they were defined as RC rockets and had settable PEN 'penetration' values. This always contradicted the manual, which says the M282 had a fixed/modified PD fuse.....so maybe it's now more correct? Although M282 is still 'RC' on WPN Page......Any experts out there with more info?
Will settable RC (Resistance Capacitance) fuzes make a appearance? I would have thought the 17-pounders with the M433 RC fuze / PEN values would be useful. (yeah, purely for immersion, until more advanced damage model).
-
Is the current INS drift model at all well modelled?
Last I heard the INS was drifting at insane rates in any pre-GPS mission.
If a proper probabilistic based INS drift simulation isn’t included, then it makes NO sense to bother with the FIX page. Other modules such as the M2000 and F-14 have properly researched and carefully implemented INS simulations. The ED Viper does not. Any simulation and/or gameplay immersion is totally bogus unless the underlying systems behave correctly.
-
2
-
-
I've just noticed that when you've got the VID page set to your HMD and with the VSEL (P-FLT or C-FLT) symbology selected, the selected NVS (Night Vision Sensor) uses the wrong, in fact the opposite, field of regard box symbology.
With PNVS as NVS the box is for TADS, and with TADS selected as NVS the box is the PNVS one. (This FOR box is the big box in the HAD with the Azimuth and Elevation tic marks etc.)
The FOR box that's projected on the IHADDS is correct, and changes accordingly when you use the collective NVS select switch. It's the VID page symbology that is wrong. Bug is seen in both PLT and CPG cockpits.
Edit: Screenshots of issue for clarity. Please enlarge and squint to view.....
-
27 minutes ago, Sarge55 said:
Anyway to set it back to GS?
No, the IHADSS airspeed is always TAS. You’ve got GS on the TSD and in the lower left waypoint datablock on the IHADSS itself. The velocity vector line gives a good idea of GS as well.
-
1
-
-
IHADDS now shows TAS, not GS.
Depending on the relative wind,TAS might increase slowly compared to GS.
-
17 minutes ago, Raptor9 said:
It shouldn't be absolute. It should be based on how many missiles are in the air at a time.
I haven't tested this myself in DCS recently, nor do I know if it was intentional or not.
OK thanks.
It's a bug then, doubt it was intentional.
-
The behavior of the 'LASE # TRGT' message has changed in the recent 8th June patch.
Before the patch the target number '#' always reset after each engagement i.e when all Hellfire's had reached TOF=0. For example, you'd get LASE 01 TRGT during a LOAL launch as prompt to lase, if you'd rapid fired and had 2 Hellfire in the air you'd get LASE 02 TRGT at the appropriate time, if 3 Hellfire in the air then LASE 03 TRGT etc....
After they'd all impacted, the message would reset to LASE 01 TRGT for the next set of launches.
New behavior in recent OB: The message never resets, so you get LASE 04 TRGT etc (up to LASE 16 TRGT) even if it's for the first launch in a later engagement sequence.
I'm 99% pretty sure it's a bug since I always thought the message was a reminder to tell you how many Hellfires are in the air and how many are needing imminent lasing ('lase 3 targets please', 'lase 2 targets please' etc). It could be correct though, in that it supposed to be the absolute targets you've engaged....Lase the 4th target, Lase the 9th target, Lase the 11th target' etc.....
Can an SME step in? It has changed, was it intentional?
-
28 minutes ago, Rongor said:
Update after today's OB 2.7.15.25026 patch:
-TSD wind display seems correct now, also matching windsocks, which are also showing actual wind direction as expected in real world.
-PERF wind vector is still opposite direction, 180° offset to TSD
-IHADDS is now displaying IAS on the ground, which may be correct.
PERF page wind was correct before wasn’t it? Is the TSD wind now correct?, if so then the bug has just been transferred to the PERF page.
IHADDS correctly shows TAS now rather than IAS or GS.
-
2 hours ago, BIGNEWY said:
Hi,
As mentioned, we are investigating for a later update. We are not saying that we will not do it.
We tested the upcoming GBU-24A/B for the Viper, and it can certainly destroy a hardened target like the command bunker with one hit. Further, we mentioned that the bump up will be coming for the update, it’s not currently available. Please wait for update and we look forward to your feedback then.thanks
The bump up isn’t even coming for the first iteration? Despite the fact that Wags mentioned (but tellingly, did not show) in his video?
Do everyone a favour and hold the PIII until it’s ready. It’s represents absolutely no addition to gameplay as it stands. We already have the GBU-31v3/4 for penetration. We are past static menus and non functional Paveway II clones. 25 years already, been there, done that in numerous sims.
Disappointed.
-
6 hours ago, Notso said:
Sorry, but you're way off with your "8 modes". It's a bit more nuanced than that.
This ^^
Yeah ok, it was a guess and a punt based on what I presumed to know at the time (very little). If you mix all my ‘modes’ together and add in a few bits and nuance then it wasn’t a bad go.
Thankfully the thread, and maybe my post, has stimulated some proper discussion that has led to a little more understanding that ED might go ahead and implement one day. So mission accomplished.You’re an SME are you not? Please feel free to fill in the gaps if you’re able. Thanks.
-
6 minutes ago, twistking said:
ok. thanks for the explanation. it makes a lot of sense if you think pre-gps...
that means the workflow would be to have OA1 and OA2 pre-assigned in mission planning (or with the ded, since mission planning is not yet available in dcs) and then slew the sensor to the terrain feature of which you had the coordinates pre-defined. maybe the implementation is not even wrong; maybe it was just matt wagner's video misrepresenting the use-case.
will have to test again, with predefined OA...I’ve tested it, yeah….it’s not correct.
Nineline, I’ll dig out the references tomorrow. I suspect they’re the same public ones you’ve already got though.
-
1
-
-
Just now, twistking said:
what benefit would it have though to have the tgp look at a different point? in the end you still have to trust that mission data is correct, so you could just release on the waypoint with sensors being obscured. could you explain the practical benefit of using an offet aimpoint?
is there a bug report on this already. if you're right that seems to be pretty big oversight by ED and should be corrected...
It's not really for the TGP, although it could be used that way.
It's a left over from the days before GPS. In those days the INS would drift a small amount, the waypoint would then not be over the correct point in the real world. You could use the radar to slew to the correct target, and possibly get a FTT. No problem....but what if the target doesn't show up so well on the radar? Maybe it's a collection of soft tents or another radar insignificant target? You can't see it on radar in that case. But, there's a distinctive looking bridge or building at a known bearing and distance offset from your intended target. This radar offset is exactly what OA1 and 2 are for. You can slew the radar cursors to the bridge, the radar looks at the bridge, but the aiming and waypoint are at all times directing you to the true target. This is what offsets are for.
Similar for TGP I guess, but it's much easier for the TGP to see the true target, so you'd not use the offset in most cases. Maybe if the target had a laser warning receiver and you want to avoid alerting or was very hard to find even on TGP.
-
1
-
-
Offsets have been implemented completely wrong anyway.
They're not supposed to be merely additional waypoints (you'd just use an another waypoint, if that were the case), they're supposed to act as a true offset - i.e aiming offset from the target waypoint in situations where aiming directly at the waypoint/target isn't possible. All steering and weapon aiming should at all times be towards the Waypoint, with OA1/2 being where the sensor looks, but with the entered offset data defining the Waypoint (.....the target.....) position. ED haven't really understood how this is supposed to work.
-
It's locked out above 80 knots right? Check speed.
-
1
-
-
3 hours ago, Dragon1-1 said:
Assuming the logical way is dangerous, because it might just be one of those systems at which real pilots and chiefs look and think "who designed this crock?" I hope ED will be able to find out enough information to model it properly.
Well, if those real pilots and crew chiefs want to offer their opinion then they’re free to help out any time. The problem is they don’t/can’t. It doesn’t really matter if it’s ‘dangerous’ or embarrassing later on, if they weren’t willing or unable to contribute towards a more realistic 100% correct solution right now then……who cares. The real info may never come in these specific cases.
Getting a few sensible and knowledgeable heads together to construct a reasonable solution is that best we can hope for in these cases. It either this or make do with a equally incorrect Paveway II copy that adds absolutely nothing to current gameplay or simulation. I say again……I’m 100% done with static menus and non functional inactive menu options. I want depth and functionality above and beyond the same old combat sims I’ve been playing for 25 years.Futhermore, if that depth and true consequential gameplay can’t be provided through lack of documentation for the chosen module, then by heck choose to model a more appropriate airplane in the first place.
-
2
-
-
10 hours ago, twistking said:
Hello,
can someone enlighten me on the logic behind the new GBU and it's FCS integration?! First of all, has the bomb data-connection to the aircraft, or is it just a "dumb" connection like on the other LGBs? I assume it has no data, since it can be carried on the inner stations. If it has no data connection, how does the bomb determine if it should do the loft-maneuvre, since it cannot get the distance to target from the laser track.
Also i do not really understand the logic behind the settings for range cue and dive angle. Why would you need to change these if the weapon would not receice these information anyway?
Can someone explain why these settings exist? Also would you lase the target directly after seperation? (As we know on the simpelr LGBs this is not recommended because it can lead to the bomb overcorrecting and loosing energy in the earlier stage of flight...)
Thanks.There are clearly lots of Paveway III details that ED simply doesn't have access to, which is a massive shame since they did once indicate that a new autopilot would be coming for PIII. Even Wag's video wasn't clear...is there a new flightpath model/autopilot implemented for PIII or is it just the same as Paveway II?? It's clear as mud at this point.
The Range Cue and Release angle settings do have some logic. The way I understand it, Paveway III is a very 'canned' weapon i.e. it's limited to fly in a very specific 'pre-planned' flightpath. It's very pre-planning intensive and the delivery has to be spot on in terms of Airspeed/Dive/Altitude to hit those pre-planned parameters. This is because the weapon has fixed non-flexible fuzing and when you use PIII you want the impact angle and fuzing etc to be planned spot on for the type (hardened!) of target you're going after. This is not a TOO CAS weapon. Therefore the Range Cue and Release angle setting's are there to pre-set a condition to release, they don't influence the actual bomb at all, they just make sure you're flying the pre-planned delivery.
Having said that, the gliding flightpath can be 'shaped' to achieve what you want by making a setting on the 'MODE' switch. On Paveway III, this is a physical switch on the bomb itself. Just like a PII's laser code. The 'MODE' setting knob has positions 1-8. I imagine these are the 8 gliding profiles or trajectory shaping modes. This detail is what ED lacks. But I say, let's make em' up.....
MODE 1. Standard medium/high alt level delivery that priorities range over terminal shape.
MODE 2. Medium alt drop that produces glide path the flattens in terminal stage for vertical targets (you want to hit side of a tower)
MODE 3. Medium alt drop that produces glide path that steepens terminal stage for horizontal targets (hit top of the target)
MODE 4 and 5. Low altitude drops that optimised for <5000ft deliveries for same vert or horiaontal as MODE 2 and 3.
MODE 6. Low altitude LOFT flight path to acheive max range in LOFT delivery for vertical impact angle
MODE 7. Same as 6, but for different terminal stage
etc etc Paveway III needs constant lasing in order to continually know it's relative position to the target. It also has a barometric altimeter, for rate of change of height.
Now, I've made the mode details up, but the 8 position MODE knob is real and I'm willing to bet I'm not too wrong...... I don't see why ED can't bow to a gameplay perspective here. Inactive and non-functinonal MFD buttons and labels should have no place in DCS in 2022. We're not in 1998 anymore and I expect more.
-
4
-
1
-
-
35 minutes ago, admiki said:
You don't have to be in range if you select map range that is more than threat range, but if you are at small map scale, yes, you are correct.
Yeah, that's how it is at the moment. Pretty sure it's a BUG. The Hornet's rings behaved that way until corrected. Hard to believe it should work that way.
-
53 minutes ago, f1rst said:
Could FCR be rotated to the left\right side, or it's fixed in front position?
Depends on the mode. In the most widely used GTM mode the scan is a 90 degree sector straight ahead (45 either side of centreline). The scan size can be narrowed and moved left and right within those limits. In ATM ('air to air') mode it's a 360 degree scan with a blanked off bit towards the tail.
-
1
-
-
11 minutes ago, lt_d4n said:
yes, I have selected for threats/targets to appear, but I don't see the rings...
let’s see if someone can put a screenshot with the rings.
thks
Can't grab a screenshot now but they are definitely in.
Make sure SHOW>COORD 'Threats/Targets' selected.
Make sure SHOW>THREATS 'Threats' selected.
-
You need to make sure that you go to the SHOW>COORD subpage and select 'Threats/Targets'. The rings then appear. Note that this is pre-selected in the ATTACK phase.
Note that this a different page than the SHOW>THREATS page, but it's a prerequisite of the threats being displayed on the TSD. Not entirely sure if that's 100% correct, but there is sound logic to it.
-
With the latest (18th May) patch there's an error when making a TADs target store, and presumably a HMD store too.. The Target store identifier doesn't correctly show in the 'weapon inhibit field' (top of the TADS or HMD High action display)....it shows T01, T02 initially but then seems to rotate back to showing T02 or T03 constantly with every additional store.
In addition the Target Store idents in the COORD page seem to increment by 2 each time....so T02, T04, T06 etc. These idents increment even though the 'weapon inhibit field' status shows T03 every time.
This is probably related to the addition of the pre-planned threat rings feature. But it's messed up the target store procedure. Although the actual locations are correct and can still be slaved to, it's major source of confusion.
In my track I removed all pre-planned SAM threats in the ME and I still get the bug. You get the bug with ME SAM threats as well though.
-
In previous OB versions the JDAM time of flight / time till impact timer worked by showing TTI in the TGP MFD, similar to LGBs. This no longer shows anything. It always shows 000.00 after dropping weapon.
There was also a ZULU TOT (Time on Target) shown on the HUD when the range carrot was within the dynamic range bracket. This HUD time would show initially the zulu time when you'd reach the top of range bracket and then zulu time at impact when the aircraft current range was within the range bracket.
In the last open beta this is a bit broken. The initial time prediction for top of range bracket is still shown, but the impact TOT and the TTI timer on the TGP page now show 000.00 when you get to within the dynamic LAR bracket.
Please see short attached track.
(Just a guess....but maybe the ongoing WIP regarding ICP CRUS mode time predictions is introducing a few bugs?)
-
There is a bug here though.
The A/C should show FLT page when in flight and ENG when on ground. It’s even described that way in ED’s EA guide, also in RL docs.-
1
-
Slaving TGP to SPI of Wingman
in DCS: F-16C Viper
Posted
There are two things here. You can transmit a SPI and you can transmit a Steerpoint.
AI can only transmit a SPI. Human players can transmit a Steerpoint and/or a SPI. Hopefully AI will get the ability to create and send mark points/Steer-points in the future.
You can slave to a Steerpoint and it’s described in a post above. There’s no way to currently automatically slave to a SPI.
You should be able to use FCR AG map mode and slew cursors and have the HSD cursor follow those slews, you could then overlay the HSD cursor on top on the AI transmited SPI and create a FCR marpoint. Although, this might be buggy in DCS as the radar map cursor has wrong update behaviour. Although actually I need to try, now that I’ve thought of it.