Drongo's Toolkit

[NacroxNicke 11]

Looks like there can't be two human commanders at the same time, one of the commanders doesn't get any squad to command neither markers in the map.

Anyway, I will take a second look at it

[Drongo69 117]

There will be an update released in the new year. A lot of stuff has been changed, I can't remember it all.

[kenoxite 156]

From time to time I like to come back to OFP and there's always amazing new stuff like this.

Unfortunately I've come across a couple problems when using this with the CWA version.

In the Command mission I can't spawn reinforcements, neither can the AI. It always displays this error:

Is there any way to fix this?

The CoC artillery doesn't seem to work in CWA either. In your missions the artillery option simply continuosly says "Artillery not ready" (paraphrasing) when requesting that option. In the CoC missions that come with the addon it just doesn't display the radio or IF menu, no matter what. If I force the IF menu in a custom mission (using [this, player] exec "\CoC_Arty\scripts\openmenu.sqs" on myself or any other unit) it displays this error:

I know it's out of your reach, but I just wanted to tell you about it.

Anyway, great stuff. I particularly enjoy the DSAI feature, so I can now use WW4 without relying on ECP.

I can't wait for the new version you have planned :)

Thanks a lot for keeping OFP alive and kicking.

[vektorboson 8]

As always regarding the COC UA-problem in CWA, may I direct you to my semi-official update: http://forums.bistudio.com/showthread.php?48537-Chain-of-Command-Unified-Artillery-1-1&p=1973165&viewfull=1#post1973165

[kenoxite 156]

As always regarding the COC UA-problem in CWA, may I direct you to my semi-official update: http://forums.bistudio.com/showthread.php?48537-Chain-of-Command-Unified-Artillery-1-1&p=1973165&viewfull=1#post1973165

Thanks, man. It works like a charm now.

[kenoxite 156]

I finally found a solution to the grouptype error.

It turned out to be a conflict between the (very ingenious, it made me smile once I figured out) way Drongo69 used to create the new groups and some of us who like to be one-shot in the head by keeping SuperAI turned on.

Let's see. The spawning script uses a dummy civilian as a buffer/carrier for several variables needed for the group that is going to be spawned. Mainly the side it belongs to and the type of group (saboteurs, mechanized inf, vulcans, etc). It does the latter by setting the skill level of the dummy civy to a given value that, by parsing it a couplel times for the desired effect, lets the spawning script know which type of group is the one the player or AI wants.

Problem is, when you have SUPERAI turned on all the AIs are given a skill level of 1, and it applies to both the existing ones and the AIs that are spawned at any given moment. That simple thing makes all this way of passing variables to fall apart, as the dummy civ always will have a fixed skill, so the script thinks you (or the AI) always want to spawn the same thing. In this case, being always the type 1000, it leads to nothing (an array of numbers instead of units), so the grouptype doesn't exist and hence the error shown.

Solutions?

The easiest one: turn the superAI off in your difficulty settings.

But if you (person who are suffering this problem) are like me and like to keep the challenge, or are a masochist, you'll have to follow these steps. All you need is a text editor of your choice, even Notepad.

In \DT\Spawn\Spawn.sqs change this:

_string = "[this] exec {DT\Spawn\Spawn2.sqs}"
_skill = _type / 1000

to this:

_skill = _type / 1000
_string = format ["[this,%1] exec {DT\Spawn\Spawn2.sqs};",_skill]

And in \DT\Spawn\Spawn2.sqs change this:

_type = (skill _dummy) * 1000

to this:

_type = (_this select 1) * 1000

Apply the changes to the mentioned files in all the missions in the Drongo's Toolkit package.

As you can see, all I had to do was to pass the desired variable in the call to the spawn2 script, instead of using the dummy's skill level as a "carrier". I also didn't want to add a new variable nor add to much to keep it simple, so that's why I still use the _skill one.

The most elegant solution would have been to be able to deactivate and reactivate the superai via scripting, but as far as I've searched that's not possible.

I haven't had the chance to test it properly, but in the command mission now everything spawns as expected. So far so good.

