I.C.E. - Integrated Command Environment

I.C.E. - Integrated Command Environment Project

Project Status:

I have a working alpha version of I.C.E. approaching beta stage.

Overall, the project is not complete yet and will take several more weeks to finalise.

However I would like to present a preview which may generate some useful discussion for design ideas and problem solving.

Progress: 85%

=====================================

Goals:

• 
  
• The goal is to create a central system containing various modules aimed at improving gameplay, where certain areas are lacking (either in realisim or interest).
  
• The primary focus is on providing a more extensive logistical support structure. It's secondary focus is on providing extended commanding options.
  
• It is not intentially intended to provide unrealistic/unfair levels of information, that could not normally be obtained by normal methods in various departments over time.
  
• It is aimed at larger scale battles, like CTI and long running missions.
  
• It aims to provide more communications and information between group members and between groups via requests and responses.
  
• Provide a common interface for the large selection of operations you see scripted: transport, arty, airdrops, airstrikes, position designations, commanding, etc
  
• Provide a MP compliant system (Dedicated server & C/S support, client broadcasting)
  
• Simply providing a more comprehensive and interesting environment and system
  

=====================================

Blue Force Tracking Module

Progress: 95% (code completed but not separated yet)

The Blue Force Tracking Module (BFTM) will be separated into a separate module which can be included in any other mission for tracking, without the need of the full Commanding Interface.

<image>

Functionality:

- group leader markers (with unit ID & unit strength)

- player/AI markers (with name or unit ID)

- waypoint lines for leaders and your units (with WP ID)

- TODO: might also show either all unit markers and/or lines for each selected group

- expected destination lines (which can be same as current waypoint or different if separate move command issued.)

Final version will allow these options to be turned on/off as needed.

=====================================

Commanding Interface Module

Progress: 90%

The Commanding Interface Module (CIM) is generally aimed at controlling operations of larger scale battles, like CTI.

It is intended to allow:

- control of other AI groups (SP & MP)

- commanding of MP player groups (via radio chat or instructions dialog and icons (to do) to indicate incoming messages)

The CIM is able to be controlled in 2 ways. Via:

• 
  
• popup menus only
  
  • all commands simulate radio comm's only. Groups must be 'contacted' before interaction, making this highly suitable for group leader comm's (rather than commander). (see screenshot)
    

  [*]the CIM dialog, which provides:

  • (screenshot) a blue force tracking map
    
  • quick group selection list
    
  • composition, threat targets and status details
    
  • (screenshot) map bookmarks
    
  • map icons & lines which represent: expected destination, location for next command, current group selection and move markers
    
  • a portion of the group commands which are normally only available to your group, can now be issued to other groups.
    - Eg: Popup-menus for:
    - (screenshot) move
    - Group waypoint management - (screenshot) (including current waypoint tracking on server)
    - target
    - (screenshot) mount/land vehicles/aircraft/statics
    - (screenshot) status/SITREP
    - combat mode
    - behaviour
    - speed
    - formation
    

To Do List:

- optimise 'calls' by utilising 'spawn' instead

