daribouca
-
Posts
78 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by daribouca
-
-
I don't think I follow. net.load_mission is a functionality provided by DCS and allows a script to load a specific mission. I need the opposite functionality, and event that gets called when server loads the mission.
Actually, what I was thinking about was to use the same mechanism as Slmod. Almost all dedicated servers are running Slmod anyway, so you could go with the "chat command hook" thingy.
For the people hosting the regular way, would a GUI hook do ?
In "/Scripts/net/uiSelectMission.lua", I found this:
function onFileSelect(lst, item, dblClick) if not item then window["8"]:setText('') return else window.selected = nil local f = item:getText() local fname if f == '..' then local s,e s, e, fname = string.find(window.path, '(.*[/\\])([^/\\]+)[/\\]*') --base.print("up from "..window.path.." to "..fname) else fname = lfs.normpath(window.path .. '/' .. f) end if item.isdir then window["8"]:setText('') if dblClick then update(window, fname) end else if dblClick then --window["8"]:setText('run '..fname) net.start_server(fname) window:setVisible(false) else window.selected = fname local descr = net.get_mission_info(fname) --base.print("description: "..base.tostring(descr)) window["8"]:setText(descr or '') end end end endThe "if dblClick" calls "net.start_server(fname)" with "fname" being the selected mission in the file list right hand of the Gui.
As for the "START" button, I *think* it is in this function:
function create() window = net.center(loader.spawnDialogFromFile('Scripts/net/ui/load-mission.dlg', cdata)) window:setTop(true) window["6"].onChange = onPathSelect window["7"].onChange = onFileSelect window["10"].onChange = function() if window.selected then net.start_server(window.selected) window:setVisible(false) end end window["9"].onChange = function() window:setVisible(false) end -- fill paths local i,v local lst = window["6"] for i,v in base.ipairs(lfs.locations()) do local item = ListBoxItem.new(_(v.name)) item.lfs_path = v.path lst:insertItem(item, lst:getItemCount()) end -- fill files local path = base.config.server.mission_dir if path then lst:setText(path) update(window, path) end end, this part to be precise:
window["10"].onChange = function() if window.selected then net.start_server(window.selected) window:setVisible(false) end end
( the window["10"] is related to the "/scripts/nets/ui/load-mission.dlg" file)
I'm running out of time this morning to confirm, unfortunately, so I can but hope that this info is relevant and will be useful to you.
-
Not possible for my wing. Missions are loaded on-demand, with no access to shell... we need to do our own lua hook on S_EVENT_MISSION_START event callback, so, you know what ?
Let's Winz do the implementation once :smilewink:
Why would you want a shell ? All you need is some kind of access to the hard drive =)
Troposphere could be run from *any* machine, provided you have a way to send the results to the server.
I'm assuming at least one person has write access to the server ? Here I'm using a SFTP mount to directly write in the mission folder of the server, but a temp dir on some guy's machine would do just as fine, all you'd need to do is mod/upload the files as often as needed.
I'm opened to suggestions if you have ideas on other ways how to work around the mp constrains.It could be as simple as hooking the net.load_mission function, same way Slmod does for the "-admin load" chat command. From what I understand by reading this
slmod.scheduleFunctionByRt(net.load_mission, {path .. self.filename}, net.get_real_time() + 5), one just has to call "net.load_mission(full_path_to.miz)" in order to switch the current mission on the server.
Concerning the backup concern, would it be very hard for you to implement a two step mechanism, by first copying the miz to some MODDED.miz file, then modifying this one, and finally loading it with net.load_mission ?
Which, translated in rough lua, would give:
function replaceWeather(missionPath) -- binary copy of the input file to an arbitrary location local out_path = "MODDED_" .. missionPath local in_file = io.open(missionPath, "rb") local out_file = io.open(out_path, "wb") local data = in_file:read("*all") out_file:write(data) out_file:close() -- Troposphere stuff local lpath = "__local_path_to__\\Troposphere\\Troposphere.exe" local executionPath = base.string.format('"%s" "%s"', lpath, out_path) base.os.execute(executionPath) -- server load net.load_mission(out_file) endI'm no Lua guru, so this may be off, but you get the idea =) Also, you could choose to have only one "MODDED_*.miz", "Tropo_temp.miz" for example, which would be overwritten every time Troposphere runs. It would prevent useless cluttering of the users' mission folder. That temp file could also be stored somewhere else on the drive, in Tropo's main dir for example.
Something totally different now ! I think it would be nice to be able to choose the output file, with
troposhpere.exe input.miz output.miz
, for example.
And then, but I know I'm pushing my luck, I'd love to be able to select the weather database at runtime, by moving the "weather_groups.cfg" into the "weather_definitions" folder, and be able to do something like
troposphere [-i[n] input.miz [-o[ut] output.miz [-c[onf] weather_def_folder
With this, we would be able to generate a bonanza of missions to choose from in a single huge batch sweep, making different kind of weather for the same mission, and making them all available at the same time. Currently I'm doing it with a script that moves the weather_def and the config in between the runs, but I thought it would make a nice suggestion, so here it is =)
Bunch of kudos once again for your work, and many thanks for giving it away, much appreciated :beer:
-
But almost useless for me if no MP :(
This is a simple as running a .bat file or a one-line command before the mission start.
-
My guess concerning the big value thingy would be the units used. It saves ED the hassle of having to deal with floating points numbers. IIRC, the fluctuations are expressed in Pa, where we are way more used to seeing them in hPa. Could be wrong, though.
-
The Steerpoint is the selected Waypoint. There can only be ONE Steerpoint at a time. The Steerpoint is also you default SPI.
A Waypoint is a navigation (2D or 3D) point that exists in the current (selected) Flight Plan.
A Markpoint is a point you can quickly make from the SOI. You can thereafter create Flight Plans with those Markpoints, should you wish so. Markpoints then become Waypoints in the new Flight Plans, and can be selected as Steerpoint.
As for the Bullseyse, the Bullseye is the Bullseye, nothing more, nothing less. It is set by the mission creator, and one and only one exist for each coalition. It *cannot* be moved during the mission.
Your Anchor Point is the point you can get relative reference to / from. It is used to safely transmit coordinates on unsafe radio channels.
At mission start your Anchor Point is set to the Bullseye, therefore you can get / give coordinates from / to the Bullseye.
Later on, you can decide to set your Anchor Point to any other point (Waypoint, Markpoints). For example, you can decide with your flight that the Anchor Point should be set and advanced to the IP for every run you make, depending on the zone you are attacking.
Very much to learn in the A10 CDU-wise, and not all of it prove useful in the *game*, but there are neat tricks you can pull off once you get your head around all the systems.
I found it an enjoyable process, I hope you will too ! :beer:
-
How'd you get it to work in MP? Thought it was not supported
No it's not, as far as I know. However, I git-diffed the DCS folder after the "injection", and saw that, basically, Troposphere works like this:
path/to/troposhpere.exe your-mission.miz
The resulting *.miz file overwrites the previous one.
From there, all that was left to do was generate the weather database, then call "Troposphere.exe" on each and every *.miz, file on the server, as often as needed.
Et voilà :beer:
EDIT: the way Troposphere works is actually described in section 4.b of the manual. Git was faster, though ^^
-
This is awesome !
I took the liberty to implement your application on our dedicated server, and now the weather for each and every mission is randomized every morning.
Funny situations sometimes, but a whole lot of fun in the end !
Thank you so much for the time you put into this :beer:
-
Here's a bunch of (unsorted) crash-logs from our dedicated server, hope it helps
-
Still unable to give some reputation, I wonder what I need to be able to do so ...
-
Thank you very much for this !
-
I'm also very interested in this, should you ever happen to find a solution.
As far as I can tell, the "dcs.exe" process does not even read "uiMaster.lua" when it runs. Also, I could not find the file that writes the line "client has started" in the log. I'm inclined to think "obfuscation" right now, like someone does not want us tinkering with it. But maybe I'm just tired and frustrated =)
I've been tracing the startup as far as I could, to no avail. I'll give it another try later, and will post any result here.
For the anecdote, I'm trying to gain lua access into the GUI so I can disconnect the monitor from my server, and spare some energy. Its only use right now is during the first two minutes at boot, in order to send mouse commands to run, login and load the mission. Still have one or two ideas, but the lua solution looked so neat ...
-
I found this diff in the file Scripts\Aircrafts\_Common\Cockpit\Macro_handler.lua, which is, from what I can understand, an update of DCS that is not included in the modded version of the file.
I *think* part of this is related to the printing of the autostart sequence, a feature that was introduced not so long ago. Some other things are also changed, but I have absolutely no clue what they're referring to.
Please note that I'm a complete noob in this matter, I'm not ashamed to say that I have no idea what I'm talking about. I'm posting this hoping that PeterP will manage to find the time to look into it.
I've included the file I'm currently using, which is a simple merge of both PerterP's and the official patch modifications. Again, I may be totally off, use at your own risk etc.
@@ -94,19 +94,10 @@ function SetCommand(command,value) if start_sequence_heavy == nil then start_sequence_heavy = start_sequence_full end - - if dev:check_autostart_condition() ~= 0 then - if LockOn_Options.flight.easy_radar then - kill_routine(stop_order) - check_routine(start_order,start_sequence_full) - else - kill_routine(stop_order) - check_routine(start_order,start_sequence_heavy) - end + if LockOn_Options.flight.easy_radar then + check_routine(start_order,start_sequence_full) else - for i,o in pairs(alert_messages) do - print_message_to_user(alert_messages[i].message,alert_messages[i].message_timeout) - end + check_routine(start_order,start_sequence_heavy) end elseif command == iCommandEnginesStop then kill_routine(start_order)-
1
-
-
Did you check the official A10 manual ?
All you asked for is explained in depth there, around page 220 IIRC :beer:
-
I don't see why this would be a problem ... you say "both of them should start at the beginning of the mission", but I *think* slmod is supposed to installed (once and for all) on the server, and from there there's pretty much nothing else to do any more.
You do not need to include slmod into your missions, only the Mist library. Also, I've been making missions with (many) more than one lua script inside, asking for MIST to be loaded first, then adding all other scripts at one or two seconds interval, and, of course, slmod was running on the server. No problem so far !
-
Yes, the functions are repeated with the mist.scheduleFunction and "intervall" sets the time-intervall it is repeated.
The single functions are scheduled with an offset, because the mist.goRoute function needs existing units to work and therefore I have to spawn the units, before I can give them a route. I am also looking for a way to randomise the spawn intervall more than just once in the beginning, but havent´t figured out a working path so far. 300 seconds minimum might be a little too low intervall and mission might get crowded too fast. Than the intervall must be set to lower a frequenzy.
If you want to randomize the delay each time, you could go the timer.scheduleFunction way.
The function has to have the signature "function(args, time)", and it also has to return as "return time + delay", where "delay" is the time in seconds until next execution. Is this not what you want to randomize ? :beer:
-
This is a great idea ! Thanks a lot for sharing :beer:
I can not test it ATM, but I read it, and I have a question for you: are the three times functions supposed to be run only once ?
As far as I know, scheduled function that wanna re-schedule themselves have to have the signature "function(args, time)", and must return as follow: "return time + DELAY", with delay being what you want between two calls.
I'm trying to understand how you did it, but I gave it my best without success, and as I said I have no possibility to test it until next week.
Is there another way to schedule functions with Mist besides the one described above ? Or am I totally and hopelessly off ? :P
EDIT: ok, I think I got it, looks like mist.scheduleFunction and timer.scheduleFunction are not quite exactly the same ...
-
Thanks a lot for your time, much appreciated :beer:
-
@icemaker:
(mes excuses si tu t'es déjà prononcé sur le sujet) Pourquoi pas passer en open source, sur GitHub par exemple ? On pourrait te donner un coup de main, surtout pour des trivialités comme le chemin dans la BDR.
Tu n'aurais plus qu'à checker les pull requests, et à refaire un build de temps en temps :beer:
Puis quand le prochain problème arrivera, le premier à avoir un peu de temps libre sous la main pourra directement mettre la main à la pâte. Enfin, mais ça n'engage que moi, c'est toujours mieux d'être plusieurs sur la même source, ça aide à garder une vue d'ensemble, et tout le "sal boulot", comme mettre de l'ordre, traduire, refactoriser tel ou tel bout de code, est partagé.
Et on ne sait jamais avec quelles nouveauté / bonne idée les gens peuvent arriver ;)
Au passage, pour récupérer le chemin, j'utilise cette clef:
HKEY_CURRENT_USER\Software\Eagle Dynamics\DCS World\Path
Ceci dit, il y a toujours un fou furieux qui a plusieurs installs de DCS, donc qu'est-ce que tu dirais d'une petite "input box" avec un bouton "browse" à côté ? Le chemin détecté dans la BDR s'affiche par défaut, et le gars qui veut en mettre un autre à la place sera libre de le faire. C'est une requête que j'ai eu avec les TDC pour le TDCSKI, donc, pourquoi pas ...
-
I am not sure I got your point exactly, but when I needed to parse and then alter "mission" files LUA table, I pushed them into an ordered Python dictionary, without running any piece of LUA code. Then changes can easily be made programmatically, and re-injected into the mission file, or spawn any number of new tweaked *.MIZ as necessary. But you could do pretty much whatever you want with the resulting data, very easily.
I chose Python because of it being widely available on almost every machine/server.
If you're interested, I already made the parser, along with all the *.MIZ file handling. You'd just need to tailor it down to your specific needs.
-
I just installed Migos Shkval Mod but it does not work if it's put into the folder it should be, at least according to the zip file folder structure.
Instead the bmp must be renamed to SHKVAL_MASK.bmp and put here:
\DCS World\_MODS\skhval\Mods\aircrafts\Ka-50\Cockpit\Resources\IndicationTextures\
have fun :)
Thank you very much !
I would be very interested to know how you figured that one out, I have not ever heard of a _MODS folder ...
-
See this thread for help with dedicated server launch
-
Nice ... enjoy ! :beer:
-
Hey,
I'm successfully using the addgroup script from this example :
http://forums.eagle.ru/showpost.php?p=1738368&postcount=2
It works nice but now I'd like to add a couple of waypoints as well and I'm not sure how that works. I tried adding the whole ["route"] section copied from a different group but it contains also this ["spans"] section that seems to me like some precalculated waypoints and can sometimes contain hundreds of points. If I don't include this section the unit spawns but doesn't move. So is it please possible to add waypoints to dynamically added groups without the ["spans"] section somehow (or do I have to recalculate the whole spans section on spawn?) ? The reason why I'm asking is that I'd like to make this waypoint coordinates random inside a certain area as well but since the spans are precalculated the route would be always the same - so spawning a randomly paced unit is useless when the route is always the same.
In my recent and limited experience, I had groups of ground units spawning with only two waypoints. The first one was the center of a randomly chosen zone and the second one was another zone. They took _ different _ route for each group that spawned, so my guess would be that the spans are calculated when the units appear.
Also, since then, I realized MIST2.0 was out, and had delicacies like mist.ground.buildWP, mist.getRandPointInCircle, mist.groupToRandomPoint, mist.groupRandomDistSelf, mist.grouptoRandomZone, and mist.groupToPoint.
They should help you to achieve your objective :beer:
-
Where I have to put this line? :)
As far as I know, and please prove me wrong, the "set internal cargo" is only for the Player unit, it does not apply to Client. In the ME, it does not accept any kind of "unit" argument.
It looks to me that we're in the same kind of pudding than for the "failure" trigger, which would be such a treat to have available for client aircrafts.
Let us hope it will become so one day !
Dynamic Campaing mod for DCS
in Utility/Program Mods for DCS World
Posted
Still working on it !