Captain Orso

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

I do it manually. I use OpenOffice Calc or Writer or whatever fits my needs using A4 page format to create the kneeboard pages I want. I export the document to PDF format and then use PDF24 Toolbox--freeware--to create one JPG per page of the PDF (open PDF -> convert to JPEG -> Output). https://tools.pdf24.org/en/ Use file names which sort alphanumerically so that in-cockpit they are in the order I want. Put the JPGs into 'C:\Users\user_name\Saved Games\DCS.openbeta\Kneeboard\aircraft' and away you go. I believe every module you can fly that you have installed has a folder in 'C:\Users\user_name\Saved Games\DCS.openbeta\Kneeboard\aircraft'.

Since it seems nothing is working as it ought to, I would say you are doing everything wrong. I'm sure, if you know what you are doing, you can use OvGME to implement the mod, but the fact that you are using OvGME to implement this into '..\Saved Games\DCS.openbeta' makes me question whether you actually do know what you are doing. Follow the instructions and copy the downloaded '..\Scripts' folder into '..\Saved Games\DCS.openbeta'. Done. When you say, you are "walking around" the map, are you talking about the 3D view or F10? You do not click the LMB to "anchor"--whatever that is supposed to mean--the F10 map--the one you should be using with Scratchpad. In the F10 map, you press and hold LMB to drag the map to the position you require--the scroll wheel allows you to zoom-in and -out. With the Scratchpad window open, click on the empty check-box to the right of the <-- --> arrows to place the center-dot at the center of your display and add the +L/L button to the right of that. The white dot is what is used to tell Scratchpad what coordinates you wish to record. Where ever the dot is when you click +L/L determines the coordinates recorded. Zooming in as far as possible onto a position and putting the white dot directly over the point to record will give the most accurate results. If you are using Draken35's download, follow the readme instructions to implement any required extensions, and follow the instructions to use them.

CTLD was only a ready example to illustrate what I'm actually trying to achieve. I'm actually trying to find a way to use the rangescript.lua (https://github.com/ciribob/DCS-SimpleRangeScript) without editing it to implement the setting I want. I'm still trying to find a away to test changing variables, but it seems that the script used the same variable name (same variable??) in two different functions, setting the variable each time, so probably my efforts are for naught *frown* I want to set maxAlt, minAlt, and range.bombingMinAlt from within the mission.

Two and a half years later and I see that I never reported that I had discovered what the issue that I was having was *sigh* Management Summery The Strafe Pit area definition through following the plotted path of a 'Late Activation' vehicle somehow got pulled apart. Per definition the first leg of the path and the last leg must cross, thus forming an enclosed area, which is the Strafe Zone. In my mission the start of the first and end of the last legs were very close to the crossing. The mission had been modified many, many times and somewhere along the way, for whatever reason the crossing of the first and last legs became uncrossed No crossing, no enclosed area, no strafe zone definition, no rangescript function. I then made the crossing very distinct, with the first and last legs clearly crossing and the start and endpoints far enough apport that even a Japanese earthquake won't uncross them again. One simple thing I might suggest would be, instead of this difficult to use vehicle path to create an enclosed area, simply use the now for functional trigger zones. A Quad-point trigger zone would be perfectly function and easy to create in the ME and easy to reference within the script - easy-peasy.

I know I saw it somewhere and I can't remember where and I can't find it, but.... How do you set a script's variables from within the running mission? For example the ctld.lua has ctld.Trace = false a variable set with the default value 'false'. There is some why to change 'ctld.Trace' to another value, like 'true' through a trigger within a mission which has loaded the script, something like under TRIGGER - - ACTIONS DO SCRIPT 'ctld.Trace = true' but that is not the correct format for the command. Anyone know how to do this? Thank you

Sexy French voice says: Monsieur, are you looking at my... back side? FEMALE!! Sexy female voice....

I know I saw it somewhere and I can't remember where and I can't find it, but.... How do you set a script's variables from within the mission? For example the ctld.lua has ctld.Trace = false a variable set with the default value 'false'. There is some why to change 'ctld.Trace' to another value, like 'true' through a trigger within a mission which has loaded the script, something like under TRIGGER - - ACTIONS DO SCRIPT 'ctld.Trace = true' but that is not the correct format for the command. Anyone know how to do this?

The map is really beautiful and the land itself is simply fascinating. Flying missions here is fun. While building them, you just have to remember, January is summer and July is winter or else the days are very short and dark lol.