moggel
-
Posts
381 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by moggel
-
-
I see exactly the same problem, and this is in the server log. Did you sort it?
-
I eventually figured it out. Turns out I had just made a mistake, and in part hadn't adjusted the NVG properly to see the strobe at a longer distance. Works fine now. Thanks for taking the time.
-
Does this still work? I tried the script and I get no errors but I also don't see any strobe effect in my NVG when I test it.
-
28 minutes ago, Exorcet said:
Have you tried AI Task Set to see if it is more reliable? Does the AI have any other tasks?
Task set will wipe out the AI's route, but it should also eliminate any other tasks that may be causing a conflict. You can pass a new route to the AI via script if necessary as well.
Yes, I have tested setting the task instead and I don't see any difference. Also, the AIs I'm testing with are super simple, with a "Nothing" main task, and no Advanced Waypoint Actions"; just a simple route with a few waypoints. I have tested with just one or two waypoints and with a bit longer routes that end with a landing. Sometimes it works, sometimes not. Oftentimes it does works fine but when I test it later, having made other - unrelated - changes to the miz, it stops working and I'm unable to figure out a pattern. It's like it's just cursed or something. Voodoo
I guess my questions are:
- Are more people seeing this (Follow task unreliable from scripting)?
- Might there be some dependency that can cause it to not have an effect, that I just haven't thought about?
-
I'm writing an "interceptor" Lua script, for air policing and such, and it works very inconsistently. What it does is it allows a pilot to fly up to an AI aircraft and perform an intercept signal (rock wings and/or flash external lights). This causes events that can be interacted with by the mission maker, but the default behavior is for the AI aircraft to "follow" the player aircraft. The script simply pushes a "Follow" task to the AI task stack.
This has turned out to work very inconsistently. I have had several situations where I've been testing it and it works. Then, suddenly, it just stops working. Pushing the task to the AI does nothing. There is o following at all. Nothing in the dcs.log.
I have not found any pattern to why this can suddenly stop working.
Does anyone have any ideas?
-
It seems the latest DCS update (February 22, 2024) caused an IC issue: /textures/su-27_detail @ c:/users/xyz/saved games/dcs.openbeta/mods/tech/vpc airfield equipment/textures/vpctextures.zip
-
Confirming this
-
I dug into the keybinding hypothesis and, yes, that's the problem. But what's weird is, it wasn't the Cougars. It was the Thrustmaster TQS, BTN60 default binding (QUIET). I guess QUIET activating FZ makes sense, in so far it prevents AGR from emitting, but I would've expected the OVRD to get triggered in that case, not FZ? Either way, mystery solved.
-
38 minutes ago, Lord Vader said:
Hello @moggel
I do indeed see what you mean and it does look like a bug.
However, when I tried that mission you shared or my own simple mission, that frozen radar issue doesn't occur.
This leads me to believe you have a assignment for that particular OSB button. Perhaps a stuck key? Can you confirm it's that?
I thought about that too, and the only binding is for my Cougar MFDs. I checked the "joystick properties" app and it does not indicate any of the buttons are active, unless I press them. I'll try disconnecting the Cougars just to be sure.
-
When in A-G mode, the AGR is in "FZ" mode and I cannot get out.
Repro:
- Caucasus
- Slot into first F-16C (air started, see miz for A-G loadout)
- Enabled A-G mode
Result:
AGR is in FZ mode. Clicking "FZ" OSB does nothing. Still in FZ mode. Have tried repairing. Also tried several different loadouts
-
Mystery has been solved. Turns out I had activated V-sync in the Varjo Base software and (apparently) not noticed the performance degradation at first so I didn't connect the dots. Duh!
-
1
-
-
Please advice. Last week I started getting crappy performance from my hardware and setting. In VR I'm used to seeing between 45-80 FPS. Suddenly, without any apparent reason (I hadn't changed any settings) I was looking at ~20-25 FPS, sometimes even sub 20.
As I started to troubleshoot I reset all DCS settings to "VR" (which acronym for "crappy settings to maximize performance; goodbye graphics - hello frame rates") and I was still looking at sub-30 FPS! I don't see anything obvious in the Nvidia control panel.
Hardware: i9 11900K, 64Gb DDR4, RTX 4090, Varjo Aero
Windows 11 Home Edition. Latest Nvidia drivers. I do not have MSI Afterburner installed
Tested so far:- Reset Nvidia control panel settings to default, then changed "Power management mode" to "Prefer maximum performance"
- Reset DCS settings to "VR" (really bad graphics quality)
- Tested Multi Thread and Single Thread (equally bad performance)
DCS is currently not playable
I'm stumped -
3 hours ago, BIGNEWY said:
Hi you will not be able to place a farp on top of a helipad as it is elevated.
Ok, unless I misunderstand something...
- Heli pads does not allow rearm/refuel without adding an iFARP
- iFARPS cannot be added to elevated platforms, such as those heli pads
... this means elevated heli pads cannot really be used as helicopter bases during operations (other than just nice looking places to start/land from), right? I can accept that, and work around it. Just looking for clarity.
-
1
-
I don't know if this is specific to the Syria map (and I couldn't find a forum to submit bug report for that particular map) but when I try placing invisible FARPs on several of the helicopter pads the ME pops a dialog informing me the terrain is too steep.
I don't have any insight into the map tech but should it even be necessary to put down invisible FARPs on heli pads?
(this particular heli pad is in YB16)
-
1 hour ago, Mike_Romeo said:
You should always share them when you do a bug report.
Done
-
[EDIT] Can a moderator move this report to AI Ground Bugs instead?
Before I take this any further, would just like to know if more mission designers are seeing the same thing. I scripted a ground battle, which sees an armored column move along a route, triggering events and logic as it reaches each waypoint. I have tested this multiple times and it works reliably in single player. When run by a server, in MP, I see this:
1. AI takes some very weird route. Instead of navigating along a road, as programmed, they start by heading off into the terrain
2. Waypoint logic gets triggered way way before the armored column is even close to themMap is Syria, DCS is 2.9.
Same miz behave extremely different in MP vs SP mode and I'm currently clueless as how to troubleshoot it.
Attached .trk and .mizSYR_A_few_good_men_M04_103_119_20-20231217-140932.trk SYR_A_few_good_men_M04_103_119_20.miz
-
Great post. I was attracted by the design of the training system and was pleased to find a group that was less about virtual 'rank' and command, and more about making use of every individual's ability and ambition. If you like a challenge and want to push yourself in the digital skies regardless of airframe or role, don't hesitate to apply!
-
1
-
-
After 2.9 release I very often find it's very difficult to designate an emitter on the HAD page. What happens is usually (with TGP active on other MFD):
- I move HAD cursor over emitter and go TMS UP
- The emitter gets momentarily highlighted (inverse block) but immediately undesignates. The TGP momentarily slaves to corresponding location
It usually takes > 10 attempts before I get a solid designation
Is this as intended? One assumption was that maybe the triangulation constantly updated and that made it loose the lock, but I don't really see the emitter number move at all when this happens (and it's PGM2, not getting any lower unless I also use TDOA - which I didn't)
-
1
-
3 hours ago, ChillNG said:
Thanks, that's great to hear, glad you're enjoying. That's probably the most likely cause, I saw this happen once in Persian Freedom - it's rare but it can happen. Unfortunately it's not something that can really be accounted for, as the mission builder has no way of detecting if the radio is not functional, and so can't program in contingencies for this.
I'm curious, though. I assumed the radio traffic was simply audio files being played from triggers, but you're saying the audio actually gets channeled through the simulated radios then?
I forgot to mention: I also did not get a reply from the tanker (I think it was Texaco), and its TACAN was not picked up by my receiver either. Maybe also due to battle damage. However, as I reported inbound I did get arrival's audio again, and later tower. -
Really like the campaign so far. Just wanted to report that during msn 2 I lost incoming radio calls. could operate the F10 radios and initiate calls to my wingman, and awacs, but I never heard their reply - just "Dan's" responses to whatever they said.
I had taken a AAA hit by then, that made me loose all my pods, so maybe radio wasn't working or something? If the radio logic does check for loss of radio then I guess Dan's outgoing messages should also reflect this? -
Me and @Moonshine did some testing and found that:
- Airborne TACANs now seem limited to about 40nm (might be realistic)
- Fixed TACANs are now very weak. We picked up the the DAN tacan (Syria, 21X) at abour 12-13nm and Kuboleti (Caucaus, 67X) at about 22-23nm. We flew high so LOS shouldn't have been a thing
-
2
-
I got my TQS today and was able to mount it to the Monstertech clamp without any problems. I could only fit two screws at the back, which seems to be sufficient, but if I want it even more firmly attached I would need to either drill two more holes in the Monstertech plate, or come up with some other solution. Doesn't seem to be necessary though.
-
So, I've done quite a lot of scripting to allow control of tankers (can be used to set up AAR tracks, and tankers can be assigned to them, and then reassigned to different tracks, RTB and so on). When my script sets up tankers, with different callsigns, it also automatically assigns the TACAN channel, mode and its identifier. For example, SHELL 1 ident is "SHA", SHELL 2 is "SHB", and so on.
This works just fine, and has been working fine for a year now. But today I noticed if I load and run a mission on a MP server, the ident isn't showing in the aircraft. Instead it's just some dots. In SP mode I do see the ident as expected though.Single Player:
Multiplayer:
Could this be some new MP bug?
-
I used this post some weeks ago to understand how to allow running Sinai-based missions on one of our servers. Worked fine.
I tried it again today and now, when I add Sinai-missions to server's list, they are grayed out again. Map is installed under server's Mods/terrain folder. I even went ahead and remove/reinstalled the Sinai map, but the miz is still grayed out.
Has anyone seen this/have suggestions for troubleshooting?
-
1
-
Mission Mods Not Visible on Dedicated Server
in DCS Modding
Posted · Edited by moggel
We ended up figuring it out. I was guiding a bunch of guys who had recently started playing DCS and set up a server for it. As such, the M92 mod was installed incorrectly into the "mods/tech" folder in the server's install folder structure (where only 'official' mods are allowed). I told him to move he mod to the community mods/tech folder instead (under the "Saved Games" structure) and he confirmed he'd done it. I double checked and they were there, but the units still didn't show up in game. I checked the logs and saw a few lines that indicated something still wasn't right:
I then asked the guys to check whether the mods where now in two locations, and it turned out they were. So, instead of moving the mods they had just copied them, so those community mods where still in the 'official' mods folder, which is why DCS blocked them as "not authorized". Once they had removed the duplicates from the official mods folder structure, it worked fine.