PravusJSB

Yea, if it's one of your messages, otherwise you'd have to find a way to store said message and that should be OK, but the method would depend on the message.

Yes, I would think that on trigger you silently destroy and then respawn it with the hidden as false.

Seems they have changed the Dedi server code since the SC, it seems to operate in a different env. Not sure but I've had to change a ton of my code to work in my dedi even though the same code works in my client. I can even run code in my client, connected to my dedi and I get 2 different results. Usually nil in the server...

Hi chaps, I'm not sure if you've stumbled upon my other thread, but I'm looking for mission designers and those especially that run 24/7 servers, with Lua knowledge and DCS workings knowledge preferable. I'm creating something unique and I'd like some alpha testers in a closed group whilst it's still coming together. some details of what it is here; https://forums.eagle.ru/showthread.php?t=276072 Please drop me a PM on forums or Discord to get involved, and influence the dev direction. Devplan here; inTheWorks = { [1] = "Persistence (save game) maodule for automation of everything", [2] = "globalFlags, for passing information from 1 reboot to the next, or mission to mission", [3] = "nil", [4] = "escortScoring, and extensive scoring system including a fully working and feature rich escort class for clients", [5] = "eventManager, creating a framework of useful functions based on events of players.", [6] = "gridModule, for manipulation of the god awful role select grid, get rid of the aircraft you need to and bring back when you want", [7] = "nil", [8] = "realLogistics, a module to sit on top of the WH int, to enable real world movement of supplies, create a supply chain, make dcs supppliers redundant", [9] = "serverOptimisation, for making MP feel like SP, no shitting around".."NOTE: I have and havenot been adding in optimisation in these as I go, but once all complete I will optimise again.", [10] = "simpleZoneCap, maybe? a simple framework for setting up zone capture area's for red/blue battles in the wild. MOOSE has this but I found it to be CPU time intensive", [11] = "***", [12] = "simple dynamic spawn manager, maybe?", [13] = "bring in the various, and often very good, dcs utils and me_db_api for use in scripting", } inProgress = { [1] = "WH wrapper, for MOOSE wh, and DCS wh integration", -- most focus will be on this -- Major TODO -- Find fuel and ammo info, write code for aircraft info -- write back to stock code, looking at a number of options -- begin the supporting logisticModule -- this module does not function on a DEDI server, unsure if will work on anything but singleplayer right now, but I have a plan [2] = "jsbGate, core module to bridge server Lua code with mission scripting", [3] = "VSC Debug, integration into VSC for live stepping into DCS code, very powerful", [4] = "netModule, to bring 'net' API into mission scripting", [5] = "dcsModule, bring into SSE the 'DCS' API functions", [6] = "UTILS for server admins, a bunch of useful tools to make life easier", [7] = "eventDatabase, tracking and handling events, passing to functions when needed, saving all events in a file for use later or tracking, can whitelist, blacklist, choose which to redirect to a function ect, used DCS in built handler thats already running so will be super efficient", [8] = "baseManager, a framework for managing base captures and what to do thereafter, simpleSlotBlocker integration, a basereward framework, mission completion tools and loading of next mission automatically", } some example output here; ret["players"]["all"]["2"] = {} ret["players"]["all"]["2"]["ping"] = 0 ret["players"]["all"]["2"]["side"] = 2 ret["players"]["all"]["2"]["slot"] = "instructor_blue_1" ret["players"]["all"]["2"]["id"] = 2 ret["players"]["all"]["2"]["score"] = 50 ret["players"]["all"]["2"]["name"] = "[GM] PravusJSB" ret["players"]["all"]["2"]["pilotid"] = 2106394 ret["players"]["all"]["2"]["ucid"] = "5c973f84b5" ret["players"]["all"]["2"]["started"] = false ret["players"]["all"]["2"]["lang"] = "en" ret["players"]["all"]["2"]["ipaddr"] = "82.48" [57] = table: 0000021C02E95300 { ["clsid"] = "{BRU33_2*LAU61}", ["count"] = 10, ["name"] = "BRU-33 - 2 LAU-61 - 19 2.75' rockets M151 (HE)", }, [58] = table: 00000218C56500B0 { ["clsid"] = "{FPU_8A_FUEL_TANK}", ["count"] = 99, ["name"] = "FPU-8A Fuel Tank 330 gallons", }, [59] = table: 0000021888ABED00 { ["clsid"] = "{LAU-115 - AIM-120B}", ["count"] = 98, ["name"] = "LAU-115 - AIM-120B", }, [60] = table: 00000218C5651230 { ["clsid"] = "{DB769D48-67D7-42ED-A2BE-108D566C8B1E}", ["count"] = 100, ["name"] = "GBU-12", },

