RAZBAM_ELMO
-
Posts
2093 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Events
Posts posted by RAZBAM_ELMO
-
-
- Popular Post
- Popular Post
Dear Customers:
Today we want to talk about our decision of removing the AGM-65F from the weapons roster for the DCS Night Attack AV-8B Harrier II.
Through the development of the AV-8B N/A we gained access to more current information thanks to the invaluable help of our current active status SMEs, this translates into a constant upgrade of the module, new weapons integration and actual employment, updated sensors, and capabilities, that the original product didn’t have, mainly because it was modeled around an early 2000’s iteration of the AV-8B N/A. All this new flow of new information and data indicated that the AGM-65F, while available to the Harriers in the 2000s, was not in service in the USMC and not integrated in the mid 2010s update the Harriers received. This motivated the decision to remove it from the aircraft to better represent the capabilities of a mid 2010s aircraft, which is what our AV-8B N/A module is based on currently.
But this decision, based on the facts stated before, overlooked the fact that some of our customers liked the idea or are fond of using said missile. For a number of factors and reasons, this time reality took over the personal choice of this product's customers. It’s easy to get distracted in the constant search for accuracy vs the reality of the fun factor and user’s choice of having such fun when using our product. This is a choice you, as the customer, should have to some extent, while the real and hard trained individual that uses this aircraft doesn’t. But in the end, this is a simulator, and above anything else, it’s main purpose is to provide fun to the user, without sacrificing too much realism in the process.
Having said that, it has been decided to keep the weapon to better represent early 2000s AV-8B N/A capabilities to give the freedom to the player to fly realistic mid 2010s loadouts or not. It has been decided to give the user that option, for his/her satisfaction while using the DCS AV-8B Night Attack module. We will keep the AGM-65F and improve it to add the bore-sighting procedure, just like in ED’s F-16. We will also improve the AGM-65E implementation and add the AGM-65E2.
The AGM-65E will have its implementation improved with the addition of limitations linked to the TPOD integration. The TPOD video can’t be displayed at the same time as the Maverick video, this is true for the AGM-65F and the AGM-65E. Since when the TPOD is not displayed, the HOTAS controls reverts to its default settings and the AGM-65 is a lock-on before launch (LOBL) type of weapon, the missile can’t be guided by the launching aircraft. The AGM-65E2 goes around this limitation because it can be uncaged and launched from the TPOD page, or the TPOD video can be switched to the MAV video momentarily. We will also implement a particularity of the E2 that it can lock on the TPOD laser source if the laser is fired before the missile is uncaged and the TPOD is loaded on station 4.
Maverick missile employment will be updated to reflect the real workload of the pilot when using the weapons thanks to the information and SMEs we have access to.
In parallel to the maverick improvements, we are working on fixing bugs and adding the last features to the Harrier. We will list some of them :
-
IFF configuration menus and allow them to be used by SRS.
-
Ability to make overlays from the data page for the moving map.
-
We will contact the Combat flight team to see how we can integrate the Harrier with this software.
-
Loft bombing profile.
-
Update to all training missions and addition of new ones.
While Baltic Dragon works on the full manual for the Harrier, here is an extract that contains the ground ops section. Keep in mind this is work in progress, it may contain errors and is subject to change. We would love to hear your input and feedback on the revised manual to help us create a better user experience in the future.
Harrier Manual Ground Ops extract.pdf
We hope this will clear-up our intentions regarding the AV-8B N/A, and show that we are committed to the DCS community as a whole. Thanks for your passion and support.
The RAZBAM team
-
48
-
23
-
DCS M-2000C by RAZBAM Simulations
Fixed: HUD Waypoint course error ("house") jumps
Fixed: AP star HUD symbol
Fixed: VTB WP display in CADR AR mode
Fixed: Radar Altimeter minimum altitude switch range
Fixed: Green Radio 1 digit channel keyboard entry
Fixed: Emergency compass behavior
Fixed: Brightness curve for cockpit lights
Fixed: VTB WP off screen visibility
Fixed: AP oscillations at low speed
Fixed: engine in-flight restart after inverted flight
Fixed: INS Alignment must be done on a waypoint >=1
Fixed: VTB Bullseye Selector going too fast
Fixed: minimum HUD brightness and added a brightness curve for easier adjustment
Fixed: feeder tank ribbon levels
Fixed: UHF Main Mode knob rotation
Fixed: External tanks not refueling on ground
Fixed: PCA issue when switching BL and AG Radar modes back and forth
Fixed: Issues with PPA/PCA binds
Fixed: alignment status timings
Fixed: InFlight realign.
Fixed: double keypress on PCN with binds
Fixed: IDN and PCN symbols flickering
Fixed: CCRP-IP release cue
Fixed: bug causing HUD WP reticle at correct place with wrong INS alignment
Fixed: Waypoints position displayed on VTB is not affected by the INS drift
Fixed: VTB Waypoints can't be added if outside radar azimuth cone
Fixed: Bug causing VTB Waypoint system stuck when 5 waypoints are added
Fixed: Adding more than 5 waypoints to VTB does not remove the oldest one
Fixed: Can only add 4 waypoints to VTB instead of 5
Fixed: VTB WP persistence across flights
Fixed: Police light ON/OFF switch
Fixed: IFF set OFF on Air Start but still operates as if on
Fixed: Radar elevation bug - slow elevation increase
Fixed: CCRP turn cues
Fixed: Radar range switch limited to 80nm
Fixed: PCN ΔLatΔLon distance 1000 factor
Fixed: Wrong ΔAlt input in PCN
Fixed: green radio ch knob not turning when radio off (cosmetic)
Fixed: Wrong TWS Closing Velocity
Fixed: TACAN Bug
Fixed: FPM stutters in wake turbulences.
Added: INS switch on to Autostart sequence
Added: Added RD (desired route) to HUD
Added: Refuel log in kneeboard
Added: REC can be used on the ground
Added: brightness knob on PCN including test position
Added: Palette SNA (Magic Slave / INS Update) hides the ILS cue and synth runway
Added: Automatically sets CP and PD on a landing waypoint
Added: Desired glide indicator on the HUD in APP mode
Added: Manual Fuel Detotalizer (can be disabled in special options)
Added: Refuel quantity message at the end of refuel for manual detot update
Added: Automatic waypoint conversion to BAD offset if wp name contains #CONVERT_TO_BAD
Added: INS wind estimate CCRP correction.
Added: Trailing needles to GMeter (with reset).
Improved: INS accelerometer and gyro failures
Improved: INS power supply
Improved: Aux ADI pitch mouse wheel speed
Improved: PCN display
Improved: Pitch ladder & horizon uses drifted INS in instead of perfect angles;
Improved: ILS line. Added CP axis ILS line to HUD instead of the previous localizer dashed line.
Improved: AP APP HOLD mode to follow the ILS cue
Improved: Synthetic Runway created from ILS data and CP/PD info instead of mission editor
Improved: HUD ILS cues
Improved: Bingo fuel logic
Improved: All 20 waypoints enabled by default
Improved: CCRP bombing accuracy
Improved: HUD Heading tapes shows backup gyro if INS is off, and magnetic heading if both are off.
Improved: heading/pitch/roll functions.
Improved: HSI and ADI movements
Improved: INS drift with a more realistic model
Improved: Windspeed calculation based on INS speed and FM sensors
Improved: ALCM (fast alignment).
Improved: Caution lights knob “click” and profile.
Fixed and Improved: Time to Destination mode
Replaced "INS does dot need realign" option by "Fast Alignment (ALCM) enabled"
Adjusted Formation lights.
All campaigns have been updated for 2.7 features, including the clouds
Stock campaign (South Ossetia) updates:
- Added SPACE BAR option and instructions for radio checks in all missions.
- Fixed "gear up" call at mission start for M07.- Updated M13: JTAC will now lase target correctly; removed the need to use DCS JTAC radio men.
The next update will see some big changes for our Mirage. In the last few months we mainly worked on the INS system, the PCN panel, the VTH (HUD), the autopilot and the fuel system and panel.
Fuel system and panel
In this update the fuel system has been updated to allow a more realistic behavior on the fuel panel. The changes that you will be seeing are to the DETOT mechanical display and the feeding tanks level display.
The DETOT mechanical display is now linked to the engine fuel flow meter and is not representing the real fuel level of the plane anymore. Its accuracy is dependent on it being set to the correct value when refueling. When spawning, the DETOT will be set to the correct value, but when refueling on the ground or in the air you will have to adjust it manually. There is a checkbox in the M-2000C special option menu to set the DETOT to automatic, reverting to the previous behavior. In order to help with the DETOT management, the kneeboard will contain the aircraft fuel quantity when starting or refueling on the ground and will provide the transferred fuel quantity when air refueling (you will have to do a bit of math here :)).
The feeding tanks level display will now follow the correct transfer logic, starting at 600Kg each and then dropping to 450kg when the external tanks are empty.
INS and PCN
The biggest change in this update will be the INS and PCN overhaul, both systems have been mostly rewritten.
The INS now simulates the accelerometers and gyroscopes with noise and mechanical imperfections to create a realistic result that feeds information to the rest of the aircraft. This means that the drift rate is now non linear and won’t be the same each flight. The drift rate is now increasing with time as the gyros and accelerometers error gets bigger. With the full alignment, the drift starts at around 0.7nm/h, but after 1h of flight the aircraft will have drifted around 1nm.
The alignment process has also been overhauled to recreate the real one. It starts by finding the true north using the earth rotation, then it starts to vertically align the gyros. The longer the alignment process, the more precisely the gyros are aligned and the less drift they generate. The alignment precision is linear, stopping the process at the end of class 4 is better than stopping it at the start.
The PCN has been optimized and the way the information is displayed and entered is closer to reality. Inputs now don’t require all available fields to be filled. For example the altitude can now be inserted as [1] [5] [0] [INS] rather than [0] [0] [1] [5] [0] [INS] for 150ft. The coordinates input has also been changed to match the real PCN, the PCN will only display degrees, minutes and tenth of a minute while the system will take hundredth and thousandth of a minute.
The CP/PD parameters are now generated correctly from the editor if the waypoint is set to landing.
The brightness and test rotator is also now working.
The last big change on the PCN is with the BUT (waypoint) 00. Selecting BUT 00 in PREP mode displays the current aircraft’s coordinates, altitude and true heading but this BUT is read only and cannot be edited on the ground or in flight. This means that now in order to start the alignment process you have to select a BUT with your current coordinates and altitude set. The simplest solution for now is to use the BUT 20.
The “INS is always aligned” checkbox in the special option menu of the mirage have been replaced by a “Fast alignment (ALCM) ready” checkbox. With it checked, you will now need to do at minimum an ALCM before moving the aircraft for your INS to work and you can start the ALN or ALCM on the BUT 00 as the aircraft did not move since the last time it was stopped.
VTH
The VTH is still going through with the overhaul that will convert all the symbology to vectors that will improve the way it’s displayed and allow easier changes in the future.
The landing symbology has been updated with the addition of the Pente Désirée (desired slope) symbology that is taken from the PD parameter on the current DEST BUT. The PD is hidden when the ILS director is present on the VTH.
The ILS director (box on the VTH) has been updated and is now working as a real director, all you need to do is put the FPM inside the box and it will guide you on the ILS glide and localizer.
The synthetic runway has also been overhauled and can now be set from the plane. For it you need to set a BUT on the airport and configure the CP/PD parameters to the ones of the runway you want to land on. CP, Cap Piste (runway heading) being the runway heading in true north and PD being the ILS slope. Then you need to set this BUT as DEST, tune to the correct ILS frequency, set the correct QFE, be less than 10nm from the airport and the synthetic runway will display on the VTH. Be careful as a one degree error in the CP parameter will completely offset the projection.
The runway heading line is now working correctly and is using the CP parameter.
The “Magic Slave/AG Designate/INS Position Update” binding, also known as Palette SNA (navigation and weapon system paddle) will toggle the display of the ILS director and synthetic runway on the VTH.
The CCPL (CCRP) and CCPL+PI (INS bombing) have also been updated to be more realistic as well as taking wind into account. The wind correction will not be perfect as the plane only knows how the wind is at its altitude and position. The accuracy is still not perfect and will require more work.
The Route Désirée (desired track) has been implemented according to real documentation, it’s using the RD parameter in true north from the current DEST BUT.
Autopilot
The autopilot gains and laws in pich have been updated, fixing the oscillations at low speed and high AoA. It also resulted in a smoother attitude change when commanding pitch change with the trim hat or using the ALT AFF auto pilot.
The approach autopilot has also been updated and will follow the updated ILS symbology allowing the plane to do automatic approach in all conditions (don’t try to land with it !).
As this update is changing a lot, be sure to disable all your mods before updating and to activate them only when they are updated by their maker to avoid any problem.
These are the main changes that we have done to the Mirage for the next update, as you will see in the changelog there are also a lot of other smaller improvements and fixes. We hope your pilots like it.
-
35
-
12
-
-
DCS AV-8B N/A by RAZBAM Simulations
Fixed: Negative clock values when local time reaches 00H00:00
Fixed: CAS Long/Lat Input
Fixed: CAS UTM input
Fixed: TACAN line course deviation
Fixed: TACAN modes not working correctly
Fixed: DMT VV slave following ghost vector
Fixed: UFC input errors after entering TACAN or waypoint values.
Fixed: TPOD reverts to wide view when selecting FLIR
Fixed: AAR Zone 3 not appearing on EHSD
Fixed: TPOD Compass Arrow not pointing North from the POI viewpoint.
Fixed: DECM annunciator lights remaining ON when pod is OFF.
Fixed: UFC/ODU display not responding to brightness control.
Fixed: GBU-12/16 ODU Fuze options not working.
Fixed: CRS Switch not centering when using keyboard/joystick
Added: AUTO Point Blank designation.
Added: Special Option: Action/No Action TDC behavior.
Added: FLIR Hot Spot detector on HUD
Improved: MPCD FLIR page to incorporate Hot Spot Detector cues.
Improved: Hydra rockets firing logic for single and ripple fire.
Improved: USS Tarawa Textures
Improved: KC-130 Lights
Improved: Exterior lights w/ LODs
Improved: VREST page logic
Improved: TPOD G4 functionality
a. NWS functionality
b. Snowplow mode enabled (requires Action/No Action TDC enabled).
c. SLV VV (slaved to VV) mode enabled
d. 2D Yardstick circle enabled
Improved FM
a. Corrected insufficient drag at negative angles of attack.
b. Corrected incorrect thrust being generated when engine is windmilling but no combustion.
c. Improved negative angle of attack dynamics.
Missions: "Ottoman Courier" campaign updated for 2.7 features, including the clouds.
Missions: Added completely new Tote Board to all missions.
Missions: Fixed invalid loads on some Fast Action missions.- Fixed: SAI cage/uncage lever animation. To cage the SAI it must be pulled and rotated.
To cage: Pull the lever and then rotate the knob.
To uncage: Rotate the knob. The lever spring will bring it down.
- Added: AUTO Point Blank designation.
To enable:
A bomb type must be selected.
Release mode must be AUTO.
EHSD DESG must be unboxed.
There cannot be a designated target.
Use the VVM as a crosshair.
The Aircraft must be in a dive at least 5 degrees pitch down
Press the pickle.
The spot under the VVM will be designated and the AUTO ASL and release cue will appear.
The designated target will be saved as T0 and the EHSD will navigate towards it.
Keep the pickle pressed until bomb is released.
Target designation is saved.
- Added: Special Option: Action/No Action TDC behavior.
Check the option in Special Options to enable TPOD special features.
- Added: FLIR Hot Spot detector on HUD
FLIR MPCD page allows the pilot to limit the number of chevrons that appear in the HUD: 0, 4 or 8.
- Added: JTAC 9 line CAS brief reception. The brief can be reviewed in the MPCD CAS page.
Just call the JTAC. ATHS will receive the brief as soon as the JTAC finishes his transmission.
A MSG cue will flash in the HUD warning you that it has received a CAS brief
- Improved: UFC WOF mode fucntion.
Press WOF when overflying a waypoint.
1. It will show waypoint altitude. ODU will show ACPT/REJT options to accept or reject the value. If not option is selected in 15 seconds, the value is automatically selected.
2. Next it will show the bearing and distance to the waypoint at the moment the WOF button was pressed. ODU will show ACPT/REJT optrions. If not option selected in 15 seconds the values are automatically accepted and aircraft present position will be updated
3. Waypoint Offset, if it exists, will be designated as target. If there is no waypoint offset, the waypoint becomes the designated target.
- Improved: TPOD G4 functionality
a. NWS functionality: When the TPOD is the SOI it changes modes
MAP DES/TRK DES to MAP DES/SLV DES
TPOD DES/TPOD DES to HUD DES/SLV DES to NO DES/SLV VV to SNWPLW
HUD DES/TRK DES to HUD DES/SLV DES to NO DES/SLV VV to SNWPLW
LSS to HUD DES/SLV DES to NO DES/SLV VV to SNWPLW
LST to HUD DES/SLV DES to NO DES/SLV VV to SNWPLW
NO DES/SLV VV to SNWPLW and viceversa.
Designating Sensor
MAP DES: EHSD (MAP) is the selected sensor for System Designation (DESG Button)
TPO DES: TPOD is the selected sensor for System Designation
HUD DES: INS or DMT is the selected sensor for System Designation
LSS: TPOD is in Laser Spot Search mode
LST: TPOD is in Laser Spot Tracking mode
NO DES: No sensor has been selected. (HUD VVM is the aiming point)
Operational Modes
TRK DES: TPOD is in either AR, PT or MT modes with a designated target
TPOD DES: TDC Button has been pressed (Target designation) with the TPOD as the selected sensor
SLV DES: System Designation exists. TPOD sensor is slaved to the designated location.
b. Snowplow mode enabled (requires Action/No Action TDC enabled).
Default mode when the TPOD starts.
In this mode, using No Action TDC (slewing the TDC without pressing down) will move the camera but will not command a lock.
The camera remains looking at the selected angle.
To leave the mode press NWS to enter SLV VV or press down the TDC to command a spot lock.
c. SLV VV (slaved to VV) mode enabled.
In this mode the TDC slew commands are disabled.
The TPOD sensor head behaves like the ARBS/DMT and is slaved to the aircraft VVM.
Use the VVM to aim the TPOD and press TDC down to command a lock
To leave the mode either press NWS to enter Snowplow mode or TDC down to command a lock
d. 2D Yardstick circle enabled
The TPOD must be locked to a spot or vehicle.
Click on the DATA button
The ODU/UFC will enter into TOPT mode (TPOD OPTIONS)
Select 2DY (The other options are functional but do not have any visible action).
UFC scratchpad will show the default 2DY radius: 100 meters
M will toggle between meters and feet (default is meters).
INC will increase 100 meters or feet.
DEC will increase 100 meters or feet.
Valid values are between 1 and 4993 meters (3 to 16617 feet)
Press ON/OFF to make the circle appear
The circle will move with the TDC.
The circle will not be shown when the camera is pointing above the calculated horizon.
-
17
-
11
-
-
RAZBAM SIMULATIONS Q2 UPDATE
Hello everyone, we at RAZBAM hopes that this finds you all in good health and spirits as we round the next corner in this global pandemic. It has been a hot minute since the last update and all parties everywhere have been hard at work churning out work for you all to enjoy. We will start with our released modules and then work into the WIP of our announced projects leading into Q2. First, I would like to apologize for my absence the last two weeks as I have been in the middle of a posting move. Mid way through April I will be absent again as I will be “traveling” for “work”. Thus, I would like to introduce to you our Assistant Community Manger myHelljumper. myHelljumper has done an excellent job in reporting new and existing bugs in the Mirage forums and will be assisting me in tracking/ reporting bugs for all our existing and future modules.
AV8BNA Harrier
A lot of new features are coming along for our beloved VTOL platform along with various fixes and improvements. Of note some of the additions are:
- Auto Point-Blank Designation
- FLIR Hotspot Detector
- G4 Pod features like the 2D Yardstick circle, snowplow and TDC action/ no action. These last two are only able to be used by selecting the option in the special tab. If you do not select this option the specials tab, the TDC will perform as it always has but you will not be able to use these new features.
- NWS functions which depending on your mode can cycle between MAP DES, TRK DES, SLV DES, HUD DES, TPOD DES and SNWPLW.
- WOF UFC Function
- JTAC CAS MPCD CAS page reception allowing you to receive 9-line briefs directly to the Cas page rather than entering them in manually.
A more detailed list and instructions will follow and be present in the Harrier sub-forums.
Mirage 2000-C
With our new full-time coder working diligently with our partners in the AdA, I will let him explain the new features he has been implementing.
The next update will see some big changes for our Mirage. In the last few months, we mainly worked on the INS system, the PCN panel, the VTH (HUD), the autopilot and the fuel system and panel. These improvements and their full descriptions can be found in the Mirage sub-forum. These improvements include:
- Fuel System and Panel
- VTH
- INS and PCN
- Autopilot
As this update is changing a lot, be sure to disable all your mods before updating and to activate them only when they are updated by their maker to avoid any problem.
These are the main changes that we have done to the Mirage for the next update, as you will see in the changelog there are also a lot of other smaller improvements and fixes. We hope your pilots like it.
MiG-19 Farmer
Yes, the beloved -19 is getting some more work done, while not as extensive a lot is adjusting the missing or non-functioning key binds. This work is being done by a new support coder. This simple work will help them get up to speed on the SDK and working within DCS code so that we have better support in the long term with existing and future modules.
F-15E Strike Eagle
Work has partially resumed on the code side of the Mudhen, but the 3D work is in its final stages with our 3D artist making sure every square inch is looked over for inaccuracies and flaws.
MiG-23 MLA Flogger
With the external 3D model complete, the cockpit is the next on the list with our 3D scans of a real -23 being used as the basis. Work remains on track for our internal timelines.
MBB Bo-105
With 2021 looking to be the year of the helicopter, our work on the BO-105 continues to drive forward. Systems complete or near completion include:
- Electrical system
- Engine cold start
- UHF, VHF-FM, VHF-AM, and intercom
- Hydraulics system
- RWR
While functional some aspects still need work such as the flight model, optical sight system and doppler navigation system. Items still requiring major work include the weapons system, automatic yaw control IFF and of course multicrew. We do not have a release date to hand out publicly yet but you know, its soon.
Secret Module
In darkest days, in blackest nights…… ha, and you guys thought I’d give you a Little hint. You’re funny.
-
28
-
10
-
-
Alright so I didn't even know this was a thing but this is working AS INTENDED. You must PRESS the button on the end of the shaft to unlock it prior to moving the handle. Marking AS INTENDED and moving to RESOLVED.
-
syc, but seriously I'm working on the Q1 update this week gents. I've been busy with a household move and doing my best to set some time aside to prioritizing my CM duties ATM with work and life being a bigger priority at the moment. Standby
-
7
-
3
-
-
Topic will be closed for now. Selection for the RaDG Programme has begun and no further applications will be taken. Candidates who have provided and submitted all the necessary material and who meet or exceed the requirements will be contacted within the next week so keep an eye on your emails. If you do not receive an email by 26 MAR 2021, then you were unfortunately not selected so do not bother sending an email asking if you were or were not because it will be ignored.
-
1
-
-
it is working for me. Upload a trk file please.
-
are you binding them to a controller button box or via the in game key bind or are you using the mouse and clicking them. Im understanding then that you are not having PT issues anymore?
-
known and duplicate report. Marking as such and moving to resolved.
-
Tracking the issue, FM noticed this and is waiting to hear from ED if theres a correct weight calculation when moving forward. What are you loaded with?
-
1
-
-
Markin AS INTENDED, this was to fix the lurching motion when the chocks were removed and is not related in any way to ground idle thrust. Marking AS INTENDED and moving to RESOLVED.
-
1
-
-
Known and we got the fix from ED and has been fixed internally. Marking as such but leaving here till i see it in CB to confirm
-
@DeadMeathave you experimented or played with swapping the stuck trim had and the stock castle to make the stick more closely resemble the Harrier?
-
22 hours ago, tech_op2000 said:
is the estimated position error always shown now? Anything I can do to reduce the estimated error?
yes
11 hours ago, Wisky said:yes, use the gbu54 and your laser for final
this
Also, we do have JDAM warm up/ alignment in but it is transparent to the player. According to the SME, once power is provided to the jet and the aircrafts alignment begins, the JDAMs also get power and begin their alignment simultaneously. When the aircraft is aligned, so are the JDAMS.
As this is implemented and working this will be marked AS INTENDED and moved to RESOLVED.
-
Im not getting the TPOD to go off in AR track, if I mask and am in PT or MT then it does slew off of where I had it tracked. Im also not having my T0 shifted when the gimbal rolls over. So I'm gonna need a trk to better deduce what you're doing because head-shakiness from the VR is hard to tell whats going on.
-
Tracking, reported.
-
1
-
-
EHPE = Estimated Horizontal Position Error
EVPE = Estimated Vertical Position Error
Pickle must be held for the information to be transferred to the JDAM and then confirm pickle with the release cue. This is intended. The actual alignment I'd have to check and see if its done through the jet as soon as the aircraft is aligned or if it has to wait for no WoW. Ill check with the SME on that.
-
On 1/25/2021 at 3:45 AM, jwbflyer said:
Just repeated the issue. My TDC slew function for DMT works a bit more in horizontal, rather than vertical axis. Seems ..”grabby” like it will move and stop and wont move. I will try to reassign the control to the non-axis function “forward, aft, left, right”. I’ll add a track file later today if the problem persists after changes in assignment.
Have you got anything to work yet or are you still experiencing the smae issues?
-
6 hours ago, Fri13 said:
There is no ISO standard if you so try to go talk about it. But there is a de-factor standard that is based to how to do properly the documentation, reporting and even management.
Yes, every business can do how ever they want, but if they go and do it badly, they are to blame only themselves when they get in the trouble.
And Razbam got in the trouble, in big trouble just last autumn. What you were hired to fix.
Does it require reviewing again by the ED?
Yes, to you it can be a nightmare... For others it is more efficient way and truthful.
Hold on.... shift through a 2.2K posts to find a solution?
What argument is that? Really?
If you have a problem with the gun sounds disappearing since last update, why would you go to browse bug reports about weapons, avionics, or missions and campaigns?
And if someone does have a problem in procedure, that is not a bug report, that is a common discussion "How do I....?" instead "bug". There shouldn't be searching solution for a problem in bug section, it is there to check out that is there problem in the code that developers needs to fix. Not to go searching "Why doesn't my gun work when I have RPM 55% and nozzles angle 82!?!?!?".
Why would you look RESOLVED section for a bug report if you want to know is it already reported?
If you have a bug like a gun sight doesn't point where the bullets lands. Why do you go searching "Solved bugs"?
If you have a bug that TPOD compass points completely wrong direction, why would you look "is it already fixed" from "Solved" part when you have it?
First thing to do is to update to latest version, check does it still exist. Then if it exist and you want to report the bug, you go to "Open Bugs" listing. There you do quick check that is there a report about it or not. If you don't find something there, then you fill a bug report.
There is no reason what so ever to go "Resolved" section to find out is a bug fixed.
That is what the labeling is for.... Why the bug reporting systems has own mechanism to easily keep a track that what is open and what is closed.
When you put a label "Closed" or "Solved" then it means that it is done, completed and it can be moved to "Resolved" section. But before it gets there, it requires that others will confirm that bug is fixed and doesn't exist anymore. That is as well part of the bug reporting that the reporter comes back to check is it fixed and if it is, informs "update XYZ fixed this".
When "FUTURE IMPLEMENTATION" tag is put and bug is moved to RESOLVED section, it is away from the open problems in the current version listing.
When you get a bug report, you link it to the internal material if you use such. When the developer has made the fix, it is marked as to be fixed in patch XYZ. When the patch is out, it is checked that is it fixed and if it is confirmed by others who had the bug, then it is marked as fixed and can be moved to RESOLVED section.
If you have system where one side is OPEN and then other side with CLOSED, it is wrong to have OPEN mixed with CLOSED.
Instead that, put all to one basket and then simply tag them "OPEN" or "CLOSED" as confirmation. Posts that doesn't have a tag are NEW, unconfirmed ones. Until someone else (anyone else from the community) can as well confirm it, what means should be tagged as "OPEN" until solved.
This is your system, [Problems and Bugs] and [Resolved Bugs] and it is same as [OPEN] and [CLOSED].
Why are OPEN reports moved within CLOSED section without fix?(Why are Unsolved reports moved among Solved?)
This is really a very simple To-Do list management.
[ ] Buy Milk
[ ] Print the daily report and map it
[ ] Swap the bathroom light bulb
----------------------
[x] Buy bread
[x] Buy light bulb to bathroom
[x] Change the printer ink cartridge
What has been done and what has not been done are very easy to see.
Even when something is known that it is to be done in the future, it stays NOT DONE until it is actually done.
If someone ticks "Buy Milk" as DONE because in the future they are going to buy the milk when they go out.... Where does it lead to?
The others does it different style by using categories. They keep the CLOSED and OPEN in the same sub-category. But they might not have added tags there that informs is it OPEN or CLOSED.
https://forums.eagle.ru/forum/320-bugs/
That is fairly easy to as well to look by the tags.
REPORTED is very clear explanation that it is acknowledged and waiting.
NEED TRACK REPLAY tells as well very clearly that it is OPEN and requires more information from users.
REPORTER EARLIER is like what? Instead use "DUPLICATE" and link to the original one (all duplicates gets linked to first one)
INVESTIGATING tells clearly that it is OPEN and it is being processed currently, not in some time in the future but currently.
CORRECT AS IS means exactly that how thing is going to be, - NO CHANGE.
FIXED well it can't be said more clearly.
FIXED INTERNALLY well, it as well tells very clearly that it is coming in the next patch or very soon.
W.I.P Meaning it is a long process and under work that requires lots of time.
SOLVED might mean that other solution than developers fixing code was required.
But again, ED keeps almost all in one basket. It makes more difficult to go through to find the wanted. Where example Magnitude keeps them categorized so person knows where to look quickly. They just don't use tags there like ED does.
One of the problems is that there is no good bug reporting tool used in DCS World, as the web forum is not really for that. It would help everyone a lot if a proper bug reporting platform would be implemented. Far more easier to keep track of everything.
It would as well allow developers to use directly the official bug report platform and be in direct contact with the users and get the direct information.
Person who would be responsible to manage the bug listings would have far easier job with proper bug reporting tools.
Im not arguing the point with you anymore. Clearly you have your mind made up and are not open to new ideas so its just back and forth at this point which I do not need to entertain. If you don't like how I do things, then tough. I have a system I like working with which helps the devs look into issues more clearly and makes it quite simple for the average user to come through and find a solution or report a bug. You are one person. I have at least 50 PMs from users praising the open concept and new reporting methods so I'm not going to just tailor it to you and how you think it should be done. End of story. AS INTENDED.
-
3
-
-
6 hours ago, tech_op2000 said:
@RAZBAM_ELMO Hey, since your actively posting here, can you find my bug i accidently posted in the general forums and move it to the appropriate bugs section?
rog
6 hours ago, netizensmith said:This entire disagreement can be solved easily and immediately by renaming the "RESOLVED" section to "RESOLVED and FUTURE ENHANCEMENTS". I see @RAZBAM_ELMO's point on this; it's not a bug if it wasn't even supposed to be in the module yet.
Some actual logical suggestions. Thankyou, that actually is a great idea and ill get in touch with the wed designers and add Furture Implementations either as a separate sub forum or attach it to the resolved section. Great suggestion.
-
2 hours ago, Fri13 said:
It is not matter of my opinion. It is matter how the bug reporting is done in the industry so the people can actually keep a valid track of progress.
there is not a standardized method, each company is free to do things they want. We are our own company. Agin, this is your opinion that it should be done in the usual industry way.
For instance, lets have a look at the MiG21 BUGS SECTION
and now lets compare our MiG-19 bugs section
To me, that is a nightmare and a half seeing almost over 200 posts in a single thread which could be RESOLVED or REPORTED. As a user with a problem, if I want to find a solution to a bug, would I want to sift through want to go through 2.2K+ posts to find a solution OR would I not look at the RESOLVED section to see if my problem has been fixed previously or/ then go to the reported section to see if it has already been reported?
And from a moderators standpoint. Tracking an active bug vs ongoing conversations off topic how easy do you think it would be for me to find a topic to reference?
-
On 2/9/2021 at 11:03 AM, Fri13 said:
While you are technically correct that if there is no code, then there can't be a error in the code that makes the code non-working.
But, the bug section is the general one that includes everything from a translation errors, the texture problems, the 3D model errors, the missing features, the wrongly implemented (yet code is working correctly) features etc.
That is the BUG in layman language these days.
If there is a missing feature that belongs to the aircraft, then it is a bug report and it is not to be moved away until the feature is implemented and users can download it and use it. As long bug exists, bug report belongs to stay in the list of open bugs.
No it doesn't. It just informs that that report is reacted, but it is not yet fixed/implemented/corrected. That is the idea of the whole bug reporting system that if the report is valid, then it stays in "Open Bugs" section, until it is solved and confirmed by the users and only then it is to be moved to "Resolved Bugs".
How it is nullified? The report is valid, it exists and it has not been fixed?
When the person responsible for managing the bugs moves bug reports that are valid (and unresolved) to resolved directory, it is completely wrong! They are not fixed, they are not usable, they are still missing, they are still wrong what ever the bug report is about. Not until the bug is properly fixed/dealed and the update has been released for the users, only then can the bug be marked as "Resolved" and moved to corresponding category. Until then it is a open bug report, and it is reminder for everyone that it is not yet done.
Speaking about the clutter:
Anyways, it is critical and correct that any bug report that is valid (confirmed) and is not fixed, stays in the open bugs section even when the developers has it in their internal To-Do list.
Bugs section is not a information table that is used to "Yes, we acknowledge this, now go away....".
It is about being a public, listing of all the features, errors and mistakes that are to be resolved in the future. You can mark it "Confirmed" instead and then write the reply to the thread that what is the schedule, timetable or future plans, but never move the report out of the bug section until fix is on the users hands and they have confirmed that bug is fixed.
Otherwise there happens the same thing as with the last update where the analog clock shows still a ZULU time, even after it was in the update patchnotes marked as "FIXED".
The idea of the closed beta tester group is that every single one of them will go through every single bug report that is to be marked as "FIXED" and every single one is required to confirm all of the listed bugs to be properly fixed. Then that list can be given to you that confirmed bugs are confirmed to be solved so you can gather the addresses for the bugs and be ready to mark them as solved when patch is released by asking bug reporter to confirm that update fixed it.
Bug reports management is time consuming task, there is no time to chat in the Discord or Facebook but all the time is suppose to be put on the bug report management here. It is about tight cooperation with the closed-beta testers and get them as well test every bug report that is opened and communicate with the community here that what is bugs state.
It is socializing with the people and work between programmers and the end-users and keep everything tidy and clean, but pushing valid bug reports to "Resolved" is just completely wrong method.
Again this is a matter of your opinion and how you feel it should be done while I am the one attending to it. I have made attempts to de-clutter old posts or merge them into one but recieved blow back from people on it so until the majority of active implemented systems bugs are cleared I will not be adjusting or removing any of them and ones that are not yet implemented I will put into the resolved section as I see fit.
-
problem is there is not a whole lot of documentation on them as they were phased out quite quickly. Are you launching within 9nm?
Departure and Changes on the Horizon
in RAZBAM
Posted
Good afternoon horde......erm I mean you beautiful conglomerate of individuals whom I love and appreciate so much.
It is with great sadness that As of Aug.1/ 2021 I will unfortunately have to step down and away from RAZBAM Simulations due to conflicting issues with my current employment. This step down is due to my work situation and not due to any issues with the community, RAZBAM team members or with ED team members. It is a situation directly out of my control so I want to make that very clear to everyone.
I would like to thank many many people but most important of all would be my colleagues at RAZBAM. Over the last few months they have opened up to new possibilities as well as adapting to rapid changes. From the onboarding of new members and the creation of new projects and team leads, the team has done a stellar job and it's disheartening to leave. If anything over these past few months I can say that my main goal was accomplished, leave RAZBAM better off than I came in and I hope you can all agree.
It is however time for me to pass on the torch. Myhelljumper with be the interim CM while a replacement is found, but nothing other than that will change. The team is full steam ahead on our announced and secret projects, pushing the boundaries and inventing new things within the DCS world and we can all applaud that. Its been a blast, I'll still be here....hiding in the shadows. I kid. Thankyou, the community, for being patient and supportive with me an the team while things got shimmied around. RAZBAM wouldn't be here without all of your love and support. Continue to be kind and understanding to one another, help what and when you can because were all on this planet together so why not enjoy this simulator together