nighteyes2017

213885 with max 2021 works for me so far. however self illumination and transparent illumination dont work anymore. I can get some illumination by using the default material and setting a texture to the self-illumination, however its not the same by far. The edm illumination materials had a nice 'glow' around it and were much much brighter. anyone know a workaround or have another version that works?

So i made this Huge hangar for my squadron. everyone has their own parking space and it can house up to 36 F16's. roughmets, lights, collisionboxes all seem to working fine. They only thing thats not working is placing statics inside the hanger, because they fall through the floor. I made a collision box underneath the slightly elevated floor to get rid of the grass poking through. When placing normal playable units on it, they stay on the floor just fine. I also placed a ramp outside and i can drive units on the ramp and on the hangar floor. However, static units fall through the floor. I'm guessing a bit here but i thing maybe the statics f16's are placed first before the hangar does?? Anyone know how to solve this?

in addition. adjustable font would be a good idea. its very easy to miss a ' or a (. as a workaround i use a regular LUA editor and then copy paste it. As most of us do i recon. Comes with added perks of syntax highligting and intellisense

In the DCS controls settings, we can enter a search for a particular function. Can this be added as well to the ME? it would make finding a certain static object or ground vehicle much easier to find when wanting to place an new object.

I tried the same thing. Complete clean reinstall of the entire game. didnt enable mods, didnt even copy back my savedgames/dcs folder. as clean as i could make it. unfortunately, it didnt make any differences in framerates at all. I got the exact same slow results back.

from what im reading. the automatic clearing of the fxo and metashaders folder when updating is broken. Manually clearing them solved the slow loading for me.

Flying in persian gulf, this new effect i'm seeing is very annoying. When turning my head, i can see the world itself around me dimming in brightness levels. Like i said in the title, is like a live brightness knob. It feels very unnatural. When looking at some mountains at 2 o'clock, i can see the mountains dimming in brightness while turning my head to the right.

Mission 13: i missed out on aux comms because the kneeboard frequencies and channels do not match up with what is preprogrammed in the radio for tactical channel on aux. target elevation for steerpoint 2 is way up in the air instead of on the island.

Yes you read the title right. intraflight datalink in the f16 on the persian gulf is clock time dependant. The bug is reliably reproducable, and is visible using hotstarts. so no 'you forgot to enter coordinates or mids' or anything like that. We didnt test it yet in other theaters, so i dont know if this is a F16,theater,or general bug. Basically the fault is this: Persian gulf mission time and F16 ded time are 4 hours apart. between 0:00 and 04:00 mission time, or between 20:00 and 0:00 F16 ded time, intraflight datalink does not work for server and clients. (AI datalink and intraflight AI remains visible) When a client connects to the server, at first the server F16 will have datalink on the client joining in because the client is busy spawning in. But after the first datalink update (around 12 secs) the datalink dissappears and stays gone. The client, on joining, never sees the datalink at all. So we tested several things: Setting mission time at 23:59 (19:59 in ded), and then waiting in pit, the datalink works. Even after the mission passes 0:00 (20:00 in ded). The intraflight datalink stays up. Setting mission time one minute later at 0:00 (20:00 in ded), intraflight datalink does not work. as mentioned, on a joining client, the server sees a momentary link, wich dissappears after the first update round. Now the other end of the timeslot: Setting the mission time at 03:59 (23:59 in ded). The intraflight datalink does not work, BUT, when passing the magic mission time of 04:00 (0:00 in ded), after 12 secs, the datalink suddenly starts working!!. Setting the mission time past 04:00 (0:00 in ded), intraflight datalink works just fine from the go. We didnt have time to test this on other maps i have included three mission files with mission time settings 23:59, 00:00 and 3:59. But basically, its just a 2ship F16 mission set on hotstart with both set to client. Nothing else is in the mission file. What stands out off course, is that the time slot where intraflight datalink is not working is between 0:00 mission time and 0:00 ded time. This may be coincidence, but it is curious. PG mplay intraflight datalink missiontime 0000.miz PG mplay intraflight datalink missiontime 0359.miz PG mplay intraflight datalink missiontime 2359.miz

