Zyll

Obviously a very minor thing, but a little peeve for me anyways. Since I've had the Apache, I've always wondered about these scratches, either they represent green paint under the black paint of the cockpit panels (and are intentional), or I'm missing a very minor texture somewhere. Just wondering if anyone else has seen this? null

Let me play with that a bit. I want to still see errors and informational messages that help mission makers troubleshoot their scripts, I just don't want to see all the other stuff that is being obsessively logged. Thx Gater. Zyll @ TAW

turns out I could have just made my life a whole lot easier with this simple line in a mission script (assuming sanitization is turned off): lfs.writedir() I can determine the server with this since the path will be specific to the folder under Saved Games that it was installed. alternatively this worked just fine too: dofile(lfs.writedir() .. "Config\\serverSettings.lua") grab any server setting from this file

If you launch a mission (no scripts) in single player, you will not notice any logged events in dcs.log, unless you explicitly request them via scripting. That's good. However, if on your local game you launch the same mission as a multiplayer server, or you put the mission (no scripting) on a dedicated server, then your logs fill with messages like these: 2024-05-31 15:57:28.565 INFO Scripting (Main): event:type=mission start,event_id=1,t=0,linked_event_id=0,ta=28800, 2024-05-31 15:57:28.565 INFO Scripting (Main): event:linked_event_id=0,t=0,event_id=2,type=took control, 2024-05-31 15:58:14.783 INFO Scripting (Main): event:type=engine startup,initiatorPilotName=TAW_Zyll,place=Kobuleti,t=42.808,placeDisplayName=Kobuleti,initiator_unit_type=UH-1H,initiator_object_id=16777729,linked_event_id=0,event_id=8,initiator_coalition=2,initiator_ws_type1=1,initiatorMissionID=2, 2024-05-31 15:58:14.792 INFO Scripting (Main): event:initiator_unit_type=UH-1H,type=under control,initiator_object_id=16777729,targetMissionID=2,target=Rotary-1-2,t=42.808,initiatorPilotName=TAW_Zyll,initiator_coalition=2, take a Huey door gunner firing into a group, and you can imagine the logs just get filled with unnecessary messages, which can hinder performance. If there is a server configuration to remove these event logs, I'd love to know it. If anyone is not seeing these messages running as a server (local install or dedicated), I'd like to compare notes. Can something like the above be used to REDUCE the amount of logging? What I don't want to do is eliminate mission makers' ability to actually log events to troubleshoot their scripts, but I don't want events to fill the logs when I didn't ask for them thanks,

Io.open would require a full path to the file on the file system, so I think your idea would work only if your different servers were on separate physical servers. If you had 2 dedicated servers separated by folders under Saved Games, I'm not sure you would be able to make it work. Certainly interested to know if you make something work, else check out that link that Tempest posted, it definitely worked for me. Zyll @ TAW

you could use a conditional trigger and use a flag counter that increments to 10 or a 'time since flag' condition to exits the loop. That's the easiest way I can see doing it in the ME without a lick of lua scripting

holy crap it actually worked. Thank you guys. This is my server script: /Scripts/Hooks/set_server_id.lua: local ssi = {} function ssi.onSimulationStart() local status = net.dostring_in("server", "return trigger.action.setUserFlag('server_id', 99); ") log.write("[set_server_id]", log.INFO, "server_id flag set") end DCS.setUserCallbacks(ssi) this is what's being run inside the miz to validate it sees the flag: env.info("server_id:" .. trigger.misc.getUserFlag("server_id")) this now opens the door to fancier stuff (or maybe not, because 100 DCS restarts later, I'm kinda done testing this thing now, lol)

Hmm, so what @cfrag responded with here using flags didn't work for you in the end? Zyll @ TAW

hey guys, I'm only just diving into server hooks here, so please bear with me as I struggle here. As I understand it, I should be able to create a Scripts/Hooks/set_server_id.lua file, which has these contents: local status = net.dostring_in("server", "return trigger.action.setUserFlag('server_id', 99); ") log.write("[ZYLL SCRIPTING]", log.WARNING, "started") and then in a mission trigger, I just wait 3 seconds and then try to output the value of the server_id flag: env.info("server_id:" .. trigger.misc.getUserFlag("server_id")) It shouldn't be any easier than this, but the server_id flag value is always 0, implying that the mission is not able to see the flag that was set in the hook script. The hook script is running with no errors, as evidenced by the log message being written successfully. I've tried different variations of escaping the string "server_id" but no matter what I do, I don't see the flag from the mission. Can you please enlighten me? thanks!