Anyway, I hope this helps others that were having this problem, like Faguss up there.

Edited March 7, 2012 by kenoxite
I meant "ingenious"

[Drongo69 117]

@kenoxite

I'm glad you're enjoying DT. I hope to release an update before too long with various tweaks and fixes (I got burned out on OFP a few months back and am just getting into it again now). Thanks for the tip regarding superAI BTW, I had no idea about that. One of the things I want to do is to make the spawning system more accessible, it is a bit convoluted right now.

Anyway, thanks for the feedback.

[kenoxite 156]

Thanks to you for releasing all this great stuff. I really appreciate it.

[kenoxite 156]

Lately I've been tinkering with your toolkit and having a lot of fun with it :ok:

For testing purposes I've reworked one of my ww4 missions (nothing fancy, your usual capture of Montignac) to work with DT and in the process I've found some problems and a fixed some. Here's the list.

ADDED:

(all this are just intended for my personal use, but maybe you'll find it fancy)

- Objectives/CLIENTmonitor.sqs : Flag poles automatically added to all the objectives. The flag changes when the controlling faction changes.

- AI/Take.sqs : COMBAT/LINE when dismounting vehicle.

NOTE: I tried to increase the distance from where the units dismount from 280 to 300+ (because of the increased WW4 engagement distances). Doesn't work. After a couple meters a get in order is issued. Then another get out after a couple more. Then repeat.

- Decreased default viewdistance to 1500.

FIXED:

- Typo in Objectives/victorycheck.sqs, line 8. RestVictory -> ResVictory (it was preventing a resistance victory)

- Typo in Objectives/Objective.sqs, line 27. _lastHeloBy -> _lastHeldBy (it seemed to be a harmless bug, though)

PROPOSAL:

- Prioritize the use of infantry for capture. Right now tanks are the first to go in, so in flag areas you have 3 or 4 tanks surrounding it which isn't only odd, it's also a tactical suicide (it's an antitank soldier's dream). I think armor should be waiting around the flag, covering the area, while infantry moves in and makes the actual capture.

PROBLEM:

- Excluded units are still given orders. Excluding the commander does nothing, he still goes into battle like the rest. For support units, if you call for them they'll go back to their empty vehicles and drive to your position. The problem here is that the vehicle uses to be at the starting point in the mission, so it takes forever to reach it and drive back. That's if they're not killed yet. Even adding " ? (_group in daiExclude) : goto "Loop" " to commanderreset.sqs doesn't help. I don't know what's happening here, as the code seems correct and all this should be working.

What worries me more is the problem described above.

You can have a look at a stripped down version of the mission by grabbing this.

EDIT: I just realized that I forgot to include the addon I used for the everon flag. The link is updated with the fixed file. BTW, the flag is the one posted here.

Edited March 15, 2012 by kenoxite
file fixed

[Drongo69 117]

There have been heaps of changes since the last release, I'm not even sure if I have fixed any of that stuff or not. I'll look at your other ideas. The AI scripts could probably do with a full overhaul. I am hoping to put out a new release next week.

BTW, here is the reinforcement dialog:

Edit: How are you adding groups to daiExclude? Has the array has been initialized before this takes place?

Edited March 16, 2012 by Drongo69

[kenoxite 156]

There have been heaps of changes since the last release, I'm not even sure if I have fixed any of that stuff or not. I'll look at your other ideas. The AI scripts could probably do with a full overhaul. I am hoping to put out a new release next week.

BTW, here is the reinforcement dialog:

http://img138.imageshack.us/img138/3035/reinf.jpg

That's great to hear.

Edit: How are you adding groups to daiExclude? Has the array has been initialized before this takes place?

In the example linked above I was including them directly in the AI\Start.sqs (I didn't added it to the preferences.sqs, but that shouldn't matter). That was the only place where daiExclude was defined, so it's not overwritten elsewhere. My daiExclude looks exactly like this " daiExclude = [evesupport1,evecommander] " and the units are given their respective names in the editor. I don't k now. Maybe I'm overlooking something extremely simple.

But, well, if you're releasing a new version soon I can just wait and try it again in the new one. If it happens again then I'll notify you about it.

WONKY MECHANIZED INFANTRY:

In the latest post about infantry mounting and dismounting continuously. It turned out to be something that happens to all mechanized infantry squads, so changing the distance from where they dismount wasn't the culprit of this behaviour.

The only solution I've found to stop all that crazy mounting/dismounting loop is to separate the vehicle from the squad and either issue a "get in" order to the infantry group or a moveincargo in their init. The obvious problem here is that the vehicle won't be used again by the squad once they've dismounted, so they'll capture the next objective on foot, defeating the point of this whole mechanized infantry thing.

AFAIK in your scripts there's only a dismount call in a couple places (take and defend, I think) so my guess is that it's a conflict between default BiS AI and your infoshare system. This is obvious when a dismount order is issued when there's no enemies around, but another squad in your side has spotted one.

Another thing that adds to the problem is that there's no "mount transport" script for the AI commander, so when sepparating the vehicle from the infantry group, once they've disembarked there's no way to make them work together again.

[DanAK47 1]

The only solution I've found to stop all that crazy mounting/dismounting loop is to separate the vehicle from the squad and either issue a "get in" order to the infantry group or a moveincargo in their init.

Would locking the vehicle solve this?

Edited March 17, 2012 by DanAK47
misformatted quotation

[kenoxite 156]

Good idea.

But according to someone in the biki: "If an AI group (eg Mechanized Infantry) has its vehicule locked with its crew in it, it will mount or dismount it anyway. But a player in this group won't be able to enter the vehicle."

So, it'd be a partial solution.

[Drongo69 117]

I assume that the mounting/dismounting loop is caused by default OFP AI being given a move order that is over a certain distance. Maybe if the group is given a series of shorter move orders to the objective, this problem can be avoided (though I am not sure of the maths required to do this). Another possibility would be to write some new scripts that detach vehicles when the troops dismount and then reattach them at the objective. The new spawn system is almost done, the AI overhaul will be next.

The new spawn system is simpler to use than the previous one. It used fixed arrays, for example: dtInfW1 up to dtInfW9 (meaning Infantry West 1, etc). This means that groups can be defined by placing them in the editor and running a script to automatically build the spawn array.

After overhauling the AI, I'll release a new version. I also have an SP/COOP mission using DT that I might release. My coop group have been playing it for over a year, it is good fun.

[kenoxite 156]

Mechanized Infantry Lunacy Fix for Drongo's Toolkit (beta 1)

and motorized infantry!

and also helos!

--------------------------------------------

This script detects any transport vehicle in a group and allows to keep it there or move it to its own group. If separated, the infantry will still be able to use it for transport, but the vehicle won't receive orders from the leader (not even if player is the leader). Anyway, as the move orders for groups are issued by the commander in DT this shouldn't be an issue.

In both cases (separated or not), once infantry disembarks it wont embark again until a given time has passed, making the mount/dismount loop less frequent, or inexistant.

When the group disembarks the transport vehicle can be stopped in place so it doesn't go into battle. So far it seems to only work for trucks, as APCs are still ordered around by the AI commander. The infantry leader will also automatically call for the transport when reembarking is reenabled, just to speed things up a bit and cut some stupid running.

There's also exceptions for when the transport is damaged or destroyed.

Those can be used to reassign the group to another transport or whatever.

This script can be initialized to any kind of group without problems, even groups without vehicles. So it can be used in the global initialization of groups of DT.

USE:

--------------------------------------------

Type this in the init field of the leader of a group or single unit or wherever you initialize your units:

[this] exec "dt_mechinf_fix.sqs"

Download the fix and a demo mission (mission requires WW4)

PS: The magic word was "allowGetin".

------------------------------------------------------------------------------------------------------------------

EDIT: Now that I'm properly rested let me expand a bit on all this.

@Drongo: Feel free to use, adapt, copy, ignore or whatever you want to do with this. My goal with this script was to showcase a way to limit the mount/dismount loop for mech and moto inf (using allowgetin) and offer a quick solution for anybody using the actual beta1 build.

It also does other stuff that you might or might not be interested in. I've included them because in my tests I've found they help mech inf to react faster and behave more properly.

By separating the vehicle (which is optional) the AI commander can be coded to handle the transports alone without worrying about the rest of the group, so they can be ordered to wait, move them to a safe place while the inf is in combat or whatever you like. And by automatically moving the vehicle to the infantry group after the "allowgetin false" is over the group can move faster from point to point, increasing their efficiency. While this is action is automatic an exception could be added when the player is the leader, to add a "Call for transport" action to their menu.

If you check the demo mission or look at the code you will also notice there's transport helos working. While they're not part of this script, I've included them in the demo mission and added a couple simple modifications to take.sqs and dismount.sqs. They handle exceptions for when typeof vehicle is in dtTypesTransportHelo (basically, increases dismount distance -as height has to be taken into account- and changes the group getout action to eject -you need paratroopers or give them chutes so they don't fall to death ofc-). As I'm using custom WW4 everon helos I also had to add them via add.sqs and include the transport type to the array concatenators in that script, which were left out by default.