- Add player led group handling (currently it's mainly AI) - Review

- Add Action menu, for things like: artillery

- SITREP - Add commander MP SITREP Request option - those who don't reply don't get updated.

- SITREP - Add various levels of reporting

- separate the CIM into 3 individual areas:

- commanding system

- blue force tracking/tactical display (info on map control)

- interface (allow switching between different ones, clean/PUM/CIM/MFD)

=====================================

Transport Request & Acknowledgement Module

Progress: 90%

The Transport Request & Acknowledgement Module (TR&AM) is aimed at improving logistics by ensuring you always have transport available (under normal conditions).

The MP version of TR&AM (screenshot) aims to:

- Prevent dumping of transport vehicles for single use deployments.

- Allow players to request transport from other players. Automatically relays current position and destination.

- Allow pilots and drivers to see a list of transport requests and acknowledge them.

The AI version of TR&AM (screenshot) aims to :

- Prevent dumping of transport vehicles for single use deployments.

- discourage respawning as sole means of restoring health by providing medevac

- provide simple AI transport for common purposes:

- insertion/deployment/paradrop

- extraction/RTB

- medevac

- field to field transport

Future ideas:

- provide AI transport when player numbers are low

- possibly disable AI transport once player numbers increase or enable if waiting times are too long

- restrict suicide respawns to only allow respawn back at main base. Prevent forward base jumping.

To Do List:

- Fill in data for MP TR&AM dialog

- Complete MP compatibility for AI version of TR&AM. Currently trialling:

- Jander's DTP (Dynamic Transport Project) or

- TJ72's Airlift scripts.

Future ideas:

- Extend this request concept to other types of requests or orders.

=====================================

Debug Output Console

Progress: 100% (except to do list)

This is a slightly improved version of the dialog than that found in the Dialog Framework Template, mainly in that it includes a server output log viewing.

The Debug Output Console (DOC) dialog provides:

- client debug log viewing (see screenshot)

- dedicated server debug log viewing on clients

- step 1. Request log from server (see screenshot) and wait a second or so

- step 2. Initial output response is a long single line. (Hope to improve this in future.) (see screenshot)

- step 3. View the details of that long line in formatted output. (see screenshot) - currently limited to 1 page

- global & public variables viewing (rather than logging them constantly, just view current values) (see global & public vars screenshots)

To Do List:

- server debug log: Work out a way to scroll formatted log or send a multi-page capable server log to client

=====================================

HQ Support modules

Progress: 20%

A series of support commands available from HQ for the whole team. Generally options you would not have available to you as a regular group.

Features:

- Recruit a soldier - (screenshot) with group size limits

- UAV radar - 95% done

- ground vehicle radar - 0% done - easy: modify UAV radar to do this

- idea: don't detect vehicles who's engine is turned off

- UAV/UDA camera - downward view - 0% done - seen some others released recently in community

- Airdrop requests - (screenshot) crates, landrover, PBX plus progress reports

- Artillery - currently using DTP

- Airstrike - currently using DTP

- more commander options. Eg: SAM site

To Do List:

- Determine recruitment limitations and spawn locations

- UAV radar - complete

- UAV camera - start

- Complete MP compatibility

- Add progress reports to all HQ Support options

- Add cancel ability to all HQ Support options

- support requests: MP version of calling support for: fuel, ammo, repairs, ambulance, medic

- Airdrops are currently dropping in a jerky motion on non local clients. Might be able to solve that by moving it to server or remove object until landed.

- Group command log for tracking radio commands issued to your group. Finding relevant chat orders in the chat log is a bother.

- Future: Create independent recruitment PUM for general use

=====================================

Various other modules

Miscellaneous options available.

Features:

- Team Status dialog - (screenshot) incorporated into PUM's rather than separate Action menu item.

- Configuration menu - (screenshot) "Backpack" (hide map objects), fix head bug, hide map markers, set view distance, set terrain/grass detail

- Debug menu options - (screenshot) sample commands to help mission makers and testers perform testing faster.

- Respawn Dialog included in mission (check if included) - It has been extended to include the ability to spawn inside nominated mobile spawn vehicles, on squad leader, in various base locations and the usual nominated marker locations.

To Do List:

- Combined group objective control module (CGOC) - 0% done

Benefits:

- leader/players can see what other groups current objective is, allowing combined efforts.

- This information may be provided via request or automatically via a dialog summary.

- fixes not knowing where the action is focused, both for your group and for the team

- players are not forced to focus on same objective areas, but encouraged to do so.

- basically present the leader with a list of available predefined objectives for selection

- you cannot leave base without selecting one

- deviating from objective area will result in some sort of warnings

- it could prevent objectives being too easy to change half-way through for an easier more convenient nearby objective, or if aborting, abort with another objective, like return to base to rearm or for re-enforcements.

- it should benefit players playing as individuals too.

- groups with common objectives could see other group leaders on map

=====================================

Downloads:

- There is no official completed project download available yet.

- If you wish to try out the progress so far, you can download a working alpha version, meaning it's not complete, not fully functional, not fully MP compliant and prone to problems.

- The project includes a demo mission to test the I.C.E. functionality.

Alpha version 0.102 - 22 Aug 2007

Alpha version 0.115 - 31 Aug 2007

Alpha version 0.122b - 29 Oct 2007

2009 - The latest version is now found included in the Merlin Porject, which provides a convenient way of testing the functionality, but will make it slightly harder to separate the code for private use.

Any suitable feedback and ideas are welcome.

(continued... boring stuff separated)

Potential Problems or Limitations:

UI Problems:

- Major inconvenience - Currently, the PUM that appears for the command interface often appears for the full PUM and vice-versa, after closing down a particular dialog in certain ways.

- PUM sometimes doesn't appear at all because main map or command map OnSingleMapClick gets lost. Use radio "Fix map click" to temporarily fix.

- No way to prevent closing a dialog when using Escape key to close a sub-dialog.

- Opening any dialog, especially CIM over the main map, causes the cursor to flicker due to the main map crosshair update. So just ensure the main map is closed first.

Limitations:

- ArmA has no getCurrentWaypoint command to correspond with setCurrentWaypoint.

- Might be able to work around this by manually tracking the current waypoint on each leader's client and reporting that to commander or all clients.

- Alternatively, might be able to find matching waypoint corresponding to "expectedDestination" result info.

- No guaranteed way to track whether AI have gotten stuck after having been given a command.

Bugs:

-

Player Usage - What basic things do I need to know to use this?

- activation keys/action menu items

- activate I.C.E. PUM/CIM/Debugs via 'T' (or TeamSwitch key) or (temporarily) via Radio

- closing dialogs

- some windows have a "[X]" close icon

- differentiating between AI only features and MP only features

- some attempt has been made to differentiate which options only operate for AI or players labelled as (AI) or (MP) respectively

- See "Potential Problems" below

- Use radio "Fix map click" to temporarily fix PUM's not appearing on map clicks

Future Plans:

(Removed for now)

Project scope, flexibility & performance details.

- Currently modules function for either AI only, MP player only or both. Eventually all modules should operate in all environments.

- Completing the MP client synchronisation should now be an achievable task. The majority of this is being achieved using processInitCommands, isServer & custom isClient.

- Attempting a fairly modular design, enabling options to be either turned off entirely or replaced with someone elses module to perform the equivalent function.

- No optimization has yet been done on speeding up the display of PUM's and possibly other areas.

- It's also a fully scripted solution, so no mods/add-ons are required.

Help Required:

- Project is currently limited to myself, so if anyone who wants to get involved, let me know by PM.

- developing, finding or incorporating community scripts for the various modules

- info on any scripts or projects which overlap with this one - better to use what's available than developing duplicate scripts

- advice on making it more modular - tips usually discovered when attempting to incorporate it into another mission

- feedback on user functionality or changes required

- feedback on bugs and problems

- further MP feature testing

- player and time restrictions. Defining rules and restrictions on usage, without making subordinates feeling left out by leaving all options only available to group leaders and commanders:

eg:

- who should be able to use commander option: arty, airdrops, etc?

- who should be able to call for reenforcements?

- how often should UAV scans be allowed?

- how often should vehicles respawn?

Similar Projects:

- CEX - Command Engine X

- DAC - Dynamic AI Creator

- SPON scripts (esp. Debug Log)

Credits/Script utilised: (some of these scripts may or may not be in final version)

- UAV code modified from: KP-CTI by granQ and kungtotte

- Dynamic Transportation Project - DTP (SP) code by Jander

- TJ72's Airlift scripts (if used?)

- Cheetah's GridRefCoords.sqf

- Dr Eyeball's Team Status Dialog

- Mr-Murray's arillery & other scripts (embedded in other scripts)

- Jander's arillery & other scripts (embedded in other scripts)

- MapFact

Not directly part of I.C.E. but might be required, currently just in test mission:

- KaRRiLLioN & norrin - Vehicle respawn script.

- Kronzky - Urban patrol script

- BAS f - noTeamKill.sqf

Full list still being determined. Will complete soon in upcoming version. PM me if it's clear I've missed one.

Definitions:

Logistics - (military definition) "The science of planning and carrying out the movement and maintenance of forces..."

WIP = work in progress.

PUM = Pop-up menu.

Mission Developer Usage - Incorporating I.C.E. into your missions.

Details still to be determined before final version.

- copy across I.C.E. folders and files

- modify description.ext

- modify init.sqf

- add any required markers, game logics

- set-up groups

- add radio/action menu items to activate I.C.E. script

Eg: _Action = _soldier addAction ["I.C.E.", "Scripts\ICE\ActivatePopupMenuViaAction.sqf", [ /* params */ ], 0, false, false, "teamSwitch" /* if MP */];

- finish mission as per normal

Sounds awesome! So this is sort of like CEX right?

Wow, this looks excellent. Exactly what i was looking for.

If you don't mind i like to throw in my 2 cents.

As i play often large maps with strong hierarchical structures (HQ, Support Officers and several Groups of Inf/Pilots), i would wish a feature that some features might be restricted.

Let's say i have a Mission which has a Leading Officer (does nothing else than set up strategy plans and commanding groups), a support Officer (coordinates pilots/drivers and supply requests as well as requests for insertion/extractions) and several fighting Groups which usually just receives order.

If it might be possible to build in some sort of "command flow" that would be really great.

Let me give you an example:

Let's say we have a Inf group near Cayo, cleared the area now wants to be extracted and return to base. So they open the I.C.E. and can select "Extract from actual pos" (maybe optional to place a LZ on the map) and then select a pos where to be dropped again.

So Commander receives the request, checks the settings (who, where from, where to) and can acknowledge or deny the request, by denieyng straight give new orders). When commander acknowledges air, the task will be given to support officer which now can assign the task to one of his pilots and this one will get all necessarly infos (waypoints).

