prccowboy

I *think* the SnapViewsDefault file is only in the program files install directory (config/views) and you will only have another SnapViews file in the Saved Games (config/views) folders if you CHANGE or customize the snap views in game (which overrides the default)

Not only does it cause the Radio Transmission to not work, I've found that leaving it 'nil' causes a cascade effect where other ME triggers 'break' I assume that it needs a reference/name to identify and run the code properly. Just name it (and again I assume it needs a unique name) then you will have no problems. A similar one is if you run a script as a Advanced Waypoint Action. The script requires a name or you break stuff.

Are you using the default SLI profile or did you create a custom? If using default, you are probably NOT getting SLI benefits in DCS. see my guide here for setting up SLI in DCS: https://forums.eagle.ru/showpost.php?p=3410823&postcount=65

Grimes, thanks for the explanation and many thanks for all the help you've given me for different questions. So, it looks like if I want to create a new location for a group (regardless of respawn/clone/teleport) then afterwards I will need to check alive/dead status of individual units in the group with a Unit.getByName('someName'):getLife() script instead of using the ME trigger conditions: Unit Dead(someName) or Unit Alive(someName)

When MiST 'teleports' a group, is it just changing the location of the group and units or does it create new units within the group? The reason I ask is that if I teleport a group, the ME triggers consider the group 'alive' but all the original units within the group are 'dead' (running 2.5 release)

glad to help. especially if it means that I can be CTD free in the near future :thumbup:

I admit I'm not much of a rotary guy - my attempts at flying the UH-1H usually result in bad things happening when I try to hover/land so I'm a little clueless about what should be accomplishable. I've seen some dramatic photos of a CH-47 delivering troops and cargo to Afghanistan mountaintops with only the ramp touching the ground but I'm confused about what is realistically accomplishable for mission building. 1) The hover OGE ceiling for many of the helicopters is much lower than many areas of the Caucasus range. Does that mean that it is not possible to safely transport cargo/troops to these areas? 2) Also, google searches seem to indicate the service ceiling for a CH-47 is 20,000 ft, but in DCS the CH-47 appears to struggle above 10,000 ft for cruising. What's going on here?

I don't know much about it, but doesn't the OH-58 have a MMS with 360 degree view/designator capabilities?

Here, I give you both a track and the corresponding .miz I was trying to create a mission that contains the basic elements that will cause the crash and nothing more (but there is still a little bit of extraneous stuff in there from the original mission I was building - I also forgot to remove some debug text to myself) Nevertheless, it shows the crash conditions. The track should crash at about 28min 20sec with a Transport.dll error postscript: I've been playing with a new script for dynamic route building and it seems promising (for crash avoidance) <= nope, this just reduced the crash frequency from "always" to "sometimes" I appreciate any feedback regarding what others find...

What was the resolution on this? I'm having consistent Transport.dll crashes when I try to build a new mission (very simple SP missions) and wondering if it is a related problem.

no need for additional waypoint at drop off - the Cargo Transportation Task adds the Zone waypoint as part of the task

Transport.dll crash This is really frustrating me. I still have constant crashes. It appears to always be Transport.dll (at least that is what Windows reports), but so far, I haven't been able to specifically pin down the behavior that causes the crash. However, it *seems* to be related to moving vehicles that are attacked by air (and possibly, dynamically spawned vehicles specifically). Is there a known bug with Transport.dll? it appears that some others have similar problems but I haven't seen a definitive answer on this. :cry:

If you are running "standard" settings in Nvidia Control Panel then you are NOT running SLI in DCS because the Nvidia profile doesn't work. Drag80, was correct that you can get more out of your system. I wrote a DCS and SLI guide here: https://forums.eagle.ru/showpost.php?p=3410823&postcount=65 Also, if you are getting better fps in other maps, then I suggest reducing "visible range" setting. There are a lot of objects in Caucasus map now. Changing that setting will reduce the workload on your system. edit: I know that many people will say buy new hardware but honestly you can optimize your system to get decent performance out of it. I built my current gaming rig many years ago for DCS A-10 1.0 and I get better performance NOW with 2.5 and DS than back when I first built the rig (by finally figuring out optimal settings). In fact, I now have the performance with my "ancient" rig that I wish I had with DCS 1.0 when my rig was "bleeding edge". I run mostly high settings @1080p with FXAA and get about 90fps sitting @McCarran and around 60-70fps in Caucasus with "ancient" Fermi cards and a moderately overclocked i7-3930. Of course the fps drops with TDR on and "heavy" action but overall the performance is better than when I first started playing DCS standalones (long before DCS World). My cpu performs better than yours but you have faster gpu's - I suspect that once you have SLI working in DCS and you drop some of the CPU load by tweaking your settings, you will have much improved performance. Check your CPU single core usage - you probably have one core that is maxed out while the rest of your i7 cores are nearly idle. I also have some examples of cpu/gpu relationship on performance in the thread I referenced above.

Advanced (Waypoint Actions) => Type: Perform Task => Action: Cargo Transportation =>Group: (Name of the Static Object: Cargo that you want to transport) => Zone (Name of Zone you created where you want to drop it) If you still have trouble I can add to the embark mission example I made for you to include cargo drop too