Anyway, this script doesn't make mech inf (or moto inf or transport helos) perfect, but I think they work a bit better than before. I hope you find all this useful to some degree.

Edited March 19, 2012 by kenoxite
Added more babbling.

[Drongo69 117]

Sorry for the late reply. The spawning system is still not 100% functional (and I got side-tracked with another minor project).

@ kenoxite

Thanks for the allowGetIn info.

I am still working on improving the AI. Using some of the ideas mentioned above, I have changed the capturing AI. At less than 400 meters, every group exits Take.sqs and executes AssaultObjective.sqs. First it checks to see if it has any mounted infantry. If so, the vehicle stops and dismounts the infantry. The group then forms a line, and goes into combat mode. When it takes the objective, it executes Defend.sqs. I haven't written the specific landing scripts for transport helos yet. I am also planning to let assaulting units call artillery or airstrikes on an objective (though I am not sure to make sure they wait long enough to avoid dropping it on themselves).

Another change is that I plan to make the AI issue orders in staggered waves. So first the recon groups are given orders, then 30 seconds or so later the infantry, mech and armour, then the support groups such as SPAA etc.

I have also removed the "Populate" AI for now as I want to focus on getting the objective AI working properly.

[kenoxite 156]

Sounds fantastic.

I was also going to mention the preemptive artillery strike, but forgot about it. Anyway, it's great to see you're going for it. About the distance, maybe the commander should issue the arty order as soon as he decides he needs to capture another town, making a quick check for distance from the capture area to the friendly AI groups with "take" orders to see if there's anyone close the strike area. Say, about 700 meters, to account the "lag" from CoC from the moment the call for arty is made to the actual splash message, which takes forever. Or maybe adding a "pause" to close friendlies while CoC is doing its stuff. Just an idea.