Some great initial interest and people involved, with some great early ideas which has evolved the dcsWarehouse integration to include things like a real supply chain and resupply framework, creating physical assets to move around weapons on the map. I'm still looking for people skilled with Lua/code in general/mission designers and server managers to get involved early to shape this new framework.

in my experience, 16gb is fine my server takes around 3-6Gb with 1100-1300 units and 6-10 players, the cpu isn't actually that costly either, when I optimise the profiles for the system and give DCS a dedicated core it idles in a mission at around 30-40%, some large tasks occurring at the same time might take it up near max but its rare my server hits the top line. I would say SSD is a must, faster the better, some tasks I do go back and forth from disk to memory often and would be detrimental to performance should I have a slow disk, but any SSD should be fine. My server ran 24/7 on my laptop with core speed of 4GHz and 16Gb DDR4 without a problem.

I should mention that on a dedi server this is all above board and not 'modding' DCS if you will. I'm not altering DCS files in anyway, but I am hooking onto some where the functions talk to C and C doesn't like us calling it ;)

I can say with confidence just about anything within the bounds of DCS capability can be altered with this framework. I have a few more modules in mind too that will be unique, its a shame I see so many complaining of MP performance, I have 1100 units moving, lots of code, lots of cpu time and my server runs like a single player for anyone whos in it. I'll try think how i could automate that somewhat so others without the skillset to do it can benefit some. Maybe you should come onboard and help ;) EDIT, an idea of where this is going long term; TODO = Module "ideas and plans;" inTheWorks = { [1] = "Persistence (save game) maodule for automation of everything", [2] = "globalFlags, for passing information from 1 reboot to the next, or mission to mission", [3] = "dcsModule, bring into SSE the 'DCS' API functions", [4] = "escortScoring, and extensive scoring system including a fully working and feature rich escort class for clients", [5] = "UTILS for server admins, a bunch of useful tools to make life easier", [6] = "gridModule, for manipulation of the role select grid, get rid of the aircraft you need to and bring back when you want", [7] = "eventModule, maybe.. might need to do this for across the board event tracking", [8] = "baseManager, maybe? for base capture management", [9] = "serverOptimisation, for making MP feel like SP, no shitting around", [10] = "simpleZoneCap, maybe? a simple framework for setting up zone capture area's for red/blue battles in the wild. MOOSE has this but I found it to be CPU time intensive", [11] = ******* [12] = "simple dynamic spawn manager, maybe?", [13] = "bring in the various, and often very good, dcs utils and me_db_api for use in scripting", } inProgress = { [1] = "WH wrapper, for MOOSE wh, and DCS wh integration", -- most focus will be on this -- Major TODO -- Find fuel and ammo info, find aircraft info -- write back to stock code [2] = "jsbGate, core module to bridge server Lua code with mission scripting", [3] = "VSC Debug, integration into VSC for live stepping into DCS code, very powerful", [4] = "netModule, to bring 'net' API into mission scripting", }

very interesting, please have a look at my post in Multiplay>Server Admin and consider coming to work with me on a project ;)

it looks to me like the messages from the LSO are coming directly from the C/C++ VM and not Lua. At the minute there's no way they can be amended/saved/altered unless you start hooking onto the GUI functions. I've not looked super hard at it so I may be wrong though.

maybe see my post in the Multiplayer>ServerAdmin section, I can do what you need.

