TangoCharlie

Thanks for the update Deadfast, nice work! :) To aid my own laziness with the development of a few new multiplayer missions, I have finished developing my LazyTasks script. If you don't mind, I have linked below a link to the script. LazyTasks, for MultiTask ================ If anyone else is looking for simple and/or lazy creation of tasks with one line of code, this might interest you. I figure this might be of use for amateur mission makers or scripters looking to use tasks with the minimal of fuss. It eliminates the need to get involved with all the complexities of the code and the various tasks commands. Particularly, a certain individual who derailed this thread and had a fit of frustraton may be the ideal target audience... ;) LAZY TASKS script ================= - An easy 'MultiTask' handler for quick and lazy task management in m/p or s/p. - This script by TC. Heavily dependant on the MultiTask code by Deadfast. - v1.2, 19th Feb 2011 * Who is this script for and what does it do? --------------------------------------------- - It allows for the super easy creation, assignment and update of tasks. - Requires no knowledge of the various separate BIS or MultiTask commands. - Simple one-line call to the script for all task commands. - Uses the power of Multitask to make tasks sync in multiplayer & JIP. - No expertise required with arma scripting - can be called from the editor. - Task information is stored in the stringtable for easy content editing. For example, using the script you can type out your task information in the stringtable file using your favourite text editor and then with ONE command: * Create a fully featured task: [1, "rescuers", "Assigned", true, true] execVM "LazyTasks.sqf"; - Create a new "assigned" Task1 for the "rescuers" squad (which includes full description, title, hint, map marker and caption), will set it as the current task, and fire an additional hint popup. * Update a task: [1, "rescuers", "Succeeded"] execVM "LazyTasks.sqf"; - Update Task1 as "succeeded" for the "rescuers" squad. Further / full information can be found in the README (click). Included are full installation and usage instructions, which I have tried to keep as simple as possible. You can DOWNLOAD the script here (click). The RAR file includes the Readme, LazyTasks 1.2, MultiTask 0.2.1, 'example use' file, an example stringtable.csv and a very basic example mission demonstrating it's use (LazyTask-Example.Takistan). This may seem pretty pointless for advanced users happy to manually code in all the task information, I wont deny. But if you are phased by complex scripting or if you have a LOT of tasks (as does one of my current projects), this may make life that little bit easier.

Oh, excellent, appreciated. I hope I haven't unnecessarily made you update the script on my account. :o EDIT: Fixed! After a brainwave when digesting the above ramblings, I came to realise that upon re-commit'ing a task, it will re-parse the entirety of the task including all text, not just the changes. And it would seem it retains all the referenced variable names, so hence upon running my "successful" 'if' statement it no longer held any record of those strings. Simply by moving the string-table -> var statements to the top of the script, the taskState and taskCommit was able to rebuild the tasks and sync them in their entirety with all the expected text. Thanks for nudging me along in the right direction.

Wow, that was quick response - thanks! With regards to language and localization, that isn't really a major concern (yet). The main reason for using stringtables is lazy / readable editing of the task content. I'm probably a bit out of my depth understand the scope of variable declarations, certainly in a client/server environment. However, this said, the "assigned" creation code you quoted DOES work, whereas the simple "succeeded" code (which doesn't reference any of the highlighted _task_* variables) DOESN'T? However, even though I may be missing the point, you may have flicked a switch on in my head in terms of thinking about the locality and scope of variables. EDIT - Additional: Made a quick empty mockup mission in editor to test with and demo the problem (alternatively, separate files here). Most interestingly, using the radio triggers if you create task 1 then task 3 (alpha, charlie) they both work fine and stack up, but if you then radio bravo to 'succeed' at task 1, it will locate the correct task and make it 'successful' but just the other fields are lost. I think this may be what you were trying to tell me, but I cannot understand why just updating the status requires the task to recall how the other fields were constructed. Surely it just relays the command to all clients to "turn task1 green and signify it is successful"? My belief was once the Task object had been constructed using the script it is 'done' - however, is it that the Task object retains all the component strings, variables, references and such bundled up, and this is why updating it causes it to be lost like you say? Think I'm slowly getting there but still so very confused! :( Still, thanks for the pointers. Slowly the cogs in my brain are turning...

Hi Deadfast, I have experience of using your script successfully in my last mission, albeit manually typing out all the DFS_ commands in the mission file or seperate small SQF files. Being a fan of the script in my next mission design I am cobbling together an even lazier 'framework' for adding / updating tasks, which compliments your script and the use of stringtables. As I begin to use MultiTask more I am seeing some issues. For example, I can create a fully fledged task (with marker, status, description, title etc) which works fine and seems to sync well. However, upon some operations such as simply updating the task state for an existing state (to "succeeded", say) it seems to wipe out the task ("any" replaces all fields ingame). I am no scripting wizard, but would appreciate it if you could look over this simple script and explain why updating the task causes mayhem: My script Example use in a mission Example stringtable As you can see from the simple script, to update a task with "successful" it does the same DFS_setTaskState + DFS_taskCommit + DFS_taskHint as "assigned" (creating the task), yet one works, one does not? Whilst my expertise is limited, I have also encountered similar issues in my last mission when it came to updating task state and hinting, so not sure if there is something I'm doing or if there's a bug? Appreciate any feedback / ideas. edit - Oh, and thanks for the awesome work!! :)

