Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by daribouca

  1. 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 end The "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.
  2. 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. 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) end I'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:
  3. This is a simple as running a .bat file or a one-line command before the mission start. http://forums.eagle.ru/showpost.php?p=1810753&postcount=14
  4. 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.
  5. 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:
  6. 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 ^^
  7. 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:
  8. Here's a bunch of (unsorted) crash-logs from our dedicated server, hope it helps crashs-logs-daribouca.zip
  9. Still unable to give some reputation, I wonder what I need to be able to do so ...
  10. 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 ...
  11. 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) Macro_handler.lua
  12. Did you check the official A10 manual ? All you asked for is explained in depth there, around page 220 IIRC :beer:
  13. 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 !
  14. 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:
  15. 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 ...
  16. Thanks a lot for your time, much appreciated :beer:
  17. @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 ...
  18. 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.
  19. 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 ...
  20. 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:
  21. 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 !
  • Create New...