Hello guys, I've been working for some time now on a framework that wraps around DCS (and MOOSE/Mist in some ways) but mainly brings new code from my learning of how DCS works to provide a set of modules for extending the available API/SSE without breaking the game or doing anything naughty. Most of the time has been spent testing and poking but I'm now ready to pull everything together, I have a plan on what I will write but so far I have; - gateModule: Allows for functions to be called, passed, and data to be sent/returned from scripting env, mission env, server code, api, sse, ect bridging everything together, which is core enabler for everything else. - vscModule: Integrates DCS to MSVSCode and allow live step-in debugging, with all var/ups and locals visible and editable. - netModule: POC which allows the use of the net API in mission scripting, get player info, kick, reload a miz, set mission settings interact and scrape the chat box ect, to be fair this was knocked together in about half an hour as a 'this all works as expected' bit of code. - warehouseModule: A wrapper for MOOSE wh, automates the set up of stocks/wh objects/radio menus and options ect all with 1 line of code. The special feature of this which opens up a whole load of control for the mission designer is the ability to read and interact with the DCS airbase wh live data and integrate it into your logic/design. I like writing code, Im not so fussed about testing and bug testing ect, so I'm looking to open up the code to a group of mission designers/server admins/game masters ect who have sufficient scripting experience to gain access to, test and steer the development of. With a view to polishing it all off into a usable, ,useful and working framework to be released to the community. At the minute the code is a bit messy and there's little annotations/instruction so it's not quite ready yet for release (which is why I'd like to keep the group closed) and I'm sure others can bring idea's to the table that can be implemented into the core code to enhance its function further. If this interests you please drop me a PM, or my discord ID is in my sig. Thanks.

Hi, upon transition from day to night mom stops giving approach instructions, no longer CASE I will not call CASE III, then no charlie at all, lights on the boat do not switch on ect, and it seems to get stuck.

this patch nailed VR for me, absolutely awesome performance, in MP, busy server 1100 units, not a stutter to be seen. New MSAA works a treat, im running almost max settings with 4x MSAA. Thanks ED.

what was the new patch this morning?

Not that I've found, hopefully someone can prove me wrong..

So timer.getTime() gets you the current mission time in seconds, as in 15:32, it's always going to be above 20, you need to reference the time first then do some maths. local timethen function myfunc() if timethen== nil then timethen= timer.getTime() end local timenow = timer.getTime() local countdown = timenow - timethen if countdown > 10 then trigger.action.outText("STEP 1",5) end if countdown > 20 then trigger.action.outText("STEP 2",5) end timer.scheduleFunction(myfunc, {}, timer.getTime() + 2) end

yes i believe there is, set a zone and theres an option for bomb in zone or similar (i dont know the name) which will detect some shooting in the zone. I'm not sure without lua you could differentiate if a player shot though, but maybe.

Same here, having to re-work the maps airbases all over again after an update is grinding my gears.

I may have a bit of code laying around to do something with events, if it's MP you're doing this in?

There's an inbuilt method in ME, create a zone around an area that you want to affect and the create a trigger, and then 'Destruct' and you can select the % of destruction.

Actually I think there's something odd going on with MOOSE SET_CLIENT atm you might want to change it to GROUP instead.

bump 2 spots free'd up.

They're not to my knowledge, you will need to write a little function that catches them all and stores them in a table. Maybe mist or MOOSE stores them but I'm not 100%. edit, nope i just had a quick look through _G and nothing stores them (count I assume you mean).

tmps=0 PlayerCrashSpit = SET_CLIENT:New():FilterCategories("plane"):FilterActive():FilterStart():HandleEvent(EVENTS.Crash) function PlayerCrashSpit:OnEventCrash( EventData ) if EventData.IniPlayerName ~= then if timer.getTime() - tmps >2 then -- i don't understant the argument, timer.getTime() gives mission current time its always going to be >2...? maybe for the first pass change the above to just tmps no value then, if tmps and tmps ~= nil then else end. tmps=timer.getTime() nom = EventData.IniPlayerName Scoring:AddGoalScorePlayer( nom, "Pilot, it's crashed.", nom.." it's crashed -5", -5 ) -- i can't help you here I dont know the class at all. end else --add error? end end that's all you should need, if you really want to limit to those prefixes then maybe add string.find as an argument at the beginning to return if not the one you want. I've not tested this and I'm tired...