Good recommendation, I have seen other colleagues using this tool. For those who already use Notepad++, it also has 'tail' capability, as well as keyword highlighting which you can setup in the preferences. What I do is have a windows shortcut that launches DCS.log in tail mode within Notepad++. Just another option for folks out there. Zyll @ TAW

Some context on exactly what I'm trying to do: We have 5 dedicated servers (all same IP, different ports), and have SRS running too, one instance per dedicated server. I am trying to have a mission be aware of which instance they are on, so I can dynamically set the SRS port configured in the script for Text-to-Speech support. You don't need to understand how SRS TTS works or anything, the simple ask is whether I can pull ANY server info from within my mission script (which happens to run as DO SCRIPT as opposed to DO SCRIPT FILE if that matters). A getter to retrieve the server name, IP/port, description, even local file system folder where the miz is located... any of these would suffice for my purposes. Our servers have sanitization turned off. I did ask this in another thread a while back but didn't get anywhere at the time, hoping there might be some new(er) insight. Thanks all,

You can confirm if the jtac is lasing by turning on your NVGs and look for the sparkle. Zyll @ TAW

During your comms with jtac via F10 menu, are you indicating 'in' and have you requested 'laser on'? Zyll @ TAW

Oh that IS weird. It makes sense that the Moose version could be out of sync, but for the file in the ED folder to be off, that's crappy. Zyll @ TAW

You can reference the DCS.lua that comes with Moose: https://github.com/FlightControl-Master/MOOSE/blob/master/Moose Development/Moose/DCS.lua

Most likely (this has been my experience anyways) your sight is currently FCR because you as the pilot switched to it and so as Floyd states, you need to take the additional step before guns will follow your head. Zyll @ TAW

if you edit the database though, then you have locked yourself into a custom version of Massun's v3.0. If you edit the mission files in your miz's, at least you have a better chance of being upwards compatible to the next version, whenever that comes out. Of course, having over 100 affected missions certainly puts you in a rather unique situation. Unless there's something you really want from v3.0, if I were you, I would consider just waiting to see what comes out from the next Massun's before changing anything.

Was it the length of the names of the units that cause the crashes, or special characters? In just trying to understand so that I can pinpoint potential causes of similar crashes across other mods. Zyll @ TAW

Can you elaborate on that? Was the names of the units in the old asset pack causing DCS crashes while flying, or in the mission editor, or both? Zyll @ TAW

did you ever get anywhere with this issue streakeagle? We had a mission tonight where we saw alot of these errors, and the symptoms were rubber banding, AI blinking in and out of existence, and a generally terrible experience for ~40 pilots in our mission. Interestingly, it seemed when the RPC.lua errors went away was when things started to look better in the game. Does anyone know what these errors may be a symptom of? 2024-03-18 01:08:18.968 INFO ASYNCNET (Main): Current ping: 151.1ms 2024-03-18 01:08:48.840 ERROR LuaHooks (Main): [string ".\Scripts\RPC.lua"]:53: bad argument #2 to 'format' (string expected, got nil) 2024-03-18 01:08:48.840 ERROR LuaGUI (Main): [string "./Scripts/RPC.lua"]:53: bad argument #2 to 'format' (string expected, got nil) 2024-03-18 01:08:48.971 INFO ASYNCNET (Main): Current ping: 70.2ms

This is horrifying! Zyll @ TAW

Are you high (altitude) or hot? The Apache does have challenges starting under extreme conditions. If so, I have a video on this: Zyll @ TAW

Is it maybe treating \t as an escape character? Maybe try using / in your file path instead? Zyll @ TAW

> Terrain scenery performance: optimized instancing and improved and optimized streaming. Anecdotally, I've heard that performance is better for folks after this latest patch. Maybe the benefit of this mod is reduced or (gasp) rendered unnecessary now? Anyone done any comparisons since this patch? Zyll @ TAW

It's been moved from the Mission Editor, and is now on the rearm screen for individual crew to manage, rather than the mission maker. Zyll @ TAW