Astronaut

I would love to see an option to have ground units placed in mission editor be able to be set as appearing hot in FLIR. Many of the missions we make, especially sandbox style missions, use a lot of non-moving vehicles. There's some realistic limitations as to what we can create and what our PC hardware can simulate and how much time we want to spend in Mission Editor vs flying the missions. I wouldn't argue that there's any bug or error in how FLIR is currently simulated, I just would like to pose the option of having stationary ground units appear as hot for simplicity of us building the missions. But It would need to be an optional check so that if you did want ultra-realism when making the mission you have that option, but if you're just not reasonably able to build a mission with units in motion you can still have a working FLIR.

unfortunately late activation doesn't work with client slots. the only current way to do what you're looking to do is with the Simple Slot Blocker script.

still not fixed

That also will create issues, if a dead unit is dead twice, once as a unit and once as a static. I have scripts that monitor statics and scripts that monitor units, so that would create just as much of a headache as the current issue. I just want it to report a dead UNIT only. That's what was placed in ME or spawned in scripts, that's what I expect to see the event for.

For everyone waiting for ED to fix the scripting issue making persistence not work, edit Surrexen's persistent world lua for LOAD STATICS to the following, addition in green. quick and easy fix that'll get you through until ED addresses it: if file_exists("ScarletDawnStaticInterment.lua") then dofile("ScarletDawnStaticInterment.lua") StaticIntermentTableLength = SEF_GetTableLength(ScarletDawnStaticInterment) --trigger.action.outText("Static Table Length Is "..StaticIntermentTableLength, 15) for i = 1, StaticIntermentTableLength do --trigger.action.outText("Static Interment Element "..i.." Is "..ScarletDawnStaticInterment[i], 15) if ( StaticObject.getByName(ScarletDawnStaticInterment[i]) ~= nil ) then StaticObject.getByName(ScarletDawnStaticInterment[i]):destroy() SEFDeletedStaticCount = SEFDeletedStaticCount + 1 elseif ( Unit.getByName(ScarletDawnStaticInterment[i]) ~= nil ) then Unit.getByName(ScarletDawnStaticInterment[i]):destroy() SEFDeletedUnitCount = SEFDeletedUnitCount + 1 else trigger.action.outText("Static Interment Element "..i.." Is "..ScarletDawnStaticInterment[i].." And Was Not Found", 15) end end else ScarletDawnStaticInterment = {} StaticIntermentTableLength = 0 end And a big Thanks! to Surrexen for his missions!

I no longer look at initiator object category, just initiator category. it'll return whether it's a static or unit but that's the best I got. and you have to use an active filter, not filter once. I agree it's very frustrating. I don't want to update all my missions because I don't like doing it this way and if they fix it i'd go back to the old way. but the fix is probably measured in months to years, not days to weeks so best to find workarounds. it shouldn't have made it into stable, but really, what's the point of stable anymore? it's no more or less stable than Open Beta (mostly a compliment for not crashing open beta with the new closed testing procedures, ) just delayed. This seems like such a small bug but it's such a huge PITA and really hampers some of the missions i build.

After the 2.7.11.21408 update, when using moose event handle scripts (EventData.IniObjectCategory) I notice that when a ground unit takes damage but does not immediately die, just burns for a while, when it eventually does die it's reported in DCS as a STATIC object instead of a UNIT now. This is new behavior, and I'm not sure if it's a bug or a change ED intended to make. But the same script on the previous version always returns the dead unit as a UNIT, not a STATIC regardless of if it burned a while and died or outright dies. It seems like burning units are now replaced with statics.

yeah I have "fixed" it too, my method just combines the static and unit internment into one array, then an if + elseif to check if it finds the entry as a unit or static. seems to work.

This isn't limited to infantry. I use the same persistence script you made in a mission I made for my server. after the last update it recorded a lot of the ground units as statics. I can't be sure if it was all or just most but I would suspect it was most. Armor, artillery, SAM units, and infantry were all recorded in the static internment file. It's weird because when I just make a blank mission with the debug lines on in the persistence script, a ground unit that dies instantly is recorded as a unit in the EventData.IniObjectCategory like it should. but if it burns and then explodes later, when it gets recorded as dead in the event it's recorded as a static in EventData.IniObjectCategory. But the in EventData.IniCategory it still seems to record it correctly. Hopefully that helps? I dunno why the sudden change.

