Jump to content

DroptheHammer

Members
  • Posts

    69
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks, this reply is excellent! I’ll give this a go over the summer and see if we can migrate to this. Appreciate your hard work on this and your detailed reply.
  2. sssooooo... Why would the Air to air radar make a SPI where the last bandit I splashed crashed in? And why would that point now be where the A2G Pod wants to reset to? Also, I practically never use the A2G radar to mark anything... Does this mean if I want to go back to waypoints, I always need to clear both the pod and the A2G radar even if I only marked with the pod?? In the past I never needed to do this. just SPI designate with the pod, and clear it with undesignate.
  3. I would argue this is less advanced. as now a user still has 40th Livery Pack - phoenix _ 1.9.0512.zip installed and had no idea it should be gone. How would OMM know to remove that one and replace with 40th Livery Pack - phoenix _ 2.0.0529.zip if I removed all prior entries from the repo? With OVGME it flags all versions older than a certain version code (in metadata, not file name) and works great for this. Maybe i'm missing something? Metapackages might be a better answer, but how will I not end up with junk on the end user side? do I tell them to just clear their own local repo first? I dont want to replace from 1.9 to 2.0 on some subpackage and they still have 1.9 hanging around on their system.
  4. Brief introduction In Slave mode, The WMD7 pod used to give up it's current orientation, SPI or otherwise and point at the currently selected waypoint if the "Undesignate" button was pressed (same button as ending a radar lock). Detailed description After an A2A kill, or some area track is established.. the pod no longer returns to waypoints like it used to when a SPI is cleared / undesignated this used to be great, because if I had say a... Pre Planned 1 (WPT36) in my computer.. I could slew the pod to that with undesignate and then check that area for targets.. shoot at something, and then put the pod back on WPT36 by pressing undesignate again. How to reproduce Fly to a waypoint, slave the pod to it... attack something not at exactly that waypoint (air or ground) and try to get the pod back to exactly the waypoint you had before via undesignate. The pod will end up putting itself where your last area track was and not your waypoint. Attach dcs.log and trk All of my track files for this are larger than 5MB. Not sure how to get such a small one.
  5. Hello @sedenion I'm a mod manager for my squadron. We currently host an OVGME Repository with some 35 mods (mostly curated from the DCS Forums but many of our own livery packs, assets etc). Currently with OVGME, we will have a mod named something like this... 40th Livery Pack - Phoenix.zip This is compiled with OVGME and has metadata like the version number (1.8.403) and description embedded into the archive using OVGME's archive builder. We upload to our repo and update the MODS.XML in the online folder to change the version number to the latest. Then when users sync their repo, they get the orange checkbox saying (you already have this, but it's an older version). From there they can sync up and download the latest ones. With OMM, the best I can see.. the version number is now forced into the file name, and this makes the repo potentially a mess as you would have the following. 40th Livery Pack - phoenix _ 1.8.403.zip 40th Livery Pack - phoenix _ 1.9.0512.zip 40th Livery Pack - phoenix _ 2.0.0529.zip Personally I would prefer not to have all these versions in the file names. It means someone can accidentally download and install 2 over each other. How should I handle this in OMM? What steps do I need to take to manage this? Thanks, DTH
  6. I think he covered it in this paragraph.. “The chaperone can be forced on at: SteamVR menu - Developer - Debug Commands - collision_bounds_toggle. Now, if the configuration is correct, the chaperone lines crossing the cockpit dial remain accurately fixed on top of each other in any position, rotation or tilt of head while wearing the headset. Even a small miscalibration can be perceived by looking e.g. at a cockpit dial down and to the side and turning and tilting the head around as in some head orientations the relative positions of the cockpit dial and chaperone lines appear to be different from other head orientations or positions. When config is good, changing head orientation causes no shift in the apparent relative positions of cockpit dials and chaperone lines.” makes me a little disappointed because I’m using OpenXR and don’t have this feature to use.. maybe if I set the alignment in steamVR it’ll carry over? I don’t know of a similar OpenXR function.
  7. @Taz1004 If i'm looking to cut the DCS Haze down.. which sub section/file do I need to alter? in VR it's just too much, I can barely see things co-alt at 12 NM. I know the dot is there becasue I can see it higher or lower, but just not co-alt with the factory haze.
  8. So after I purge shaders you’re saying on the first run it’s better to compile everything in 2d? Then run VR later? Is this better long term for frame times or jitters or something? or is this only to avoid being stuck in the helmet while it flashes and jitters a bit on first load. reason I ask is I’ve been religiously compiling in VR first after making changes and wondering if I’ve been screwing myself over :)
  9. So far, the new patch it seems to be pretty reliable. However we haven't seen what happens on mission night with 40-60 players. Will provide an update later in the week.
  10. Alright, I forgot to come on earlier but I figured out why this is. It's all planes and not the Jeff. Simplex and other shader mods dont have entries for the new flir... so flir = instacrash. Please consider this thread answered although it isnt JF17 specific.
  11. Very excited for the new FLIR textures etc. However I loaded the Laser Guided bombs SP mission and the moment I switch the POD to IR mode I get a hard crash. Repeated 3x. this is from A-G master mode and using the pod on the left MFD.
  12. Reverse ground effect might be magnifying the fairly stable descent rate in the final moments. Combined with lag it might be a contributing factor. I also agree the plane feels stuck to the ground on takeoff compared to before. hopefully we get a pass on takeoff and landing characteristics as well as gear strength. Obviously it shouldn’t take carrier landing styles like it used to… but it’s way too fragile now.
×
×
  • Create New...