Jump to content


  • Posts

  • Joined

  • Last visited

About daribouca

  • Birthday 10/03/1979

Personal Information

  • Location
  • Occupation
  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 !
  • Create New...