The bits about recon first, etc, and the rest of features sounds great. That's exactly what I was wishing for, so I'm glad again that you're considering it.

TBH with all that you mention you're working on this is going to be even a sweeter script package. And I love the flexibility of this toolkit already. Being able to be used for simple things such as just dynamic speech, or simple capture/defend missions, or a pseudo cti style grand campaign. Keep it up!

Just one little thing: could you make it so the command and air support action menus aren't displayed when the player isn't a leader of a group?

[Drongo69 117]

I'm thinking if the commander AI puts targeted objectives into an array like dtObjectivesAssaultWest then any group that gets within 700 meters or so gets an order like WaitForAssault.sqs. After waiting a certain period of time for fire strikes, then the objective is removed from the array and the groups get given move/assault orders and proceed as normal.

Another idea I'm going to try is perhaps giving armoured units a "Follow Infantry" order in assaults to encourage cohesion. Basically I want the AI to appear a bit smarter without too much complex scripting.

could you make it so the command and air support action menus aren't displayed when the player isn't a leader of a group?

I'll make this an option.

Finally, I am going to make it so that AI artillery strikes can also use WP, ICM etc if the ammo is available.

[kenoxite 156]

Great. The simulation of "waves" the way you're planning will surely help both versatility and efficiency, while following the KISS principle.