edit: file doesn't work. sorry, I tried.

The removal has been a gift from God it's so much better in VR! Do not add it back!

Tin Shield is code 130 SA-5 Gammon is code 129

The testers have always been us. Unless you're interested in whether an A-10 can land and take off from the kuznetzov while saying morally questionable things, then there's another group that can test and answer those questions.

Oh it works without mods I already know. And it works with just FSR. It just has a hard time loading with the VR shaders mod.

I'll start this by admitting I know the reason is mods but here is the issue I'm having. Since about 2 patches ago (OB) I just cannot load into a game with any of my VR performance mods. The loading bar gets stuck at a few points, whatever.n5g or net sim post start mostly but not exclusively. sometimes it goes through on free flight but loading into a MP server 95% it gets hung up forever. The mods I'm using are Kegety's VR shaders (with speed-of-heat's hotfix) and FSR. Without the mods it loads in ok, slower than it use to I think but it loads. I know many of you are using these mods and not having this issue so what could be my problem? If I load into 2D and try it it still has the same problems. there are a ton of these in the log when it hangs at whatever.ng5 2021-10-15 16:01:34.006 ERROR DX11BACKEND: Can't find precompiled shader model/transparent_self_illum_material.fx:BLEND_MODE=1;DIFFUSE_UV=tc0;DIRECTX11=true;TEXCOORD0_SIZE=2;USE_DCS_DEFERRED=1;. 2021-10-15 16:01:34.006 INFO DX11BACKEND: Compile shader: model/transparent_self_illum_material.fx:BLEND_MODE=1;DIFFUSE_UV=tc0;DIRECTX11=true;TEXCOORD0_SIZE=2;USE_DCS_DEFERRED=1; 2021-10-15 16:01:34.008 ERROR DX11BACKEND: Can't open include file: /shaders/_HMD.hlsl. 2021-10-15 16:01:34.024 ERROR DX11BACKEND: Can't open include file: /shaders/../../deferred/_HMD.hlsl. 2021-10-15 16:01:38.433 ALERT DX11BACKEND: Error: Can't find precompiled shader for effect model/transparent_self_illum_material.fx:BLEND_MODE=1;DIFFUSE_UV=tc0;DIRECTX11=true;TEXCOORD0_SIZE=2;USE_DCS_DEFERRED=1;. Recompilation process will take some time, please wait (this situation should not occur on end user PC, if there is no manual shader editing) My assumption was it had to recompile shaders, so I let it in a few free flights and missions, I keep trying to load into maps but 10, 20 min will go by and nothing... randomly it'll go through, I had it work once last week in a MP server, and once in it worked mostly fine (one moment when a few units spawned in the whole server had a quick momentary stutter, everyone else recovered in a second or 2 without mods, I took about 8 seconds to get unfrozen). I mean I can go back to no mods and be ok, but it was nice having high framerates, 230% SteamVR SS, no stutters and actually having MSAA and shadows on at the same time while maintaining good visuals and 60+ FPS on the ground. i9 9900k @5.0ghz all core rtx 3090 64gb RAM @ 3600 CL16 1tb NVMe install SteamVR Beta Valve Index Windows 10.

Just FYI, 80c in a stress test of a i9 9900k is completely fine and normal, don't worry about temps as long as you stay at or under around 90. That chip will run hot, but with a decent cooler, AIO, you'll have no issues with hitting 5ghz all core with hyperthreading on. I haven't seen many that can't. Auto vcore is probably outputting more voltage than is actually needed, manually tuning will help you bring down the temps a few degrees too. 9900k really just needs 1.2v at the chip to be stable, which at full load with minimal LLC usually means 1.3-1.33v is usually fine. On a good chip you can get even lower.

5nm I believe.

I've had these on my cm2 throttle for a while, they've worked great. Got mine printed from shapeways. No issues with durability.

I too would love this. Even just a slimmed down implementation that can run on a non-gaming laptop using an igpu and a reasonable amount of RAM. I often am not really interested in testing missions or even the quality of the models when I start building and placing units, statics, writing scripts... All that can be time consuming and take days or even weeks until I'm at a test phase. It would be nice to be able to start building missions, get the bones built out in a less demanding environment. It's something I could work on from my laptop while I watch tv, travel in an airport, get bored in a hotel. All of which I'm not interested in buying an expensive laptop that I don't really need or want to do. Obviously I don't consider it a high priority development item, it's a niche use case. But it would be a nice to have thing.

Lol good god please no. Last thing we need is another dummy weapon to fight in forums over.

So I'll get to put JSOWs on the inner pylons then by your logic?

Maybe you missed my point, or I wasn't clear, or we're on different pages, I dunno. Yes, that's absolutely fine with me, that's why I said I only partially agree. The USAF F-16C doesn't have the capability to fire the HARM on 4/6, so why include them as an option because someone showed them a picture of a test flight? So if we're stimulating USAF or USANG block 50 I shouldn't be able to load them on 4/6 at all is my first point. If you wanna tell me I'm simulating a block 50 that may also be a test plane then why wouldn't it be conceivable that they might install the needed things to also fire it. If I can fly test loads why can't I test 3 gbu-12 on a TER on station 3? Fins interfere with the wing tanks but what if I'm not running wing tanks. My point or more so my opinion on the matter is that if we're given the option to load them on 4/6 then we're saying it's a gameplay compromise because in reality it can't any more than it can load 6 gbu-12 on stations 3/7. And in such a case I think we should be able to fire them. And I'm fine with that too, I feel as if you're one of the people that prioritize gameplay then I am fine with that being an option, if you prioritize reality and revit counting then no one will force you to load and fire HARMs from stations 4/6 if you don't want to do that.

In part I agree with Punchout, if ED is making it available to load on stations 4/6 they should make them operational. I know the argument is they don't maintain the wiring necessary for data but since there's pictures of it loaded they let us for the screenshots. But those pictures are likely from USAF verifying it's a valid loadout, just one they'll never need to use, so they don't maintain or install the supporting systems in the plane. But in DCS our needs by nature of this being a VIDEO GAME do not perfectly match IRL. I mean if you tried to mimic IRL ops there would be so many planes in the air it would set your computer on fire. If the USAF ever did have a need for the use of 4 HARMs they absolutely would maintain that ability as we've seen it's possible from other nations AF. ED needs to get off the fence, either simulate it's full capabilities in which case we should be able to use them on 4/6, or simulate realistic operational loads as per USAF and/or USNG and take the option of loading on 4/6 at all away, as well as all the other completely unrealistic loads, like caring 10 CBU-97s, or 6 mavricks.... The airframe is capable, if Punchout wants to use 4 HARMs in the sim he can imagine that for his mission his squadron decided to have his maintenance depot retrofit the wiring/software/whatever to 4/6 to support his mission needs. If it's shown the jet can technically support it, why not, just because US doesn't use it doesn't mean if they wanted to they couldn't. We can't simulate 200 fighters thousands of ground units at a time, we're often doing sead with a 2 or 4 ship in the game because that's what our computers and our patience with the mission editor can handle, if that's all the USAF had to throw at SEAD and they actually thought HARMs were useful they'd probably maintain the ability to load and fire 4 of them. But that's just my opinion on the matter. Pick one, either let us fire 4, or only let us load the 2. Anything else is just kinda dum.

The owl-head / g-load restriction idea is absolutely terrible for one clear reason that you cannot fix. The fastest way to make someone sick in VR is have their view and their head/inner ear motion not be in agreement. We're not in fighter jets, our body thinks we can turn our head, but if what we see doesn't match we'll vomit. Want to know how to turn people off from a game and make them not want to invest in it, make them vomit when they play lol.

Forget north up, I just wish the MFDs were half as bright and readable in VR as this. OMG would that be a MASSIVE quality of life improvement.