Closed BigBoss329 closed 2 years ago
Hi,
I had this issue for a while a few week ago, and it eventually stopped happening without any reason.
I suspected it was linked to liberation at some point (and it might be), but units placed in a new custom mission would be glowing as well for me... So I just assumed it was a DCS bug;
So I'm really unsure about the reason why this is happening..
I'll try to find if other people have this issue as well.
Khopa
Hello!
This is rather strange. I opened a thread on ED forums first, suspecting it is a DCS bug. My issue could not be recreated and I could not recreate it within custom missions. Then I tried just loading the liberation miz file, without the actual generator running, and the vehicles looked normal. What makes it extra strange, is the effect disappearing when the vehicle goes through water. Perhaps it is a combination of things.
I definitely experience the same thing. As I was watching a group of Abrams (all glowing), after a few minutes the first one wastn't glowing anymore, than the second, etc. Don't know if that's because they were entering an enemy air base, or some timer, or else.
Has anyone seen this recently? I don't know that I ever have.
It happened to me again, maybe two week ago. It seems random, and rather rare.
I see this all the time, actually. Usually when tanks are on level open terrain and moving. But not roads or water.
I do however use Taz's Better Smoke Mod which already modifies the effect files so maybe something in there exacerbates the issue.
https://discord.com/channels/595702951800995872/595706079459934208/789143835016036382 reports seeing this outside Liberation.
Hi all, just arrived here off the back of Jabbers' recent vids. Really loving the concept, but I too am seeing the glowing ground units when they're on the move. Saw it in the previous release, too.
Not seeing it in non-Liberation missions :/
Best, Rik.
My latest tests showed the following results
Setup
Latest DCS Openbeta with Liberation 2.3.4 and "Better Smoke 8.1 IC compliant" on Caucasus map
Liberation generated mission
https://paste.pics/BABLB https://paste.pics/BABLG https://paste.pics/BABLM
Ground vehicles moving offroad below 4kts do not glow, but the moment it hits >=4kts and it's offroad, it glows. Once it's on a street, or crossing a street, the glow is off, regardless of speed.
Manually created mission same setup as above, even on the same spot on the map - no glow whatsoever, regardless of speed or on/off road position
I even tested multiple weather conditions and time of the day - pattern remains as described above.
I think @Khopa is on to something here regarding the mission load sequence, as in, what is the very first mission you load after starting DCS. I did some tests this morning - no altering anything on the miz file. It is reproducible and it's also the first time in months, were I have not seen the glow at all, since everything I do is Liberation missions.
glow_test.zip liberation_nextturn.zip
Verdict: Looks like, whenever liberation_nextturn.miz is the very first mission that is being loaded, the subsequent missions will have the glow effect. What puzzles me is scenario#5
scenario#1
don't start Liberation start DCS load vehicle_glow.miz (manual ME mission) and validate --> no glow -> close mission & return to ME load liberation_nextturn.miz and validate --> no glow -> close mission -> DCS crash -> exception on close (screenshot available if needed)
scenario#2
don't start Liberation start DCS load liberation_nextturn.miz and validate --> glow -> close mission -> DCS crash -> exception on close (screenshot available if needed)
scenario#3
start Liberation and press Take Off start DCS load liberation_nextturn.miz and validate -> glow -> close mission & return to ME load vehicle_glow.miz (manual ME mission) and validate -> glow -> close mission & return to ME close DCS
scenario#4
start Liberation and press Take Off start DCS load vehicle_glow.miz (manual ME mission) and validate -> no glow -> close mission & return to ME load liberation_nextturn.miz and validate -> no glow -> close mission & return to ME close DCS
scenario#5
start Liberation and press Take Off start DCS load vehicle_glow.miz (manual ME mission) and validate -> no glow -> close mission & return to ME load liberation_nextturn.miz and validate -> no glow -> close mission & return to ME load vehicle_glow.miz (manual ME mission) and validate -> no glow -> close mission & return to ME close DCS
Scenarios 1 and 2 won't work for liberation regardless. Liberation must launch first so it can modify MissionScripting.lua
before DCS loads it.
Thanks a lot for figuring out the steps 👍 How many times in a row did you try scenario 3? I'm wondering if the procedure and results here are coincidence or if that's 100% repeatable. Scenario 3 (aside from the second, non liberation mission) describes most of the games I've ever played and I've still never noticed this issue.
Any chance that this only happens when you launch from the mission editor? I never do that.
I agree these results are fairly puzzling.
since I'm fairly new to DCS, I have two patterns/play styles:
A) 100% without Liberation -> instant action to learn new modules B) 100 % with Liberation -> starting Liberation -> Take Off Button -> start DCS -> go to ME -> load liberation_nextturn.miz -> don't touch anything and hit play. In option B) I had 100% of the times the glow, since I play Liberation (>v1.9)
Related to your question on scenario#3 - I didn't count the exact number of attempts, but >5 for sure and it was 100% reproducible on my end with the documented steps in order.
Is there another way to lauch a Liberation mission, other than from the ME?
Another weird thing, potentially related to the startup sequence is, that I started flying the KA-50 with my new Virpil Control Panel (Button Box). Virpil provided a link tool which I have to start prior to DCS startup in order to sync argument values (C:\Program Files\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\Ka-50\Cockpit\Scripts\mainpanel_init.lua) using a Hook (C:\Users\Maxl\Saved Games\DCS.openbeta\Scripts\Hooks\vpcGameGUI.lua) and a Hook Profile (C:\Users\Maxl\Saved Games\DCS.openbeta\Scripts\Hooks\vpc\VPCExportKa-50.lua) ... essentially a "local LUA server". The result is, that I can change the LED color on the button box based on those ingame argument values.
local socketHost = '127.0.0.1';
local socketPort = 4123;
log.write('VPC.EXPORT', log.INFO, 'Loading JSON lib');
package.path = package.path .. ";" .. lfs.currentdir() .. "/Scripts/JSON.lua";
json = require("json");
log.write('VPC.EXPORT', log.INFO, 'Loaded JSON. Switching package.path...');
package.path = oldPath;
log.write('VPC.EXPORT', log.INFO, ' Loading Sockets lib');
package.path = package.path .. ";" .. lfs.currentdir() .. "/LuaSocket/?.lua";
package.cpath = package.cpath .. ";" .. lfs.currentdir() .. "/LuaSocket/?.dll";
socket = require("socket");
log.write('VPC.EXPORT', log.INFO, 'Socket lib loaded');
log.write('VPC.EXPORT', log.INFO, 'Starting socket connection');
c = socket.udp();
c:setpeername(socketHost, socketPort);
log.write('VPC.EXPORT', log.INFO, 'Created socket connection to ' .. socketHost .. ':' .. socketPort);
function LuaExportActivityNextEvent(t)
local data = {} ;
local MyPlane = LoGetSelfData();
data['plane'] = 'Ka-50';
local panel = GetDevice(0);
if(panel:get_argument_value(330) == 0) then data['Light_K_Bank_Hold'] = '0' else data['Light_K_Bank_Hold'] = '1' end
if(panel:get_argument_value(332) == 0) then data['Light_H_Hdg_Hold'] = '0' else data['Light_H_Hdg_Hold'] = '1' end
if(panel:get_argument_value(333) == 0) then data['Light_B_Alt_Hold'] = '0' else data['Light_B_Alt_Hold'] = '1' end
if(panel:get_argument_value(331) == 0) then data['Light_T_Pitch_Hold'] = '0' else data['Light_T_Pitch_Hold'] = '1' end
if(panel:get_argument_value(334) == 0) then data['Light_Flight_DIR'] = '0' else data['Light_Flight_DIR'] = '1' end
if(panel:get_argument_value(65) == 0) then data['LGCP_gear_handle'] = '0' else data['LGCP_gear_handle'] = '1' end
socket.try(c:send(json:encode(data)));
return t + 1.0;
end
function LuaExportStop()
socket.try(c:send("quit")); -- to close the listener socket
c:close();
end
Long story short - in any mission BUT liberation_nextturn.miz, the above functionally works.
So Liberation must somehow tinker, with what is loaded on either game or mission start. I sadly lack the knowledge on what Liberation is doing in that regards, but it definitively does more than "just" create a MIZ file.
I need to verify, if I can make the button sync work, with the same test pattern as for the glow - will report back later this week.
Quoting my comments on Discord last night :
I have done some testing and it looks like the issue will only happen if DCS Liberation is the first mission loaded by the game. If Liberation is the first mission loaded, the bug happens consistently. And then it even happen in others missions.
If i restart the game, load Liberation as the first mission to be played in the editor, and delete the triggers that loads our lua scripts and library, and starts the mission, then the glowing vehicles bug will not happen.
My theory is that the DCS game engine loads particles effects on the first mission you launch, and one of our script being loaded at "MissionStart" might be "somehow"overriding some critical variable in the scripting context for this dust effect to be loaded correctly, thus causing it to be replaced by the glowing effect.
Then on subsequent missions launch, since the effects have already been loaded, DCS is not loading it again, so the bug will remain if it was enabled by Liberation, or will never happen if you started your DCS session with a normal mission.
(Note : i might be wrong, not 100% sure about all this)
Theory : Some people will never experience the bug because they have disabled such particles effects ?
In all my tests i was launching from the miz editor.
@DanAlbert I did scenario 3 and 4 more than 5 times last night with the same results.
I still have to figure out which script exactly is triggering the issue. This is where it gets weird and results are inconsistent. If you disable all the scripts, you won't have the glow bug. If you restart the game and remove the dcs_liberation.lua trigger, sometimes you won't have the glow, sometimes you will have it. (It is really tedious to test because you have to relaunch the game each time you want to test a new case)
Also worth posting it here for reference, Taz1004's (Better Smoke mod author) comments on the issue, vehicle effects and possible causes :
https://forums.eagle.ru/topic/244009-better-smoke/?do=findComment&comment=4536986
If you folks give me a clear test plan to run, I'm happy to help, since my machine starts DCS fairly quick - and yes, it is tedious, but worth it :-)
But I think we are a big step further than a week ago on this issue! 👍
Some additional info: https://discord.com/channels/595702951800995872/595706079459934208/799100392910749727
Hi, this issue is still present.
And i know the cause. It happens when you script the mission to spawn a vehicles for a country that doesnt possess such vehicle. Similar problem happens with aircraft as well, but instead of glowing they show 0% RPM and dont make engine sounds.
I suggest using the new Combined Joint Forces "countries" for use of vehicles that involved countries dont own.
Really? That's bizarre. I can't remember which faction I would have tested with, but I usually used a CJTF faction for testing... Maybe I didn't this time.
Assigning to 3.0 to audit the factions.
no it does always work correctly with CJTF because CJTF owns all vehicles. what i meant is that the glowing bug will appear if, for example, you would spawn a russian abrams tank. last time i saw this was one of the syrian scenarios i played couple days ago. dont remember which one, sorry, but according to tacview, the glowing vehicles were humwees, i assume syrian.
in regards to the second bug, i made a bug report on ED forums: https://forums.eagle.ru/topic/243811-ai-can-fly-at-constant-speed-and-altitude-with-0-rpm
they are fundamentally the same problem.
Yes, that's what I'm saying. I usually use CJTF blue factions when testing so I'm pretty sure I saw this happen with CJTF blue. Like I said, maybe I didn't use CJTF blue when I was working on this.
Appreciate the diagnosis. I spent hours on this and didn't know what to make of it :)
A note for whoever ends up looking at this:
pydcs does have a list of what is and isn't allowed so this doesn't need to be a manual audit:
# From dcs/countries.py
class Iraq(Country):
id = 35
name = "Iraq"
class Vehicle:
class Artillery:
Mortar_2B11_120mm = vehicles.Artillery.Mortar_2B11_120mm
MLRS_BM_21_Grad_122mm = vehicles.Artillery.MLRS_BM_21_Grad_122mm
SPH_2S1_Gvozdika_122mm = vehicles.Artillery.SPH_2S1_Gvozdika_122mm
SPH_2S3_Akatsia_152mm = vehicles.Artillery.SPH_2S3_Akatsia_152mm
...
Probably best to make a faction linter that can spot all the problems, fix them, and then integrate into the faction loader so we can warn for custom factions.
How do you explain this, then?
Last I checked, Russia can use T-72Bs. And this one is glowing.
Damn. It sounded promising.
How do you explain this, then?
Last I checked, Russia can use T-72Bs. And this one is glowing.
dammit
edit: could you somehow attach the mission or link it? id like to look at it.
@Hornet2041 From my experience, if the glowing moving unit bug happens, then any moving unit in the mission will glow. This is not only the units that "shouldn't be there" that will glow.
im at work right now but iirc it was the default Russia 1990 / usa 1990 factions
@Hornet2041 From my experience, if the glowing moving unit bug happens, then any moving unit in the mission will glow. This is not only the units that "shouldn't be there" that will glow.
i have just tested this, its true.
also once the bug appears, it appears in game until exit to desktop. after running faulty nextturn.miz, i made an empty clean mission in mission editor with just one red t-55 and it still glowed.
this means you have to restart the game for each test.
after some more testing, im consistently NOT getting glowing vehicles if I disable JTAC Autolase script, either in liberation campaign settings or directly in mission editor. and consistently getting glowing if I leave it enabled.
yes, im restarting the game after each mission run. could someone verify this please?
it is also possible there are multiple independent or even mutually dependent triggers of this bug.
I agree, I tried the mission with the glowing t-72b with JTAC autolase on and off, both times starting from a completely fresh boot of DCS.
JTAC Autolase on resulted in glowing vehicles, with it disabled, vehicles did not glow.
I ran another test with JTAC autolase on but JTAC smoke disabled - with smoke disabled, vehicles did not glow
If it's related to the JTAC autolase that would also explain why a lot of folks don't see this outside Liberation, and why many of us don't see it in liberation.
i have modified the jtac autolaze script to run normally except not actually spawning smoke (commented out the DCS API call) and the glowing is gone. i have also modified it to print out the function call arguments and they all seem to be normal so its not a bug in the script it seems.
i suspect the problem is caused by modifying the world state during mission initialization phase. i will try to recreate the glowing in a clean non-liberation mission.
in the mean time, try this. i have moved the JTAC autolaze stuff out of mission start trigger into once trigger, activating couple seconds into the game. glowing seems to be gone.
does it work for you?
Is that why most scripts inexplicably recommend loading everything on a delay? I've always wondered what that was about.
in the mean time, try this. i have moved the JTAC autolaze stuff out of mission start trigger into once trigger, activating couple seconds into the game. glowing seems to be gone.
does it work for you?
this does work but only if i also set the config-options trigger to activate 1 second after the initial autolase script activates
@Hornet2041 got the attention of some folks in the Hoggit discord (can't link messages from mobile, annoyingly, but it's in the #scripting channel if anyone is interested) and Grimes was able to reduce it to something that they filed with ED as a bug. It was reduced from a Liberation mission so we haven't been able to rule this out as us generating an incompatible mission, but it's progress.
Grimes reduced it to smoke triggers that are created before the mission finishes loading (scripts are allowed to run during that time, for some reason), so the trivial user-side workaround is to disable the smoke feature of JTAC autolase. Since this is most annoying at night, and smoke is pretty worthless at night, that's something.
I get the orange glow on all vehicles on the move, no matter which side. If it's moving, it's glowing.
This is fixed in the 6.0 dev builds with the replacement of the old jtac autolase script with the current CTLD script, isn't it?
Should be. Thanks for remembering.
I actually experienced the issue on the dev build today but only with friendly vehicles...
I noticed moving vehicles have an orange hue around them, similar to the glow effect around burning wreckages. This is especially apparent at night, which makes it super easy to spot marching vehicles. The effect disappears when the vehicle stops, or goes through water.
If I place these units in the mission editor and have them drive around they do not glow. Also, if I load the liberation_nextturn.miz file, without the mainframe running in the background, the moving units do not glow at all. This leads me to believe, the glow effect is somehow caused by a DCS Liberation 2.0 script. Could you please look into this?
I made some screenshots.
Abrams' and Bradleys on the move: https://photos.app.goo.gl/5fqdpczcsjuBDedK6
BTR glowing before being hit: https://photos.app.goo.gl/BbVwr2AxtzvEVut67
Abrams tanks standing still: https://photos.app.goo.gl/pCEETvjSTQ6nFhv59