[Drongo69 117]

Here is an interim release with various bugfixes and improvements:

• Reduced the font size in the personal menu
  
• Added dtExclude array to DT\Start.sqs. This array allows groups to be excluded from most DT scripts
  
• Changed the spawning system significantly. Each side can now have up to ten vehicle and ten infantry group types
  
• Spawned groups can now be easily defined in the editor
  
• Improved the mount command to allow mixed APC and infantry squads to work better
  
• Issuing a dismount order to a group will cause any vehicles in that group to halt and dismount all passengers
  
• Infantry that have a transport unit in their group will attempt to mount it before trying other transport
  
• Implemented waves with the AI commander: Recon, Combat and Support
  
• New AI type: assault objective.
  
• Divided spawn markers into two categories: infantry and vehicle
  
• Scattered spawning around spawn markers to reduce early game congestion
  
• Overhauled AI buying

http://www.mediafire.com/?qv3z6achdphcssb (~2.24mb)

Be sure to overwrite the old pbo files.

Please report any bugs. I have also removed the other test missions as I am currently focusing on the AI. The next step is to add more AI improvements and to improve the way the AI uses CoC artillery.

[kenoxite 156]

I haven't had the chance to test all yet, so take this as a provisional bug report.

BUGS

There's still these bugs/typos from the previous release:

• Objectives\VictoryCheck.sqs: "RestVictory" should be "ResVictory"
  
• Objectives\Objective.sqs: "_lastHeloBy" should be "_lastHeldBy"
  

Apart from that:

• Reinforce\Dialog\Reinforce.sqs: dtPointsW variable is assigned to all sides. Should be fixed with dtPointsE (east), dtPointsR (resistance) and dtPointsC (civilian). Right now only west can use those points.
  
• fwatch check error. The check for fwatch you've implemented doesn't seem to work properly. I don't have that file, so I get a "not found" error instead of a clean bypass (which seems to be what you were aiming at in the code).
  
• Error displayed sometimes:

  '_logic = "logic" createVehicle _pos|#|': Error Type Any, expected Number

  There's another error messg previous to this one, but it disappears too fast.
  

• onMapSingleClick dodgy behaviour. Same problems as in previous versions. 90% of the time I can't select units or assign orders. Simple process: start mission -> assign points (200 each faction) -> buy tank section -> open map and try to select tanks or give orders. Can't select, can't assign orders. The esc/logout issue shouldn't affect anything in that chain of actions, as I'm not opening the command menu in any step. Partial solution: use the camera option twice in the command menu. That makes it all work again, but it's not an ideal or a 100% solution. Sometimes that doesn't work either.
  
• mission.sqm: ww4_helper and ww4_warmy are not needed
  

SUGGESTIONS

• Some units still die upon respawning. I see you separated both vehicle and inf spawns to help avoiding that, but it still happens (with mech inf vehicles, I guess). Maybe inf should be given onhit/onkilled event for a few seconds to prevent them from dying, then remove it
  
• Add "assault/defend/move to" options to command menu. TBH I'd rather have just those options than all the stance, facing, etc that are now. After all, if you're a commander issuing those generic orders should be more than enough. In other words, make the command menu work for the player the same as for the AI. And let the AI then choose their stance, etc according to the situation. That said, there's very useful stuff now there, like the Land or dismount command, etc.
  
• Assign points for commander per each enemy unit killed or town taken (also, discount per each friendly dead or obj lost), and to the units that are close to objectives when captured. Using addRating and/or addScore (mp). Probably something you have in mind already but want to implement on a later stage. I thought it was worth mentioning it, anyway.
  
• Following the suggestion above, add a simple resource economy. Captured obj= resource points to purchase units. More or less like Warfare. Again, this isn't crucial at all, but it'd be nice to have.
  

