daribouca

That is something I would _love_ to make happen, but sadly I'm still on the lookout for any kind of function that will give me a way to implement it. The "Hold the line" mission was only me getting my head around the LUA, and a showcase for the guys I fly online with, please do not consider it a "serious mission" of any kind. It was basically just for the laugh :beer:

It is indeed very doable. Just as a tease, here are some basic mechanics I designed so far =) The "main module" represents the "campaign state", which is basically the map of Georgia, divided into square chunks. Each chunks can be either red, blue, or neutral. Each chunk can also (but must not) hold a particular type of resource. Resources can be, for example, an airport, a refinery, a civilian town of importance, some cultural objective, a factory, whatever. Those resources give the coalition that owns the chunk specific advantages over each "campaign turn". Each coalition is free to spend those resource as they wish. The "decision-making" is made very simple: a coalition has a "high command", which gives priorities to "subordinates HQ", which represents battalions and squadrons on the map. Those priorities can be adjusted by the players, at the start or during the campaign. For example, blue priorities could very well be "ask SEAD to get rid of any immediate threat along the FLOT, maintain tight CAPs at all time, concentrate mud-movers on CAS, do not engage assets over red territory, except for airport strikes. Tell ground commanders to hold the line, while giving priorities to those three chunks (because they contain bridges we gonna be needing soon)". This is just an example, of course. Behind all that, the mission are randomly generated, based on numerous kind of differently shaped zones, that represents the "points of interest" on the map. To those "main zones" are added a lot of "random stuff can happen here" zones. All those zones are injected into the *.miz file, which at this point contain not very much besides inactive red and blue assets. Once all that static generation is done, LUA takes control and makes the magic happen, based on a library of functions that I'm busy writing now. At this point, I cannot give you any clue about a release date, because all of this has still to be tied together. One major headache that I'm struggling with since the beginning of the project is the balance of the ground forces, whose combats must be simulated when they happen outside the players "bubble". The results I'm having so far are so disappointing that I'm almost planning on a rewrite of this part.

Indeed ... do not hesitate to come to me should you decide to use the script I made and need help tailoring it to your specific needs.

Still working on it ! Right now I'm busy with getting my head around all the lua scripting that will be needed to run the whole thing.

It's actually pretty efficient. You can compile your code into an .exe in one click, and then put the .exe in the Windows auto-start, which means the server will autostart AND launch the first mission it finds every time the computer starts (+ auto restart & auto update thingies). It also means you can remotely restarts dcs.exe OR the whole computer with the assurance that you'll get a running server in the end whatever happens. I do not quite understand why you would consider a script such a bad solution. As far as I know, there is _no_ command line option that lets you run the server and launch a mission at the samed time, due to the onlin log-in being mandatory. Anyway, have fun ! :beer: EDIT: This is exactly what my script does ...

This is a snippet from one of my script that you could use to retrieve all the Hueys in a mission: function get_hueys(arg, time) for k, v in pairs(mist.DBs.humansByName) do local this_unit = Unit.getByName(k) if this_unit ~= nil then if this_unit:getTypeName() == "UH-1H" then do whatever you want end end end return time + 5 end It's written off the top of my head, and quite naive syntax-wise, but you get the idea. You could also fairly easily iterate over the list of pre-added units (pre-added meaning added in the ME) using some other mist database. For iteration over dynamically added units, at the moment I use a custom table holding the units' names, have not found a more efficient method yet.

Some feedback: this is __ awesome __ ! Thanks a lot for your time, much appreciated :thumbup:

The options.graphics.render3D = false only helps relieving the server with the display part, so the graphics card used does not matter anymore. I warmly recommend you use Slmod for the remote administration _in game_ Below is some (very dirty) Autoit code that will launch the server, update it if a new version pops out, start a mission, and restart the whole thing if "dcs.exe" dies on you (handy with a remote "taskkill /F /IM dcs.exe" for a hot restart of DCS). You'll need to adapt the paths to fit your system, obviously. Once the server is running, you can choose which mission you want to fly with Slmod ("-admin load"). Cheers ! :beer:

