nighteyes2017

So i received mine today, and it took some steps to get it to work properly. At first i thought to install the simshaker software, but couldnt get it to work. While troubleshooting, i stumbled on this vid: Now that still didnt solve the problem for me. However, then i did two things at the same time, so i don't know wich of these actually made it work in the end. 1) I installed a loopback network adapter (google how to do this, its easy) 2) I de-installed the simshaker software, and manually went to the scripts folder in my savedgames/dcs folder en removed the simshaker scripts, as well as the lines in the export.lua that refer to the simshaker script. Also, i noticed that either the hf8 software, or the simshaker software, had made a backup copy of the export.lua and replaced it with their own. So i copied the single line that referred to the hf8 software, en put it in the backup export. Then removed the export.lua file and then renamed the backup file back to 'export.lua', thus restoring the original file, but now with the hf8 extra line. after these steps, it suddenly started to work hope this help you out.

Tested in multiplayer. When using a 'sound to unit' action, the entire group that unit belongs to is hearing the sound as well.

Yeah ok, seems to be working. trick is how the flag was set from the mission editor. When using flag on/off, the value is a 1 or 0. when you use an if statement to test the value, you should use a integer or boolean value to test for it, and not the string value. setting flag random value (max 100) works too. userflag test.miz

Well, i got it to work a moment ago. then changed something, and now it isn't working again....interresting. working on it....

yes i understood that you were trying to GET the flag and not set it. So i'm trying it now. Seeing the same problem. Setting from script and picking it up in the mission editor triggers works fine, just not the other way around. setting true and testing for 1 is the same thing btw.

Last week i used this function the other way around. Setting a userflag from the script and then using that for a trigger in the mission editor: trigger.action.setUserFlag( FlagName, true ) the created a trigger that displayed a message based on that flag. So definitely interaction between scriptflags and mission editor flags. I haven't tried it the other way around yet though, but should work just fine unless there is a bug there. will test it now.

Just came back from a mission with an ILS landing on al dhafra 5 minutes ago. No they are not fixed. freq 111.1 is the ILS for 13 and not for the 31.

agreed with all of the above. datalink settings is not streamlined yet for mission makers.

following the entire discussion along so far, it looks like most of the confusion is around the vis mode and the delta that designating introduces. undesignating puts the spi back on the FPM but does not reset the delta. Like the others, this at first, does did not make sense to me. Why would you move an important reference in the hud in vis mode, and not make it reset? However, as Lord Vader has said, this seems to be real life implementation. So i have been asking myself: why would they design it like this in real life? Then i remembered a handy feature from the harrier that looks a lot like this. Its been some time since i flew the harrier, but i seem to remember it also has a visual marker that is placed at the point where you threw your last bomb. So when you come around for another pass, and are looking for the target area, you have a reference of where that was. Remember, we are talking about visual mode here, wich probably means we are also talking about a target of oppertunity, and not a pre planned target with a steerpoint on top of it, but rather something that doesnt have a reference point at all. So, following those circumstances, if we designate visually at a target location, wich is away from the steerpoint where we started, and we fire a weapon at it, we now have a marker were that was. And then when we come around, we have a reference point. tms down in that case, shouldn't reset the delta, because you would want to keep that reference until you are done launching your next weapon. This is the only reason i could come up with so far as to why the real life designers would implement it like this. It still may be a bug, but looking the logic from the perspective of a target of oppertunity, this makes some sense at least.

So following along so far, i decided to test this myself. So designating in vis mode introduces an offset for steerpoints. What i also noticed that designating in vis mode, is that on the ground radar, wich is not SOI at that moment, a cursor zero appears, which wasn't there before designation. Pressing this, does not negate the offset, but does the same as pressing tms down, reattaching the cursor to the FPM. So the cursor zero appearing and doing nothing in itself looks to me like weird behaviour. Furthermore, returning to NAV mode, the offset to steerpoints stays. So clearly NAV mode does not seem to have a different offset than maverick vis mode. Pressing cursor zero in NAV mode does negate the offset. So as a workaround this works for now. I cannot understand why you would want a offset to be introduced in vis mode in the first place. If your target is located around your steerpoint, and you designate, and then lose your target, how would find the target area again??? by designating you just introduced an offset with the first designation. So in order to reacquire the original point you would have to back out to another mode, CZ, and the re-engage? So looking at all that, if the CZ that appears after designating in vis mode, would actually reset the offset (deltas), than it would solve our perceived problem.

yes, found it. it wasn't under the ins procedure though, but was under cockpit orientation. Must have missed it.

Kudos on the details of the INS in that case. It maybe a good idea then also to mention this in the manual that any movement on the aircraft interferes with the alignment.

Couldn't find if this has been reported, and cant really imagine that this is normal behavior. So during INS alignment, taxi of the aircraft stops the alignment. Normal off course. But wiggling of the aircraft isn't changing the actual GPS position is it? So when bombs get loaded, or if wake from aircraft taking off passes by, it wiggles the aircraft, and alignment stops. Should it? I cant imagine that it really should. I mean, off course there is some gyro involved. And it could be that the shaking hinders the alignment, but I'm guessing that a lot of people are out there wandering why their alignment got screwed up again, even when they did everything exactly the same as last time. Bug? or feature? ins wake test.trk ins rearm test.trk

Nederlands squadron met meer dan 20 jaar ervaring in het vliegen van de F16, in missies met meerdere flights. vliegen met grote packages. formaties. samenwerking tussen meerdere flights. strategie en tactieken m.b.t. wapen gebruik in teamverband. Air to Air tactics. radio comms. werken met Jtac en awacs (human). etc. We hanteren onze eigen squadron SOP's en hebben ons eigen trainingsprogramma. We hebben onze eigen open server die toegankelijk is voor iedereen, waarbij we mensen op weg proberen te helpen. Intern in het squadron vliegen we de zwaardere missies waar je wat meer voor moet kunnen. discord alleen Nederlandstalig. https://discord.gg/EZWWgUTTkg