This is a copy of the post i did here: That post can be deleted because i should have posted it here. -------------------------------------------------- Since 2 or 3 updates ago, i noticed a really annoying problem in de ME. Sometimes, when i try to pick up a unit or zone with left mouse button hold, the unit or zone suddenly jumps away from under my cursor. I am at that moment still holding it, but it is suddenly offset from the mouse cursor. I decided to investigate and have managed to find out how to reliably reproduce the effect. Here are the steps: 1) Create a small zone, say 150 feet radius 2) select the zone and press ctrl-C (copy) 3) offset the mouse from the original zone and press ctrl-v (paste) 4) deselect the copied zone. 5) reselect the copied zone and press delete 6) the original zone gets selected. 7) press and hold left mousebutton to try and drag the original zone. The zone jumps from under the cursor. It is still attached, but with an offset. made a small video to show the bug: So are other people seeing this as well? I did a reinstall and the problem remained, so i decided to post this.

after searching for a long time, i couldnt find anything about this. so i posted something myself. then, 3minutes later, i found this topic. i seem to have the same problem. for me, the problem sticks untill restart, except when flying the f18, then it clears up after about 30 secs.

what plane do you fly? because for me, it only clears up when flying the f18. All other planes the problem sticks until restart.

Whether im flying in VR or in 2d, i sometimes have the problem that at the start of the mission, the screen suddenly is a LOT darker than normal. If i then restart the same mission, everything is fine again (see screens, same mission, taken at the start). Reloading the mission seems to solve it. I also noticed that, when flying the f18, the problem seems to fix itself after about 30 seconds, but only in the f18 so far. I cannot find how to force the problem. It just randomly happens. Tried clean install, clearing shaders, different drivers (nvidia), but nothing seems to solve the problem. anyone seen this before? i can't find anyone else with this sort of problem anywhere. happens at any point in mission time. so not related to sunrise sunset times.

On mission 1, was told by the tower to fly the pattern (runway heading, 2000ft). I then already heard the audio for when landed and ordered to switch to ground freq, while i was still in the air. Guessing i flew through a trigger zone. I was at that point a little lower, around 1500ft.

I cant find it, but i seem to recall this was reported earlier, and i also seem to recall it was already fixed? If not this may be a double report. Anyway, on selection the jdam, the alignment starts running. On completion, deselecting and reselecting the jdam restarts the alignment again. jdam alignment.trk

No. Thats not it. The tgp always hands off to the maverick when the maverick is capable of receiving a handoff. It is about the lock that comes after the handoff. The man/auto does not handle whether or not the tgp does a handoff. It is about the lock that is needed after the handoff. Handoff does not mean lock. Watch the vid.

Yep, that states exactly what i said. The manually talks about the lock itself. Handoff is not locking the maverick. So i see the confusion here. Handoff and locking are 2 seperate things.

As far as i inderstood it. The manual/auto mode does not mean handoff mode on or off. Rather it determines if the maverick tries to lock on manually or automatically. Meaning you do not have to switch soi to the maverick and lock on. With auto it will try (If close enough) and do that on its own. Mind you, not all mavericks have the auto lock capability. So it has to be the right type.

Maybe related. When dropping from a station with more than one bomb, you have to manually select the other too when dropping the second bomb from that station. When you drop the first one from too1, you have to manually switch to too2 before dropping the second one. Dont know if this should work like that or not. Seems a bit weird if you want to drop 8 jdams at once. You then have to press too2 manually 4 timles to drop bombs 5/8.

That all may be, but that was not what the op asked for.

why not check the units speed? unit speed higher than condition.

Though they are not made anymore, the best for the last 20 years has been the thrustmaster cougar HOTAS. It is a metal made, heavy, exact replica of the F16 stick. You can still get them second hand. The overall quality of these are still unmatched . Wich is why, after 20 years, they are still around. The feel of this HOTAS is just spot on. The stick is standard not force controlled. However there are several options to convert them to force sensing. Many of them already are. there is a whole site dedicated to this HOTAS set: http://www.cougar.flyfoxy.com/ The software and configuration options this thing has is unrivalled. It requires some more effort to program, but even today, the software has more configuration options than any other stick. I'm still baffled that they stopped making these, and still more baffled that they havent started producing them again with the coming of the F16 in DCS.

accidentally posted this in the main thread instead of here: can it be moved over here and then delete this one?

came across something weird here. As far as i know, when using the radar cursors on the ground radar, the TGP should be following the radar cursors shouldn't they? (as long as the radar isnt in area or point mode of course) However, if i move the ground radar cursors, the TGP just stays put. But if i then switch the SOI to the TGP, and start moving that, the radar cursors on the ground radar DO follow the TGP. Shouldnt this be happening both ways anymore? track and used mission file attached. (edit: just saw i posted this in the wrong thread, should be in bug reports, can this be moved there?) SPI and TGP.trk SPI and TGP.miz

yes absolutely. This has been bothering me for a long time now. Can't imagine that this would be too hard to implement? Quick win.