Gah! Sorry, it would appear my colo server / host has taken a brief absence from the internet. Also why the images are broken. Should be resolved by this evening (UK GMT) when I get a chance to take a look. Perhaps I will upload it to a mirror for just this kind of reason... :) EDIT: FIXED - download now available, see OP. Stupid apache webserver crash...

Version 1.06 released to address a few minor bugs and tweaks I wanted to implement after numerous playthrough's. Changelog and download link in the OP. I hope this is a final release of Coastal Raid. Enjoy!

These were really good fun scenarios of just the right length for small groups, and has just the right amount of pacing and action. Great atmosphere and 'drug cartel' feel to it. Makes great use of the Lingor island and will definately be staying on our server. Nice use of sound samples and clear briefings, which add to the 'feel' with satellitte images etc. That extra bit of attention goes a long way. I'd actually be keen to see more in this series as a larger drugwar campaign! Only minor criticisms were: - Mission 1 and crossing the river after destroying the boat - tried at thinnest point but we still lost our weapons by the time we crossed. since then we've resorted to driving around the inlet, but this seems to be not the intended route judging by enemy spawn locations. - LAW soldier always starts with a LAW launcher but no M136 rockets. And there aren't any in any of the crates. You can access a few in the briefing Gear screen if you remember, but that's it - and many people won't know / check. - Dying in mission 3 with the satchels, respawning and failing to recover them from your corpse means that upon arriving at the drug factory you are left with no means to destroy the building than go alllllll the way back to the start (guh). A satchel crate nearby may be helpful here. - Bagpipes (lol) and outro length (long flight path just to reach a random ship and credits to roll on for some time, certainly mission 2).

Really looking forward to playing this when a non-ACE version lands. Looks really promising.

Can someone confirm that ACRE (1.1.1) does work for local player hosting a coop game? Despite receiving no errors, and having updated all components, addons, plugins etc and receiving ingame CBA / transmission graphic / headset confirmation - nothing seems to work. Do player hosts have to do anything special? (I can confirm our setups did work when connecting to a acre dedicated server recently, and we've avoided all the common pitfalls like run-as-admin etc).

Okey. Probably useless to you at this point, but I have assembled what you requested anyway, not that it seems to show much. You can grab a screenshot and the user-profile config files from my latest clean install HERE. Other info: Vista 64 SP2, Steam based Arma2 + OA installs. Very, very odd issue or bug for sure. :confused:

Yep, CO is definately selected. And as i say, the modpath looks as I would expect (having familiarised myself with the necessesary CO'fication of Steam OA): Presently, at the bottom it shows: "-mod=D:\Games\Steam\steamapps\common\arma 2;Expansion;ca;@acre;@cba;@fallujah1_1;@jayarma2lib;@lingor;@okt_noblur" "-name=TeeCee" -nosplash -maxMem=2047 -cpuCount=4 -exThreads=7 ...with "D:\Games\Steam\steamapps\common\" being my steam app root. Testing further, even selecting "Arma II - OA" it STILL loads Arma2!?! I have: - Uninstalled, and ensured c:\progra...\sprited machine\.. was wiped clean. - Cleared out C:\users\<me>\appdata\local & roaming of "sprited machine" saved data files - Reinstalled using download from your site in 1st post - Re-setup the app double-checking exe location paths etc - Identical behaviour - any option loads Arma2 irrespective of dropdown choice (and even if I point the arma2 exe at the OA one...). The main app claims to be v1.4.0.0, but despite the clean reinstall I can see that in: - "Help - About", it reads 1.3.3.0 - <appdata>\local\spirited machine\ , it reads 1.3.3.0 Is that normal? Are there any registry entries that need clearing? Why / how else is this application finding my arma2.exe, even when I trick it? Can I provide any form of debug / error / test files, or further info?

Spirited Machine - a little help please if possible. I have just downloaded and installed your launcher (v1.4.0) and configured it with my Steam-based Combined Ops installs and mods. However, despite the summarised launch line at the bottom looking fine, it insists on loading Arma2 (not OA engine / combined ops) no matter what I do. I even changed the "Arma II" path from the A2 executable to the OA one to trick it, yet somehow it is still loading arma 2 1.08?!? I am at a loss as to 1/ why it is doing this, and 2/ how does it even know what/where to load arma2 having reconfigured it and hidden the path? Is this a known issue for the latest steam versions? Any workarounds? Unfortunately the launcher and its handy grouping features are rendered useless to me as it plain refuses to work. :(

The biggest show-stopping bug is when you 'win' and clear all the caches. It attempts to enable a 'superman' mode which just sends everyones PC's tits up and locks you out of the menus - you can't even return to the menu / quit out. The only way out is to abruptly Alt-F4. I'm sure this 'feature' was for debugging or messing about anyway - can this be axed and just end the game instead?

Bloomin choppers! :p With the feedback from my buddy, I changed the littlebird to be "on demand" now via radio, so the specops snipers can make their own judgement call when it is safe to call him in. Hopefully that will negate the kind of crazy scenario you describe, so do update to the latest 1.05 download. The respawn is auto-moved to the relocation drop zone at this point for safety should such an event occur, like dumbass pilots crashing or getting sniped. That bit is intentional to stop units being marooned. Glad you guys are enjoying it. I've pepped up the ending a bit, so try it out! :)

Hehe, ta ... I think :-P Saying "best mission of the year" on 1/1/11 hadn't gone unnoticed, lol. Unfortunately i just had to re-upload v1.05 due to a last second couple of issues (now also added to changelog). That realllly should be it now... please... hopefully!