I hope you get the point. It is some sort of "command flow" as we usually had the problem that the commander was overboarded with requests while still planning next steps, at the same time pilots needed to be ordered and son on. Such a system which allows a certain "flow of commands" would be really great.

Of course this could be optional, as it might be a very special and therefor rare case.

Myke out

Nice.

Will the different modules have an option to turn them off if not needed ?

Lets say the mission designer doesn't want artillery or airstrikes to be enabled. Is there a way like a global init which allows you to turn some functions/modules off ?

regards

ricki

Download available:

I have just uploaded alpha preview version 0.102 (temp 30 day link).

I've probably broken some things trying to rush this out today, but it should give you an idea of the final goal. Remember it mixes up conflicting features of: SP/MP/AI all together.

Expect some updates 1 to 2 times a week or so.

(Don't forget to use radio command "Fix map click" to temporarily fix PUM's not appearing on map clicks occasionally.)

@Opteryx:

I would imagine the CIM is obviously similar to CEX in concept. (Reminds me, I'll add a 'related projects' section.). I have only seen screenshots of CEX. I don't know what it's status is or whether it will be released for ArmA and whether it will support MP this time. CEX includes a RTS-style 'eye in the sky' mode, which CIM will not include. CIM is a quite a small module, making up maybe 25% of this project. Any public release info on CEX would be appreciated.

@Myke:

Thanks for that scenario. It got me thinking that it's missing some of that structure. Currently, there is no strict CoC structure enforced, but it's limitations actually produce a psuedo CoC: HQ can communicate with group leaders only. Leaders can comm with other group leaders and HQ. Subordinates currently have the same comm powers as group leaders, but the reverse is not always true.

Adding a "Group command log" listing all orders issued to your group leader might helps this particular problem. If you preview the project, perhaps you can further suggest a solution for that situation.

@ricki:

Yes definitely, you will be able to turn off any feature. Especially potentially 'unfair' features like arty, airstrikes, UAV, etc.

In the beginning, you can simply turn off a menu item by commenting it out or setting it's enabled status to false. Later I'll add a central location to enable these features. Once the project is fully modularised, you should also be able to delete the folder branch of that module too, to ensure it's not hacked for use and to save space.

<s>link is not working for me.

its loading for ages now ?</s>

yeah, got it now

I don't know what it's status is or whether it will be released for ArmA and whether it will support MP this time.

It will be released and it will support MP.

good work

Excellent initiative. I think you're on your way to making some great stuff.

I would like to provide a counter-argument however.

Please understand I respect everything you've worked very hard on so far. (I love your dialogs btw).

I think you are approaching things from the wrong angle. In fact, I think a majority of people in this community trying to provide a more cohesive and modular structure are doing things completely wrong (CEX included). You should build the framework before the dialogs. The framework should be based on communication. Once you have that laid down, the dialogs (UI, etc..) should fall into place. In fact, the comms should not rely on the UI at all. I should, as a mission maker, be allowed to create an action, a dialog, OR an automatic call within a script to perform the same function within said framework.

If you can get a solid way for the AI to talk to players and vice-versa, you don't need half the scripts you have created.

Dr_Eyeball

Im glad you are considering using my scripts for this project. I worked very hard to make the system as friendly to something like this (merge hybrid super type of mission) as possible and I am allways thinking of ways to make it even less of a potential conflict with other script modules. Im definetly one of those people working to make things more cohesive as Crashdome has said.

If theres any custom scripts or features you might need to bolt my script on the project more easily I am fully commited to doing so where possible. Meantime, Im going to chase any remaining bugs down so the script is even more stable and hopefully of good use to this project.

Quote[/b] ]In fact, I think a majority of people in this community trying to provide a more cohesive and modular structure are doing things completely wrong (CEX included).

