fargo007

From the changelog:

What does the 1.2.1 Menu issue involve? I am seeing a problem where whenever carrier wrench is loaded, it makes the menus created with other scripts no longer appear. Is this a related issue? The only thing that makes the menus reappear is NOT loading carrier wrench at all. Even if it's loaded on a time_more of 300, any clients joining after it loads get no menus at all.

The same for me. 100% on the Steam VR SS, and 1.5 PD in DCS is the right combo for me, although some prefer it the other way around.

What I do is map the menu entries to functions, that contain all the assets required to make that menu entry work. This way it's very clean code, it's all self-contained and modular, and performant, because everything can be local inside the function, and nothing's alive on the map unless it's requested.

You are correct that you have to be trimming the Harrier constantly - defined as any time you gain or reduce speed, or add power. Bind the trim hat (gray) on your stick to nose down (fwd) nose up (back) and L and R. That's what most do.

Mine shows a recommended of 200%. I had been running it there with renderscale 2.0 and PD 1.3 in DCS, also using the kegetys mod. After the last update performance went way down. For the time being, I am running at 100% on the slider, PD 1.6 in DCS, and the kegetys mod. It seems each update new experimentation is going to be necessary to find the right combination of settings for both visual appeal and smooth performance. Each of them being subjective.

I just went to 32G from 16. No effect on framerate but it loads faster for sure. For me to get straight 45's in the O+ I have to use the kegetys mod, and go 100% on the steamvr video slider, and not the recommended 200%. 1.4 PD. I also use low terrain textures. In the PG map, I literally cannot tell the difference at all.

This is an excellent mod and one I've been subconsciously wishing for. SOOOO much easier than trying to come out of VR and write stuff down. I am also inquiring about changing font size. I'd like to go bigger if possible.

To me the map work being done since PG and forward seems more about the conflicts of the present & future than being very specifically focused on those of the historical past.

I can say that in SP, spawning an MI-8 in parking 4 puts me in the back, clear of the house. Run the same mission in MP, and I spawn right next to the house, and shorten the rotors.

What's the dcs.log say? Have a look at that. The code looks fine, I would double check the airfield names & the name of the F15 in the ME.

The textures for the damage model on some ground units is affected as well. Once destroyed, you will see a big green texture_missing square without the correct damage model textures.

We have someone in our squadron developing something like this by writing out XML to an external database with REST API calls. I have not yet seen under the hood but I've been in the mission, and it works very well. Restart it, and everything is EXACTLY how it was. It's very slick. This is a very sophisticated approach to it and it's targeted at very senior/advanced mission designers with script/programming/systems experience.

Thanks Urbi, I see a description.lua with each skin, but I'm not sure exactly what you are referring to in them. Can you give me a quick example of what has to be done in description.lua to fix these? Thank you!

Sure they can have waypoints! Wherever they spawn, they are then going to head for waypoint #1. Or if desired, you can route them directly to a Vec2 point that you can collect from any other unit (like sending them toward the location of a current enemy unit). I'll say that mod looks super cool and more realistic than having them just "pop" out.

I don't understand how this translates to many skins having missing textures.

I'd detect when it reached the beach with a trigger zone or zones in the ME (but better with scripted/polygonal), then spawn the troops with for example the SpawnFromUnit() method in MOOSE. Just spitballing here: -- landingcraft01 is the group name of the landing craft in the ME -- LCInfantry01 is the infantry that is supposed to disembark that craft (late activation) local LC01 = GROUP:FindByName("landingcraft01") local infantry01 = SPAWN:New("LCInfantry01") -- Then in the mission editor when they are in the zone you use a DO_SCRIPT trigger and: gogogo = infantry01:SpawnFromUnit(LC01) ------------------------ I use this technique all the time to spawn bad guys that get out of vehicles when it gets hit. Arrange the infantry knowing that the #1 unit of them will be dead center on the landing craft at spawn.

I also think the type of flying you are doing matters a lot. Flying CAP in a Hornet at 26,000ft is a lot easier to get good looking 45fps than it is with an Mi-8 at rooftop level flying through a densely populated Iranian city. Another setting change that might help people on PG - You can set the terrain texture to low and lose very little if anything at all visually. It's indistinguishable from high for me.

I've noticed problems with Huey skins/textures missing.

Found this hiding out in the menu.... "Airborne Troops"

@etherbattx: If that's the case my answer would be "not so great." It's not terrible, but up to this update (and using kegetys shaders mod) I had solid 45's in every AC, nearly everywhere. Now, 30 is my high water mark most of the time, with the Huey and Harrier showing the best performance. It's a wholesale 25% performance drop in FR for me. O+, AMD Ryzen 5, 16G DDR4, 1080ti. I'm also seeing missing textures on some Huey skins but still not sure what is causing that. Even after a repair.

I'm in a better place with all but the MI-8. The cockpit is very stuttery with head movement but this does NOT occur in any other helo. Harrier is smooth as glass. Thanks for the check on my initial observations fellas. ETA - It's undeniable that the frame rate for me is substantially lower with this update across al A/C. I struggle to find another benchmark. It is what it is - maybe I'll try shutting off MSAA.

I'm going to do that. I'm seeing enough weirdness that it could be something like that. I'd love to be wrong here. Repairing.

Still testing but this update was a step back in performance so far IMHO. A pretty big one.

@Habu - Those are the DETECTION classes. ;-) How to keep mission in daylight hours, or night hours if desired: Use a reload mission trigger that works off the mission start time. So if your mission starts at 0630 and it gets dark at 1830 that day, you have 12 hours (43200 seconds). At 43000 (or desired time) fire a trigger that warns everyone of mission restart. Then at 43200, you simply use a load mission trigger. The key here is to build the interval from your mission start time which is constant, not the actual time of day which varies based on when you start the mission.