Maybe you could try to alter some settings in your router/switch configuration ? I did not take the time to bother with that as I was pretty sure the new switch was my problem (and indeed it was), but maybe you could solve yours with a bit of checkbox (un)checking ?

Thanks a lot for the heads-up !

I had the exact same problem some days ago, as I was tinkering with my network setup for my brand new dedicated server. I could connect, but was forced out after a few minutes. Turned out that it was the switch I used (DLINK 12 ports GB managed) that was at fault. I revert back to using another switch, and no problem since then. My guess would be that your problem also lies somewhere on the LAN cable between the host and the client =) I can't tell you anything more precise, sadly ...

Yet another version. List of changes (that I remember): theater change embarkable units list changed no more infantry on either side (too slow) MUCH more difficult blue units all start off the same airport, north of the main zone two FARPS for repair/embarking instead of one one little nasty surprise ^^ As for last time, feedback is most welcome, and feel free to do whatever you want with the files included HoldTheLine_Pyatigorsk.miz

I did just that =) See this thread: http://forums.eagle.ru/showthread.php?t=107946

Here's an updated version of the script: http://pastebin.com/bTHRYy9K

As far as I can tell, the missions and its scripting environment are self-contained, so anyone (re)playing it should have no problem with missing functions. However, as I realized while working on it, the mission environment may sometimes become inconsistent with itself, but that may as well be just me being a noob with scripting, so ... I guess your feedback will be much appreciated for track-related trouble !

@gregzagk: feel free to re-use part of or the whole script for your mission, it's very easily translated to another zone. You can also fairly easily change the type of red units, their strength, the quantity of spawning zones, and so on. @HiJack: I have no idea, I don't even know what could make a script break a track. I'd be grateful if you'd gave me pointers to understand ! While searching for "script break track", I found this Mist update from Grimes: http://forums.eagle.ru/showthread.php?t=106234&highlight=script+break+track This piece of code adds a new dynamic database: sct.DBs.dynGroupsAdded I actually had to work around the fact that the Mist AliveUnits database does not keep track of the units I added manually (could not use it anyway, can also be me being stupid), so I will probably work with it for the future versions. It already gave me some ideas ^^ Edit: the Mist update was made by Grimes, not Speed as I originally stated ...

Hello guys ! This mission started as a joke in our squadron, and was at first intended to let me toy around with the lua. I never, ever, wrote a single lua line before this, so please forgive the numerous syntax enormities, and the flaws in the structure of the file. Thing is, it works, et voilà ! It was heavily tested both offline and online, but this is a re-write of the tested version, which I could only test offline. I decided to go public because the first iteration went smoothly, and I could do with the extra feedback. You have been warned, this is for the braves ;) The script is 100% re-usable, provided you stick with the naming scheme for the zones, the Huey's and the FAC, or you could also adjust the names in the beginning of the script. Scenario : blue team has to defend a central zone against never-ending waves of enemies. The waves are getting bigger and stronger as the mission goes along. Here are the key features of the mission: flyable aircrafts: A10, P51, Huey & Ka 50, four of each the enemies spawn only when one or more blue aircraft is in the main zone the enemy unit spawn at (pre-defined) random points the enemy groups composition is randomly generated each time a group spawn the number and power of red units is tied to the number and power of blue aircrafts in the "main zone" (1 Huey will spawn much less red units than 4 A10s and 2 Ka) the Huey's have the special ability to embark many kind of blue ground units: infantry, mortar, stryker (different types), HMMV's (different types) the Huey's can then drop those unit anywhere on the battlefield the Huey's can also re-embark the dropped units (provided they land close enough), and re-drop them somewhere else the FARP and visual NAV point to the zone are marked with a BLUE smoke the pickup zone is marked with a GREEN flare the spawning of red units are marked with a RED flare the pickup zone is a slope; this is intentional =þ the briefing picture has not enough detail ... well, sorry for that one a blue FAC exists at the beginning of the mission, and should it be ever destroyed, will be replaced after a fixed delay (120 sec default) the score of the blue team is tracked and displayed each time a red group spawn the score goes up for each red group destroyed, and down for each blue FAC destroyed the mission ends (and is lost) when the enemy reaches the center of the "main zone" (Kaspi in this instance of the mission) there is no way to win; just see how long you can survive =) The original work on the script was made possible thanks this other script, which gave me the ideas for the rest. The script uses the last version of MIST, whose authors can hardly be thanked enough for their astonishing work (Speed, a HUGE load of kudos to you, sir, for both Mist & the Slmod). TRIVIA: the briefing and all the in-flight text output is in French; you probably realized by now that English's not my native language ... DOWNLOAD: see attachments Feedback would be MOST welcome. As I said, this is a rewrite of a tested mission. Everything was OK with the previous version, but I definitely expect problems to arise with this one. I WILL fix problems, provided they are reported. Enjoy ! Best regards from Belgium :beer: EDIT 1: uploaded a *.miz with a leftover debugging unit ... :doh: EDIT 2: new version of the script: http://pastebin.com/bTHRYy9K HoldTheLine.miz