You seem to know a lot about internals of other project, some of which are not even released yet .

While your suggestions are all sensible and would be an ideal situation, in practice there is always some interplay between the core and the interface. From experience I would say that the interface is the more limiting factor, and I would not want to spend my time on some framework feature and later find out it is diffult or impossible to acces from the interface. Also, as a scripter I find it more fun do work on both simultaneously, as I can immediately see the results and test them.

Dr_Eyeball, keep up the great work. I wish more people would work in this field, as I think it has the biggest potential for providing new game experiences in ArmA.

Quote[/b] ]In fact, I think a majority of people in this community trying to provide a more cohesive and modular structure are doing things completely wrong (CEX included).

You seem to know a lot about internals of other project, some of which are not even released yet   .

I go by what I have available to read about I'll admit I play the role of investigative reader, but I can conclude certain facts to be reasonably true. I am merely pointing out an observation and suggesting a perspective. I certainly do not mean to put down anyone's work.

Quote[/b] ]

While your suggestions are all sensible and would be an ideal situation, in practice there is always some interplay between the core and the interface. From experience I would say that the interface is the more limiting factor, and I would not want to spend my time on some framework feature and later find out it is diffult or impossible to acces from the interface. Also, as a scripter I find it more fun do work on both simultaneously, as I can immediately see the results and test them.