I'll create a "city assault" mission with this version later and report anything new I find.

Good job as always, anyway.

---

EDIT: Tested it a bit more. Found just a couple things.

• Dynamic speech seems to not be working in this version.
  
• The "Menu" entry seems to appear twice when you're not in command of a group.
  

Edited April 20, 2012 by kenoxite

[Drongo69 117]

Thanks for your feedback kenoxite, maybe I should be paying you as a beta tester :)

As you can see, attention to detail is not my strong point. I have fixed the bugs you mentioned, with the exception of the "unable to select groups" error. I thought I had squashed that one, I'll have to do more testing. I have implemented a very simple resource economy based on the number of objectives held. I'm not sure I understand the "Some units still die upon respawning" bug, I haven't encountered this myself. Could you please explain in a bit more detail?

Add "assault/defend/move to" options to command menu

This is possible, but I personally like the command menu as it is now. If I feel motivated enough, I might make a toggle to include these options or the default layout.

Dynamic speech seems to not be working in this version.

It seems to be working for me. Note that groups won't say anything if there is only one member.

[kenoxite 156]

• Group selection. Well, I said "dodgy" and not "not working" because it DOES work, sometimes. So far I haven't tracked what exact course of actions make all this not working, but I'll keep testing that later. Funny thing is, the first time I used your beta 3 all worked without an issue. After the second relaunch (back to editor and preview) I started having that problem again. It's not like there's a correlation there, I don't think so, but that drove me a bit nuts. Why the hell did that work before and not after? etc. At first I had the impression it was CoC doing something funny, but that doesn't make much sense. What it seems to affect somewhat is using TACAIR. At least in one instance the mapclick thing stopped working after I sent an Apache away through that command window. I had to do the camera trick to be able to command inf again through mapclicks.
  
• Units dying. I mean that, sometimes, when spawning an infantry group I get the "MAN DOWN!" text/audio mssg. So my guess is that it's the vehicle of a mech inf unit running over one of those guys. If I'm not mistaken mech inf spawns in the infantry marker, not the vehicle one, so that'd make sense.
  
• Dynamic speech. I encountered the issue both while commanding (so, not in a group) and as a grunt in a mech inf squad in a custom mission I made later. Maybe I wasn't paying too much attention or was sleepy or whatever, but I swear I didn't hear a single thing, apart from the radio. Well, it might have been that I hadn't have it proprely configured. To activate the voice system I just need to set it to true in preferences, right? Anything else I should be doing?
  

[Drongo69 117]

Group selection

I've had this problem before, but really thought I had squashed it. I thought it had something to do with dtExclude in DT\Base\RegisterGroup.sqs. I need to test more and see what is happening at each stage.

Units dying

This is checked by DT\Base\GroupMonitor.sqs. It might be a delay in OFP recognizing that the "leader" of the group (ie. the spawn dummy) has been deleted. A pause of 5 seconds or so at the start of the script might prevent this. Unless there are actual bodies, I would guess this is the case.

To activate the voice system I just need to set it to true in preferences, right?

Yes, unless I switched it off while testing and forgot to turn it back on when I released it. The voices in my current version seem to be working.

[kenoxite 156]

Hi again.

Are there any planned updates, by any chance?

I'm currently working on a little mission where I've finally decided to use DT instead of waypoints and triggers, as it involved the participation of several squads in a particular assault. I'll finally make the player be the commander of a whole platoon, with all the freedom to plan the attack DT offers.

But the (my) main problem with onMapSingleClick keeps me holding back. Have you make any progress on that? Is it just the one having this problem (CWA related, maybe)?

Oh, and the problem with DSAI was my fault. While upgrading DT to beta 3 I forgot to add the ECP DSAI pbos to the DT addons directory :o

---

EDIT: Adding some stuff I've come across while making the mission I mentioned.

