Captain Orso

That's a whole box full of work, there. I have one suggestion and one request. Suggestion: For demo missions, don't use DO SCRIPT for lua files. That's IT on foot. Having to open a lua file, copy everything over to the ME and insert it there is anything but user friendly, and a source for errors. Using DO SCRIPT FILE is simple and even hard to do wrong. Request: There are some veriable in scripts, which users might want to enter. I only know of one personally, but there might be others. In 'dcsCommon.lua', the variable sets the aircraft which can be used as transports: 'dcsCommon.troopCarriers = {"Mi-8MT", "UH-1H", "Mi-24P"}'. If you want to add, for example the UH-60L community mod, it must be added here. But editing files is not necessarily a good idea. the variable can be modified through the ME trigger command used to load the lua file to include the UH-60L very easily. This and any other variables, which might be useful--I'm counting on you to know which ones, better than I--ought to be included in the Guide. Smooth sailing to all, into 2024!!

and phantastic... phor real!

After nearly 40 years in IT, I can confirm the principle, never touch a running machine. The exception is, if you are unsatisfied with your current status. If you are satisfied, leave this thread, never look back, and

It seems to me that even open, clear, field causes 'ground clutter'. From my yet limited experience--about 30-40 AGM-114Ls fired under the control of FCR on MP training server from 4YA--about 1/3 of the Hellfires miss their target; some by only feet, some by much more. It's no wonder they had to implement a score card into the software for picking which targets yet need some TLC (Totally Loud Caboom!! the exclamation points are implied in the abbreviation).

Inquiring minds need to know

It has to be something you can do at any time during the mission. I do not even know where I will spawn until after I've looked at the F10 map so see what area I will be operating in and what FARP is nearby. Yesterday I did that, I cleared the first two target areas--the second being an airfield, which I captured. I refueled and rearmed at the airfield and headed off to the next airfield to capture, taking a route completely different from the first. So, as I stated in my previous post, the best solution would be to be able to recalculate the database at any chosen time.

You are forgetting that in MP there are no preordained routes; only the route you create yourself. The simplest solution would be to add all the units on the map in order of distance from your starting point. Another more sophisticated solution would be to allow for the player to create his RTE and then, per button-press, have the database be populated be distance from any point on the RTE. In fact, so that the player can have a educated idea of how to plot his route, allow the player to press the populate button first, using only he present location for distances, and then build his route with the information on hand. The as above again using the route added by the player, and distances from route waypoints. This might cause new CMs to be discovered, so allow the player to repeat the process until he is satisfied with the results. It can't get better than that, other than possibly adding filters to ignore certain unit types, if the map is so highly populated, so that important units (SAM, AAA, etc) are less likely to be left out, while some supply truck might be. Ofc this will take work to implement, so I won't expect the issue to even be publicly acknowledged for at least "two more weeks"

Currently all the relative objects placed by the ME are populated into the COORD database automatically, up to the maximum number per type of point. I've never looked into how this is organized, but I suspect something as simple as numerically per the unit id. On big maps on MP server, this leads to your Apache being loaded down with point, hundreds of miles away, you will never see or even come close to, while units fairly close by on the ground are not inserted into your COORDS DB. It would be awesome if when you spawned into an Apache it simply tabulated all the points and calculated the distance from your aircraft to the point--should be a trivial calculation per point--and then sort the table of objects by closest to furthest, and only then populate the COORDS DB. This would insure that only the most useful points were in the DB.

Thanks guys!! I'll give this a shot and see what happens EDIT Okay guys, that was the issue - ACQ is set to TADS by default, and then when TADS looks somewhere else, so does FCR. Set ACQ to FXD and the issue is solved

Okay hot start normal preps for flight take off SSS FCR FCR Mode -> GTM give CPG the gun So far, so good I note that if I use my HMD pointer to direct CPG to look in a direction, that afterwards the FCR focus is centered on that point, and if CPG has found a target and I tell him to focus on that target (George Helper -> Right), the FCR focus also locks on to that target. I would say FCR is slaved to the TADS. How did this happen? And how do I turn this off?

I could pretend I'm using one of those long grabby-sticks that they use to pick up the trash in the parks. I could just reach back and flip those two switches... and then smack George across his great, stupid gob with it!!

You still have to make it your sensor of choice and set the correct FCR mode for it to work properly, which is a bit confusing at first, because there are no indicators--or at least I haven't learned to find them yet--telling you that maybe you are doing something wrong, other than it just doesn't work.

If I'm flying as CPG, and that dang pilot has forgotten to turn off the Nav and Anti-Collision Lights. Without swapping seats, how do I turn the lights off?

Now this is how a map is supposed to look. Thank you Orbx..... oh wait... Isn't Lofoten in Skellige? Geralt...!

IIRC it depends on how many bombs you are dropping--yeah, I know, you ask A or B and some jerk says C I'd have to look into it again, but I think it was 6 or more or 8 or more bombs dropped meant the CCRP target point was measured in the middle, and < 6 ( or 8 ) meant measured from the first--more used with CCIP.

Non-aeronautically enabled

YES!! It works perfectly now!! The only thing I might complaint about, is when starting for the first time, and the old 1.1.1 style config files are all being converted, OMM complains that it can't find the hub.omx files, but after that no issues found Many thanks Sedenion