Yes i use this in VR just fine. There is a 'hack' of sorts though: I use this mod for that: I dont actually use any shader adjustments at all in this mod. The only reason i use it is the scratchpad in VR for copy pasting coordinates. Before i used 'the way' i was using this for coordinates in VR. Now this mod has another small benefit. It puts a small white dot in the center of the map when you check the checkbox under the scratchpad. And that is what you need. Center the dot on the map where you want it. Make sure you have shortcut keys set for 'the way', as described in the github readme.ctr shift s, ctr shift t, cts shift d. now, using the dot from the first mod, you can use 'the way' to setup multiple points acurrately with the shortcuts, and then transfer them to the cockpit.

reverb g2. not running mt. yep same problem here. went from a 1 minute load to about 3 minute load. Also, exiting dcs takes a lot longer now too. annoying as hell.

this looks a little too unnatural. its here:

Are these shelters at el gora supposed to be destroyed? or is this just the wrong model?

by that logic, what use is the auto rename? cant imagine its hard to fix this.

Ok so my mission freezes at a certain moment and i spend about a week trying to solve why. I finally managed to make it reproducable. Since DCS freezes totally and does not crash on its own, i cannot save a track file, nor do i have a crash log. I do have a normal dcs.log however that shows the same error on every freeze. I included the mission file so you can try yourself. The problem occurs when a helicopter dies hauling cargo over sea. When it is shot down, crashes or dies in any way, the cargo sometimes survives. It is then underneath the surface still moving very erractically wich is visible on the F10 map view, until, after 45 to 90 seconds it shoots/flies completely of the map. At that time, the dcs.log shows 1 of 2 errors: APP (Main): INFINIT or/and FMBASE (Main): invalid double at that time DCS freezes. but only if you are occupying a jet at the time. If you are in a gamemaster or on map view, the sim goes on. So i made a mission file to show this strange freeze: The mission has 2 mi26's. picking up cargo and then starting to transport it to another island. Wait till they pick up the cargo and fly overseas. it takes approx 2,5 mins for them to do that. normally, for testing, you would use time accell here, but logs show this uses some sort of antifreeze??. in multiplayer or missions, you wouldnt use this, and it affects what i'm trying to show here by not freezing. so use real time. use F10 menu to kill either one or both the mi26's. It takes about a minute or so for the surviving cargo to fly of the map, at wich time the logs show the error and DCS freezes. (use log viewer) If not, restart the mission. As i said, it happens when the cargo survives wich is 80 percent of the time. So you shouldnt have to try too hard to see the freeze. you can also observe the F10 map view, and watch the strange cargo behaviour. it will move around a bit and then suddenly accelerate off the map. however if you view the map, DCS wont freeze. it freeze when you do the entire process from the cockpit view. wich is where you would be in a mission or multiplayer. so to see the freeze you need to be flying the f16 in the mission. just set it to autopilot and let it fly circles. freeze dcs.log Island Wars 2 single 26 only .miz

So for instance, i created a group wich is automatically called aerial 1. I set everything i want for that group and rename the group to Players-1. Then i add 3 wingmen and end up with: Groupname: Players-1 unit1: Aerial-1-1 unit2: Players-1-1 unit3: Players-1-2 unit4: Players-1-3 Now if i press rename i should end up with Groupname: Players-1 unit1: Players-1-1 unit2: Players-1-2 unit3: Players-1-3 unit4: Players-1-4 But it wont allow that because the new names conflict with existing names that the group has now, eventhough after the renaming action it would not.

Awesome work in the saluting crewchief.!! Very nice work. Really adds to the immersion. I am having trouble getting the script to work in multiplayer. Here's whats happening. empty mission, 2 F16 set to client on the ramp hot start. Trigger1 loads the latest version of moose. Trigger 2 loads the salute script after 2 seconds. Crewchief with proper name set to late activation. The crewchief spawns next to me, but not at the second remote player. The logs show an error. It seems that the "local unitClient = _client:GetClientGroupUnit()" returns nil on the second client. so we tested a second time, with me as server staying in the observers position, and letting the other remote guy take a seat alone. Then the script works for him too, but not if we both take a seat in an F16. Any ideas? Did something break? ---------------- EDIT: update! The script works if the second player is not in the same group as the server. I'm guessing its either a moose or a DCS scripting thing.

and how about the infinite flares? i have a tacview that shows a mig21 throwing around a 1000 flares continuously.

Just noticed this during a mission yesterday. When loaded with a targeting pod, but no ground stores, its not possible to make a markpoint based on the TGP in AG mode. I suspect its got something to do with not being able to switch away from ccip mode, since that button won't do anything if you don't have any ground stores. Normally you can switch to CCRP when carrying bombs, but without ground stores, it does nothing. Also, switching to gun didn't solve it either So, loadup TGP, go to AG mode, make TGP SOI, setup TGP on a target, press 7 on the icp. Use seq to select TGP if needed -> TGP is not an option. As a workaround: Doing the same thing entirely from NAV mode does work. no tgp mark.trk

We are simulating an F16. So why aren't we simulating the pilot? Real F16 pilots need to be able to maintain a 15 second 9g turn in the centrifuge without help of the G-suit. So why does the DCS virtual pilot start blacking out after a few second of 8g? (while wearing a virtual g suit) Dont tell me its sudden onset of G's. In the centrifuge it goes from 1 to 9 in less than a second.