I should really stress out to anyone pondering about buying this that the 'issue' I had should absolutely *not* weight in the balance, it was but a feedback the the craftsman :thumbup:

Received mine today, and experienced a slight problem with the plastic screw thread (hope the term is correct, or at the very least clear enough). It was too large to fit the grey metal screwing ring of the stick, thus preventing correct fastening. Had to spend 2 minutes with a cheap knife correcting that, and now I'm wondering how I could even fly without it. The aforesaid little issue aside, everything is made of top notch quality material, and I really doubt I'll have any problem at all with it at any point along the line. Thank you so much for your work ! EDIT: too late (early) to post, sorry I butchered English, guys

Simple & dirty fix: assign the "brakes" key to something, and just before takeoff (or just after you've been using the toebrakes, anyway), click that key, or plainly depress the keyboard key. It will reset both axis, and off and straight you go ! :beer:

A bit off-topic, but I'm looking for a comprehensive list of what can and what cannot go into this "autoexec.cfg" thingy. I already searched the forum, to no avail, then the wiki, without any more luck. Do anyone know where such a resource can be found ? I probably missed the obvious, but I'm lost right now ...

Gods, I'm trying not to lose my temper here, but have you ANY idea the time it takes to make and support such kind of *freeware* app ? I had the exact same issue, once, the first time I launched the app, and then what ? Does it prevent the app doing what it was intended for, namely saving you lot of frustration ? Nope. How in heaven is it even conceivable to go on such a rage on someone willing to give away their spare time for the community ? Had a bad day ? What have you done to try and HELP solve the issue ? Ah, right, nothing at all. Then you just have the right to uninstall, and walk away, IMO. EDIT: thanks a lot for your time & dedication, icemaker !

Wow, that's just great, thank you SO much !

Not necessarily. All you need to do is parse what happened in the previous mission, and create a new one with the data. 15 seconds of CPU time between mission on average, so far. The randomness comes with a lot of pre-generated random events. One huge downside compared to Falcon is the impossibility to run a home-made server with hundreds of active units on the map. Units and groups have to be activated and de-activated based upon player proximity, and a hard-limit of units on map has to be set to prevent freezing the server with gazillions of things popping all over the place. Prioritizing is key. It just cannot be as "live" as the old Falcon one, but we could do something close enough, I think.

Not that hard IMHO. Keep it simple in the beginning, then expand over it. I'm busy right now with exactly that, actually. Based all of it on the Falcon 4.0 dynamic campaign (one of the best dynamic campaign engine ever made AFAIK), already have all the fuzzy logic written down, got the parser for *.miz files (in & out), and most of the rules (which are based on some kind of board-game). I won't say it was a breeze, but I'm expecting to release something solid in either a couple of months, or early 2014 (duty call from Augustus to December). To be quite honest what I'm missing right now (code-wise) is some way to parse the events in-flight, a HTTP renderer to display info for the pilots, and a bit of glue here and there. None of those should prove such a challenge as to put the project on stall. The whole thing is made with Python, and I'm far from being any kind of Programming-Guru, so it'll probably be quite opened for improvement ... and real basic at first, but one only has so much spare time =)