Points well taken, but it seems we have more interface related progress than otherwise (in terms of immediate usefulness). From an engine development standpoint, what's easier to modify should the need arise? the core features API or the interface API?

Thanks for the support guys. Next update should have a portion of it functioning in MP properly on dedicated server (at least CIM so far and maybe TR&AM).

@CrashDome:

Spot on. I totally agree with you. If it can't be modular and you can't replace the UI, then it is destined to fail. Hopefully, I believe, it will meet those requirements since that's part of the design.

Anything that was activated via a PUM item (which is the majority of it), should be able to be directly transfered into an Action menu item as is. (It might not auto work with Radio menus, since that auto broadcasts and might cause duplication.)

The whole idea behind the PUM system was that I was running out of room to add actions in a reasonable usable manner to the existing Radio menus and Action menus.

Given that incorporating I.C.E. into any mission would generally require you to delete half of the non-relevant functionality (eg: MP only, AI only, realism only, etc), it should then be likely that the remaining required functionality could be inserted into a smaller custom dialog, Radio menus or Action menus a lot easier than with the full demo system, since there will be less options.

You'll also notice there are sometimes 2 UI versions of each system. Eg:

1. TR&AM (Transport Request)

2. CIM (Commanding Interface)

Each of these systems can be used either via PUM's only simulating radio comm's, or via their specialised dialog simulating electronic devices, like MFD's & GPS positioning.

Since the PUM concept can be transferred to any other UI concept, it should show that it's not tied to any UI system.

So it's good to hear these concerns to ensure critical aspects like these are not overlooked.

@TJ72:

So far, I've been using the Dynamic Transportation Project as a place-holder to demonstrate the transport requirements but which are limited to SP only. (I asked sickboy to release his MP converted version, but he hasn't replied yet.)

As far as I understand, Airlift scripts should be:

- MP capable,

- allow multiple transport vehicles to respond to separate requests,

- allow departing/incoming vectors.

This would be ideal.

The issues I'm having are: (note: some of these may well be caused by my own misusage.)

- two gunner positions requirement

- the map clicking seems to be timer based, which is a problem - once it's selected, it should stay

