AMVI_Rider

Hi, some answers have been lost sometime ago so when the forum backup has beem restored, to be short: load & save as well as the import from mission file is a work in progess and will be delivered in the version 1.1 (the next feature update). If you can provide some details on crash(es) I'll fix the problems. Thanks :)

Yes you are absolutely right: in the hurry of writing the guide I took the single engine climb table :doh: I will fix it in the next release. Thanks

Version 1.0.2.4 has been released This version contains a major update of A-10C weapons Drag Indices and some minor improvements/fixes.

Thank you very much!! Weapons Delivery Planner (that's used in our Falcon vFG) is great and I'm happy to see someone comparing DCSMP to it, but I need to add a lot more features before DCSMP can match it. :pilotfly:

Latest version: 2.1.3.2 AMVI is proud to announce the release of DCSMP a tool dedicated for DCS World mission planning. The software assists the A10-C and F/A-18C pilots in calculating takeoff, landing and fuel data just like it is done in the real world and enabling faster planning and more accurate mission briefing. The tool can be used also both for accurate planning of the whole flight and quick check of loadout/takeoff data. This release supports the A10-C and, with some limitation, the F/A-18C. In the future more DCS aircraft and new features (some of them are in progress) will be added. DCSMP is distributed free of charge in the hope that it will be useful to virtual pilots and as a form of gratitude to anyone supporting hardcore flight simulation. We ask everyone interested in the tool to link the original download page rather than redistributing the package. The tool and the quick start guide can be downloaded from the AMVI website

Same here (since 1.2.9). Issue is 100% reproducibile. Configuration is the same shown in my signature except for the monitor configuration that is: main display (1080p@75Hz) + DK2 + 2xMFCD (disabled). Logs ... Crash: DCS Crashlog: I can provide the dump file if needed.

I was investigating the db_weapons_data.lua file to check some details when I stopped in front of the definition of LAU-68/131 in TER (any kind of rocket): CLSID = "LAU_131x3_HYDRA_70_M151", ... displayName = _("LAU-131*3 - 7 2.75' rockets M151 (HE)"), ... Count = 21, Weight = 702, ... I found it to be too heavy compared to its single launcher configuration: CLSID = "{69926055-0DA8-4530-9F2F-C86B157EA9F6}", ... displayName = _("LAU-131 - 7 2.75' rockets M151 (HE)"), ... Weight = 100, Then I did some research for the real data: LAU-131 fully loaded with M151: 223 lbs (101 kg) LAU-131 empty: 68lbs (31 kg) M151: 23 lbs (10 kg) ... but I wasn't able to find the BRU-42LS specs then I took it from DCS: BRU-42LS: 143 lbs (65kg) The math: LAU-131 = 68 + 23 *7 = 229 lbs (104 kg) LAU-131*3 = 229 * 3 + 143 = 830 lbs (376 kg) The first one is confirming DCS data for the single launcher configuration while the second one, as expected, is quite different. Am I missing something? Later on I also found dubious drag figures for some weapons i.e. : - LAU-105 with and without AIM-9: The empty drag is greater than the 2 missile configuration that it's (properly) greater than the 1 missile configuration. - {BRU-42_3*Mk-82AIR} vs {60CC734F-0AFA-4E2E-82B8-93B941AB11CF}: Mk-82AIR drag is 1/5th of Mk-82 In the respect of drag It's hard to find real world data with the exception of this: http://www.dsto.defence.gov.au/publications/1988/DSTO-TR-0545.pdf

I'm not a big fan of FRAPS as I find it just too expensive to record a video. Looking around for a viable alternative I found this: Open Broadcaster Software Setup is a little bit tricky (in my rig), but works like a charm and it's free.

A quick and dirty way to detect VRAM swapping for signle-GPU cards is low FPS with low GPU usage. I usually test this situation by: 1. check the inflight VRAM usage, if it's near to the amount availble on the card then you might have swapping issue. Try flying low over densed areas / airports and by adding some units. 2. disable any GPU-saving feature (i.e. vsync, adaptive vsync, power throttling) 3. if your GPU usage stays low without any apparent reason then it's likely a VRAM issue 4. lower your texture settings (that's the most impacting setting) and try again ... if you see a noticeable GPU usage increase it's confirmed Once you confirmed to have VRAM size issue you need to detect how much is exceeding the "optimum". This is done by playng with settings (most hungry on top): A. Texture B. AA C. HDR (D. View distance / scenery) Lowering the texture detail always works (if it's a VRAM size issue) but if you just are a little above you can try diabling the HDR and/or lowering the AA that impacts video buffers (and GPU too). On point D I have no relevant data, but usually is not that hungry. Just try and measure to fine tune the settings. Considering only the VRAM requirement, 2 GB are always enough with a single monitor setup. With 1 Gb you have to play with settings. On a complex high-res multimonitor setup 2GB may be enough (see my specs), 3/4 GB would be better but you also need a top end GPU to process that much data.

As workaround of the workrkaround I found cleaner to prepare, move & rename the Export directory into the user directory as described and made a junction back to the original location. This worked with TARS and with some custom exports I have made. I mean something like: mklink /j "[i]<install>[/i]\Scripts\Export" "[i]<user>[/i]\Saved Games\DCS\Scripts"

To give you a straight answer you will be able to use 512x512 MFCD with 2GB of Video RAM, but you should have been with 1.2Gb too (unless you were using too high settings). Roughly video memory needed depends on resolution of display and texture/AA type and level. Also the memory bandwidth of the GPU should be taken into account for performance matters. I suggest you tu use nVidia Inspector or GPUz to take a look at the GPU and Video Memory usage during flight. Adjust you settings to keep the memory usage less than 90% of the available. You need to reduce (eliminate) data swapping from system memory to video memory. Once did the video memory tuning, try to keep the GPU running at comfort level and spare some processing power to compensate higher load situations (i.e. fumes, explosions, high object densities, ...). High FPS are useless if you experience lag / stuttering during attack. I found the Adaptive V-Sync feature of nVidia drivers very useful.

You don't really need a tutorial, nor a specific mission: it's just a matter of practice to stay connected ... thrust me, I had the very same problem and got a little bit frustrated until thing started to improve. Here is something I learned in between my training: 1. Be patient, always! :smilewink: 2. Stabilize and fine trim your plane both on observation and pre-contact positions: this prevents your arms to get tired too quickly and helps you to fine control surfaces with the right amount of force applied. Relax, don't squeeze your stick and throttle. 3. Approach and maintain the right angle on boom: to have better sight on the boom many tend to stay too high causing a reduction of margin. Once connected, try using pause and external view to check your position. 4. Don't fixate on looking at the boom: your reference should be the tanker position as seen from your cockpit. Lock or smooth your trackir/freetrack. 5. Practice flying some time with the tanker but without being connected. 6. I don't know how precise is your HOTAS, still, DavidRed is right about curvature: try adding some (10-15), practice some days until 100% success then start removing it. I think you'll be able to take it back to 0. 7. Remember point 1 :music_whistling:

No I just stopped with statics ... as you confirmed, I need to take another approach I read your posts about re-reading the mission table from temp directory and used your code to match runtime object with original mission table during export stop function to discover killed units without the need of constantly get the object table. If you ave any newer code I'm very interested in it ;) ... I see ... I took the export approach to avoid changing the sim files too much and in a way that became not compatible with other mods (i.e. yours) and to write some code from scartch rather than cutting&pasting too much. My MOD (let's call it a training on the job) main goal is to get killed units during MP missions: I thought about the debriefing approach but I think I will go for net to have some space for future improvements. Now it's clearly time for me to gain some expertise on the sim code :book: Thank you for being so kind to share yours!

I'm writing my first export script that just exports the object list to a log file. I noticed that static objects are not reported in the table returned by LoGetWorldObjects(). So, am I missing something? Is there an alternative way to obtain static objects from an export script? edit: forgot to mention that I'm referring to DCS World 1.2.0

Agree, this is a wrong (and common) assumption! This is not completely true: I have a 2 x 560Ti (sadly only 1GB only per card) in SLI and a three monitor setup. Both cards are running 80% of GPU load at full clock frequency in both DCSW and DCS World (windowed mode). The point is that Nvidia drivers limit you to one of these configurations: 1 Non SLI + 4 monitors of any type/res (that is what you were talking about). 2 SLI + Single monitor. 3 SLI + 3D Surround - 3 monitors of same type/res (where supported). 4 SLI + Dual monitor of any type/res (that's me: main + right MFCD). I also have a third monitor (left MFCD) attached to my Ivy Bridge integrated card (so to say, the third video card in the system). So my advice is to buy a SLI setup to boost performance as the rendering happens in the two cards working toghether. If you want a lot of monitors a cheap card could be the solution, but you can have it both at the same time. In all this, PCIe lanes usage should be taken into account, but it's quite too much to discuss right now. A note about SLI: to obtain a real performance boost in a SLI setup, a little tweaking of stock SLI profile is needed. That's my expereince, but AMD/Crossfire situation could be different (despite AMD's better implementation of multimonitor stuff).