Nee no panic, but I did have to go back to 1.1.1 because I updated DCS yesterday and wanted to start learning how to spam radar guided Hellfires from the Apache It just took me a while to find all the files I needed to get 1.1.1 running--I was restoring from my weekly full system backups. So currently I cannot experiment with 1.2. When you release 1.2.1 I'll migrate over again and test everything. In 1.2, I did look at the hubs and channels at one point to see that the target directories were correct. It looked good to me, but I didn't actually look directly for errant file locations, which shouldn't be that difficult. Just take time. It may very well be that the mods were going to the wrong location, because I would find it hard to accept that a 'copy file' system call could fail and there be no indication of it. So copy to the wrong location would explain that completely. We'll see I guess, and if it doesn't rear its ugly head in 1.2.1, all the better, and less work for you

Okaaaaaaaay.... something has gone terribly wrong with my installation it seems. Everything looks like it works, but my modded files are not being copied into the target location and OMM says that they were. The log says all the to be modded files in my list are backed up and the mods applied, but when I check no mods have been put on place. The backups were made though. Log attached. Log_20231220_072357.txt Edit: I think I may have found the issue. The Presets are not working. At first when I double-clicked my standard preset, it seemed to be installing everything listed for it to install. The mods were checked off too. When I looked into the list, however, nothing was in it. I deleted the list, manually installed all the mods and tried to save the list, but it picked the wrong channel to save to, and will not let me pick the right channel. So I deleted the one channel--it only has one mod in it anyway--and created the list for the one remaining channel, but when I look into the list (properites - Installation Scripts) the To Install column is empty(!!). I select all the mods for the list, but cannot update the old list. Create a new list and give it the old name, hoping the old list will be replaced. New list added with the same name, old list with same name remains. Select old list, properties, try to rename old list: get a popup: Preset rename error Unable to rename Preset index out of bound Delete the new list, now both old and new gone - things getting better. New Preset created with new name - so far so good, Properties shows all selected mods in the To Install column OMM acts like implementing mods is working, but none of the modded files are landing under '..\DCS World OpenBeta', neither through the list nor through manually double-clicking the mod. Yes, OMM is 'run as administrator'.

Hi Draken! Since rkusa has the ability to use extensions in his code, is there any difference between the rkusa base installation and your branch--possible differences in extensions excluded?

Migrating was even easier than I expected. All the previous Hubs were still in the File -> Recent list so it went zip-zip and everything was back to normal The Manager Options pop up can order the pre-opened hubs now so I can pre-open all the relevant Hubs in the order I want to have them The only think I might ask is that the 'Always On Top' function might be an option. I'm not sure if I might want to turn it off yet, but it's just something I noticed. Event though the previous version was never anything I though of as slow, at all, now it is fast as lightning! So awesome! Thank you!! PS Just saw the Paypal thingy - nice mug of cold beer coming your way

What I have in my notes is this scene.m1:setArgument(443, 1.4); -- BORT 1st character scene.m1:setArgument(444, 0.5); -- BORT 2nd character scene.m1:setArgument(445, 1.5); -- BORT 3rd character This is for the P-51D, so the Hornet may be using different argument numbers. The "m1" references scene.m1 = sceneAPI:addModel("P-51D-25-NA", 15, 1.9, 6);

When you import a PDF with multiple pages into KBB it takes the name of the PDF and adds consecutive 3 or 4 digit number to the ending: eg My_Kneeboard_Pages.pdf (contains 3 pages) - output: My_Kneeboard_Pages-001.jpg My_Kneeboard_Pages-002.jpg My_Kneeboard_Pages-003.jpg. When you add they to a kneeboard, they get a prefix to keep the order of groups. Given Group: My_Kneeboard_Pages My_Kneeboard_Pages-001.jpg My_Kneeboard_Pages-002.jpg My_Kneeboard_Pages-003.jpg Group: More_Pages More_Pages-001.jpg More_Pages-002.jpg More_Pages-003.jpg More_Pages-004.jpg Added to you kneeboard folder of the aircraft in question: 0001-My_Kneeboard_Pages-001.jpg 0001-My_Kneeboard_Pages-002.jpg 0001-My_Kneeboard_Pages-003.jpg 0002-More_Pages-001.jpg 0002-More_Pages-002.jpg 0002-More_Pages-003.jpg 0002-More_Pages-004.jpg That's the whole magic. There is nothing stopping you from doing that manually, and if you have some nice tools like PDF24 Toolbox and Total Commander, it makes you life much easier to manage your kneeboard files.

Man, that first pass of the Corsair said loud and clear, "FU Japs, comin' thruuuuu...!"

I used to think I would need to swap pages often. I've found that I practically never have to. I have a set of reference pages I use for a specific aircraft, and I fly with those every time. I do have some pages I've downloaded with day and night version, so if I want the night version I just swap out the day and in the night version--so sad that you cannot switch between day and night pages within DCS, so if you go online and decide to join a mission at night, all you have to do is flip your kneeboard to night-version and everything is hunky-dory. I think about 90% of KBB is unnecessary. Take away resizing and repositioning the KB window, and modify the page implementation. Currently you import a set of pages, add them to a group and they are physically move to that group's folder. That is totally unnecessary. Import a set of pages and give them a logical name and numbering. They get stored in a repository folder, instead of a group folder. When you want to implement them, pick the pages and add them to a list. When you implement the list, the pages in the list will be picked from the repository, given index number for DCS to sort, and thrown into the KB folder of that aircraft. That's it. Easy-peasy... except for all the programming of course