- it doesn't work for deployment/insertion

- it seems to sometimes delete the wrong actions

- SQS syntax, making further enhancements difficult - I might need to convert it over to SQF

- setup requirements, especially once combined with a larger project like this - simply need to minimise it

- whether it will work with respawned vehicles

- knowing all it's usage permutations

Extra features I'd require are:

- progress status reports

- reaction to hostile fire or AA zones (since it will be assumed that the transport pilots are non-combatants and will not risk hostile extractions - to keep it simple and sensible.)

But to be honest, I've spent minimal time on AI Transport so far, so there's a long way to go with that aspect. Still trying to integrate it now. I'll PM you about this when I get more into it and find out how it works.

I wish there were a lot more of these stand alone scripts with full MP capability. It would reduce this project's time considerably.

Awesome work, Dr_Eyeball

This is what many people searching for. Thanks

I would like to use the mobile respawn, but i can't unpack your mission for some reason

@LtCmdrBoon:

I've sent you a PM with a rar file instead plus cpbo info.

Update:

While I'm here, I may as well provide a small update. Sorry for the lack of updates, since I've been busy bloody painting for 7 days. I would have progressed further otherwise. But I've still made some interesting & unexpected changes and progressed about another 5%.

0.115 changes:

The changes have primarily focused on CIM (Command Interface module).

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">- started adding TJ72's Airlift scripts for testing - not integrated yet with waypoints and menus - it has a small side effect which removes the ICE action menu.

- sped up the PUM display time - probably 2-3 times faster than before (but will improve a bit more later)

- CIM - most of the main commands are now starting to become MP compatible on dedicated server

- some people were asking about this, so at least now you can start to see how it will behave.

- CIM - started adding targets info to "Group Details" box and to Targets menu

- CIM - added "Waypoints, bookmarks, group locations" listBox for quick navigation (see image below).

- added CIM waypoint menu which operates on the selected group

- waypoint menu added/moved to CIM for _all_ groups (not just your group)

- it draws (blue diamond) icons for the group's waypoints

- it draws (blue) lines joining the waypoints on the map

- it draws a (green) line to it's current expected destination

- waypoints & bookmarks menus reworked

- waypoint menu redone - no longer dependent on "current waypoint" which made it difficult to use for planning

- both now show the town name & grid ref coord in the menu - much more meaningful and easier to identify

Can't remember any more changes.

Screenshot

It doesn't look much but getting this part working is a prerequisite to getting some of the other stuff completed. And since BIS haven't provided suitable "Get" commands for all of their great "Set" commands, makes our job even harder requiring us to write MP/multi-group compliant work arounds. (eg: getCurrentWaypoint, getWaypointDescription & others).

Download: <a href="http://www.uploadpower.com/en/download.php?id=8349D80F1" target="_blank">

Alpha preview version 0.115 (PBO file)</a> - 31 Aug 2007

This version may be a bit untidy with debugs galore, etc, and not properly tested yet, but I'll provide another quick update in a few days once this current stage is considered complete, stable and tidy.

Any updates for us, Doc?

Apologies for the lack of updates. I should have released another alpha version a few weeks back, but got caught up in side projects. So I'll give you a quick progress report instead.

Progress report:

The bad news is that my 8800GTX video card blew up, so I can't test anything nor get updated screenshots at the moment until it's replaced.

The good news is that I should be able to release a (beta?) version in about 1-2 weeks.

The whole project won't be complete, but the CIM (command interface module) will be completed to a usable functioning stage, providing control over AI mostly (rather than players) to begin with.

This is a very old screenshot (which has changed since then and shows both sides for testing) of what the initial interface will roughly look like. That'll be overhauled again in future.

screenshot

It not only shows waypoint lines, but also includes expected destination lines (when no waypoints are used) created by move (and various search) commands, which also shows formations. I find this rather nice and has proven to be a useful AI debugging tool as well. Add this to a few missions and you'll be surprised what you discover.

I started working on a MFD (multifunction display) console which is functional but incomplete, but I'll have to delay that for a while. Eventually it will be an independent MFD template where you can add your own MFD graphics to it instead.

screenshot

New features & changes:

- expected destination lines (for both AI & players)

- more interface info