Yes, I made a quick example for you using the Mission Editor. You need to use advanced waypoints actions. For the infantry waypoint, You need to add the aircraft type under "vehicle group" (ex: UH-1H) that you want the infantry to embark to (or a specific unit with Binding to Transport and unit name) and for the aircraft waypoint you need to add what group is going to do the embarking (below the 'Distribution' checkbox there is a drop down, use that to pick the infantry group name) then click add (same for disembarking) EmbarkExample.miz You can also do it with scripting by using pushTask with the tasks: "EmbarkToTransport", "Embarking", and "Disembarking" (or use something like CTLD)

the crashes definitely seem to be related to path finding and transport.dll. I have had zero crashes since I changed to manually building AI paths (and explicitly avoiding terrain objects along the route) update: I think I just got lucky on rebuilding that mission. I still have constant crashes no matter what method I use to build AI paths in other missions.

hmm.. maybe that's it. I have been using a lot of mist.groupToRandomPoint in my mission building. I will try a test where I spawn everything stationary. update: A sample size of one isn't a true indicator but by changing my mission scripts to spawning only "stationary" units seems to fix the crash. So, it appears to be a bug related to transport.dll and pathfinding. Bummer, now I need to try rewriting all my missions by building manual paths for the spawned AI

I was looking thru the Windows logs and it seems that 90% of my crashes are related to transport.dll. Does that imply that the crashes may be related to path finding for the AI?

How do I keep both installs and make sure that they only update their branch? After I installed the stable 2.5, my Registry key changed to reflect only the new install. Can I manually add a "DCS World OpenBeta" key to point at the OB install - and will this prevent updates to the OB messing with the stable version?

OK, here is another example. I just tried flying one of my WIP mission test builds and had another crash. I deleted the fxo and metashader folders before the mission (which shows in the log), but this time the error was something new (I don't remember seeing this one before) ERROR DX11BACKEND: invalid technique pass, line:1516 here is the full log: dcs.20180406-181402.txt BTW, memory commits were about 12GB at time of crash Thanks for any feedback.

ok, here is one of my full logs (I have a lot to choose from). I think this is one of the "typical" crashes but not the one where it hit 21GB memory committed (I think I still have that one too if you want it) dcs.20180406-012820.txt postscript: I will attempt to actually fly one of my latest mission builds today and send a new log if I have another crash. Mostly I have been just testing the missions from ME and letting them run at 5x speed to check my scripts.

While DCS is mostly stable for me flying the "vanilla" missions/campaigns (like Georgian Hammer or Red Flag), I've gotten a little bored with them and have been attempting to build my own but I consistently see crashes now (usually after 20-60 minutes "game" time). It has been a bit frustrating because I don't know if it is my scripts/mission building that is causing the instability or something else (like memory leaks). I don't think any of my scripts are firing when it crashes (most run within the first few seconds) and I don't see anything in the logs that indicate a script error or hardware faults but I am open to the idea that maybe it's on my side. The missions I am creating are not "heavy" - usually about 300 total units (half that being unused late activation groups for a dynamic spawning pool) Nevertheless, whenever I see a crash, there is usually high memory usage. I have 16GB RAM with pagefiles usually set at 16 or 32GB. In one of my recent crashes the memory usage was 9.2GB used and 21.4GB!!! (of 47.9) committed with 6.6GB cached. However, most crashes seem to happen around 12GB committed. (memory commits are at about 1.7GB without DCS running) What I'm looking for is feedback whether or not it is something I should be looking at on my side or if it is something outside my control (like a known memory leak). I'm attaching some snippets from my last 5 crashes (what happens immediately before the crash). A common error seems to be related to tracer model json files... Thanks in advance for any feedback (this has been really frustrating my attempts at mission building) edit: changed thread name because its not a memory leak, but possibly a different bug

I couldn't run your example because I don't have the mods you are using, but I created a quick mission that does what I think you are trying to do. I made a FARP with 2 aircraft blocking pads and a few static objects. The inbound Mi8 will land and shut down engines and crew will exit. Note: I did see the behavior you mentioned if the fuel is too low. Maybe DCS is automatically adding an emergency landing task if fuel state is critical, then after it lands (and refuels), it starts again to complete the mission (which still has a WP landing that wasn't completed) <= just speculation on why. If fuel state is a little bit higher then the Mi8 behaves the way you want. helo landing test.miz

hmm.. spawning a static effect DOES spawn something. It shows up on the F10 map with the correct icon and desc, and if I change the shape to "flare" then it will render the flare at that location but I still haven't figured out how to get the correct particle effects animation.

I think it is because you added an advanced waypoint action, effectively giving the helicopter an additional task to complete before finishing his mission. Why not just change the DP waypoint to type "Landing" and remove the advanced waypoint action? edit: Also, if the static Huey you already have on the pad is causing problems with the AI landing on it/crashing, you could replace the static Huey with an AI Huey, pick the parking spot you the Huey on (to "reserve" the spot), set The Huey to takeoff from ramp with no other waypoints and set him to zero fuel. That will keep the parking spot used up on the FARP with a helo that never leaves the spot. - I just set up a quick mission and the behavior seems to work for me. Mi-8 picks one of the empty parking spots on the FARP, lands, shuts off engines and crew leaves. Huey sits on pad and never starts engines (but crew are visible inside)