It's an assault mission where a platoon of VDV (3 rifle+BMD squads) assaults a rebel camp placed in a forest, the location of which isn't known (in the original version, at least). The only intel available is that it's "in that forest". The player is the assigned platoon leader (and DT commander, via init) and, for this version, all the waypoints for all the units (both rebel and russian) have been deleted, in the hope that DT would manage the AI, etc.

While previously I've revised some of your code to check for bugs there's a lot of stuff I still don't know or don't understand fully. So, lots of questions about basic functionalty of DT follow.

QUESTIONS

• Which settings would be needed to be set in Preferences for this particular mission? Currently the ones I have activated are: _command, _menu, _voices, _infoshare
  
• Does AI still need waypoints if Objectives is set to false? Looks like, as the AI does nothing even with _AI set to true.
  CORRECTION: I tested this by placing "objective" game logics while having _objectives deactivated. The capture and defense of objectives still work, but they don't trigger a victory/lose end (as expected, that's what I wanted). That said, the AI commander seems to react poorly and quite late to assaults in this version. But seeing that you mentioned in your latest posts that you're (or were) working on AI I guess this issue will eventually be addressed, if it hasn't already.
  
• In that case, there's no need to assign commanders, right? Not even the player?
  
• Does that mean that in this case DT is only used for platoon level management? (so, AI would still need waypoints set in the editor and such?)
  
• If I decide to use Objectives (which I don't, see below), how to integrate them with BIS objetive system so the briefing is updated when one is captured (via objstatus)?
  

ISSUES

• dtExclude and _AI: When _AI is activated in Preferences the player group is also given orders, even when player is leader and listed in dtExclude. Maybe already fixed in revised dtExclude?
  
• Vehicles and inaccessible areas: Mech Inf has troubles when objective is inside a forest. They try to keep going in without dismounting. Even if Dismount order is given in COMMAND menu they mount again automatically. More info below.
  

SUGGESTIONS

• Objectives: Assault/Defend only mode: Would it be possible to add a mode to Objectives where the attacking side doesn't have to have their own owned flags? I mean, right now a side without flags loses automatically. In this particular mission, giving flags to the russians would look out of place. That's why I'm not using them right now.
  
• Invisible objectives: Could the visibility of the objectives be toggled, to allow for objectives where it's exact location is unknown? In this mission the attackers should ideally only have an approximate idea of the area where the camp/s is/are.
  
• Infantry only areas: Related to mech inf and forests, mentioned above: Could there be a way to exclude player defined areas so mech inf AI knows when they have to go on foot (and their vehicle to wait outside)? Something like allowing the mission maker to place triggers, markers or game logics to indicate those forests or "vehicles disallowed" areas? --I know the simple, common sense, answer is "don't use mech inf when objectives are in forests" but, well, sometimes missions have multiple objectives and, anyway, this will give a lot of flexibility to mission makers regarding what unit types to use and where to place objectives. Also, my guess is that vehicles in general (tanks, etc) would have a hard time trying to achieve objectives placed in this kind of places that only infantry can access, and I'm not sure that's taken into account currently in DT. In this particular mission the idea was for the BMDs to wait in outskirts providing support fire while the inf goes in to search for the camps.
  
• Radio Operators: When dtHasRadio is false and dtRequireRadio is true the only way to use DT's command interface, etc is if the player himself has a radio equipped. Could be possible to allow access to the command system if ANYBODY in the group of the player has a radio? There's no point in assigning radio operators for the player's group right now, and it's a bit sad.
  

--

MORE EDITS:

ISSUES

• Invisible units and DSAI: Invisible units should automatically be excluded from DSAI by default. Right now, it looks like the islands in OFP are inhabited by the ghosts of drunk russians. You can hear them everywhere, but you can't see them.
  

SUGGESTIONS

• Timer to capture objectives: Set an objective as captured as long as it has been held for X amount of time. Right now the objectives are captured instantly as long as there's no enemies close. Forcing the attackers to hold the objectives for a given time would both introduce a nice dynamic to the capture system and give the defenders a better chance to hold the last objective.
  

Edited May 28, 2012 by kenoxite
some editing for better readability and some stuff added