- finished most of the issued commands

- it has been heavily cleaned up, folders structure reorganised and separated from the unrelated mission (from earlier alpha release).

- MFD

I can't remember what has been added since last time, right now. I'll edit this post if I think of anything important.

Quote[/b] ]So far, I've been using the Dynamic Transportation Project as a place-holder to demonstrate the transport requirements but which are limited to SP only. (I asked sickboy to release his MP converted version, but he hasn't replied yet.)

The DTP script was converted by me to SQF and made multiplayer compatible, but there were quite some bugs and when I look at it now, I have a big laugh and would redo it completely from the ground up, if I had the time.

I can share you what I have but I can not guarantee anything to work or otherwise be useful.

I might however consider creating a new system for it, which you can use as module and I can use in my own stuff, unless you got your own stuff going in the meantime

Thanks Sickboy, getting your DTP code changes would still be handy if available, since I'm yet to start on that module seriously. It's a long slow process with delays unfortunately. (Hopefully all will be completed before ArmA:2 though! )

Given your past comments on the conversion having bugs, I did not intend to use it as it was, but wanted to follow a similar process of converting it all to SQF and completing the MP compatibility side of it. Browsing the code myself, I saw a lot of redundant and repetitive code in it. I wanted to remove the spawned scripts as well. I've been looking for as many shortcuts as I can to complete this project, so any reference material or completed scripts would be handy.

If you do plan on writing your own system for it, that would be great. I've got a particular set of requirements though. Given that others are still working on similar transport scripts, this module would be the last part of this project to be worked on, since I'm waiting to see what comes of those first, to prevent duplicate efforts. So there's still plenty of time to decide on the best approach.

This looks very interesting

Will the idea be to slot it in alongside existing missions / create missions around this?

Does it have a commander type dude, or is it more like a squad leader requests something, and then to all parties concerned get a message, and choose to accept etc?

Either way, I like.

i cant help you with the modding but i have a creative mind for missions. but inturn of help, i will need some1 to help me with the scripts.

oh, make it simple and make it so that the ai is given objectives, rather then the actual orders (so if you order a squad to move to point B, mr. stg will say: blue team, cover from point C while red team charges to point D. then cover red as it moves to point E ect")

@LtCmdrBoon:

Usage:

Yes, the idea is to simply slot it alongside existing missions. Basically include the required files, perform the initialization calls and it should be ready for use.

Commander:

You should be able to setup any type of chain of command, with no depth limit. However that's currently manually done by the mission designer (i.e. init each client with their own level of authority).

So you could have:

- a commander controlling many groups

- a commander controlling many leaders, who in turn control many groups each

- no commander, but have many leaders controlling many groups

As far as requests to superiors go, that's not implented yet, except for simple replies and support requests to an AI HQ. But that's being planned, along with confirmations and acknowledgements. It'll probably be very similar to the Transport Request module.

@THE_BLITZ:

I doubt this project will incorporate any form of enhanced AI. That example sounds a bit like precise SWAT tactics, unless I've misunderstood. My main focus is on vehiclular-type combat and logistics.

As far as I understand, projects like "ArmA Group Link II Plus", "6thSense.eu AI Manager" and others, already do that sort of thing, but I'm not certain of their scope.

You may also be able to partially achieve some of that using waypoints.

I've uploaded a 3rd alpha version. See first post for links.

It's finally approaching it's completion.

I need a little more time (1 or 2 weeks) before releasing the beta version.

Screenshot image

Notes:

• 
  
• Since the last alpha version, the structure has totally changed. Removed 2/3rds of the unrelated mission code. Obviously lots of new code. Significantly tidier.
  
• The MP Transport Request & Acknowledgement module is now functioning. I'll probably rewrite it in future though. Create a better interface for it and move the client side code to the server.
  
• The MFD buttons are not fully integrated yet. It still uses the popup menu for now. Click the 'A' button to zoom to full screen. Found 2 bugs relating to resizing a dialog which will need workarounds (ListBox & RscMapControl).
  
• New commands & options added to popup menu
  
• First post updated with new section & updates: Blue force tracking.
  
• Blue Force Tracking, Commanding Interface & Transport Request modules are probably the most interesting parts to explore for now, since other sections (like HQ Support) have not really changed in this update.