Spooner

No, I haven't even tried it in MP. Another thing I should have clarified. Sorry!

Huh? Asking BIS to release more patches than could be necessary? OFP got to 1.96 and Arma got to 1.16 (and is still going, since last release is beta). If you think that Arma 2 won't get patched up to at least 1.10, then you are a crazy banana

In 1.01Final: Yes, the sub-commander can't command his subordinates for me either. If the top-commander gives orders to sub-commanders, they sometimes move and sometimes not (they never moved in 1.01beta in my tests). the subcommander's own subordinates never move. However, as in the previous version, the sub-commander does not have his own group appear, since he is being controlled by his own commander. This implies to me that the structure is correct and that the HC module is correctly recognising the chain of command; just not working with it correctly during the game ;) Sorry that I gave people the idea that the HC system worked. I was mainly just wanting people to see a more complex example mission, rather than just a simple example in a screenshot, which would take a while for everyone to replicate and test (I know I kept accidentally using group links rather than sync links, since the HC modules kept auto-grouping with each other!). Gaia said next version and not next release. Thus, probably was meaning 1.02, not 1.01 final.

You have some good points there. I am inclined, however, to give the squad leader the option to attach a HC subordinate group that would become a new team or detach a team as a new HC subordinate group. Again, this is an option that is already feasible to add to the current systems we have been given, whereas asking BI to do brand new work is considerably less likely to produce results.

SPON components use IDD from 72000-72012 if I remember correctly. I just picked a big number and hoped other people wouldn't pick the same one (not ideal, but really we should assign IDD ranges at OFPEC associated with a tag).

Anyone documented or documenting the new dialog config? Save me doing it.

@DreDay: Since HC is largly soft-coded it doesn't matter if BIS don't ever finish/fix it (as long as the SQF hc* commands all work properly). The community can finish the job :D I think that, for me, this is the key improvement in A2. The new systems are mainly scripted, so we can modify/disable/enable/extend/fix them to our heart's content!

I ran a very CPU intensive script (specifically dynamically loading Rahmadi height-map data into A2 using Dynamic Terrain tiles) on my quad core and saw a high of 60% cpu utilisation. This means it is operating on at least 3 cores and this without there being any AI on the map. Bear in mind, though, that at this point the game freezes for about 20 seconds while processing hundreds of thousands of height points and animating the tiles to take on the correct shape, so it is an entirely artificial situation. Still, this might give us hope for utilising quad core fully (if the engine+scripts can use 3 cores, as in this example + 1 core for micro-AI, that is all 4 cores as far as I can tell). Q9300 quad@2.5

Since synchronisation is now very much more important than before, I think that might also benefit from a mult-syncing ability. I don't think it is close to an important feature though, so I'd ask for it around 1.04, if not later (plenty of critical bugs to deal with for 1.01 and 1.02, if not further).

Not being able to command them to get into other vehicles is obviously a bug (or at least an oversight), not strictly a limitation of the HC system. Even if BIS don't think it is correct to be able to do this, there is nothing to stop us adding a "get in" context option when you hover over a vehicle, just like you get an "attack" context option when you hover over an enemy unit. Try changing the fire-team system (a1 or a2) even one iota and you'll realise why, even if HC isn't perfect, it is more powerful and has massively more potential than that old hard-coded system! For example, I'm sure that if CEX has any functionality greater than HC, then that could be added to HC rather than having to have a whole CEX system running in parallel to HC.

No, they don't, because there is no reason at all to be able to do this in A2. I am sure that this is one of the reasons they actually bothered with this HC system (i.e. because the A1 teams system was extremely limiting). If you want to do this, just set each fireteam as a HC subordinate group to your squad leader group and you can change individual formations, etc, since they are their own independent group which you have complete control over in the HC interface.

In truth, I haven't had the opportunity to play a decent game of MP to have actually used them. More importantly, HC is broken in MP, I think. My wild assumption is that the Commander channel allows you to talk to your HC commander (they would reply in their Command channel) and that Command channel talks to all leaders who are your HC subordinates (they would reply in their Commander channel). At least, that is what I'm hoping, so don't take this as correct on any level!

Example mission and screenshots for a more complex example using multiple levels of HC command hierarchy. I didn't extend command hierarchy down into fireteams in the example (I have a company and two platoon commanders here), but they do work and are infinitely better than using the old fireteam system which was very awkward. You also get much better on-map control which is closer to a good RTS game in versatility (add chain of waypoints, select own and get context-sensitive attack option when hovering over enemy, etc). Although buggy, HC is the system that will make command a pleasure rather than a chore and is 10x better than PR for describing a hierarchy, even if Arma1 was terrible at it. Also, we have built-in VOIP/chat command channel now, which people have been asking for in PR for about 200 years ;) And commander channel, so we catch up with PR on that too.

You seem to be able to do that; you can have any number, mix and type of units in an extended hierarchy The only issue I've found though is that you can't tell a subordinate to get into the vehicle owned by another group (even if that transport vehicle is the only thing in the group). It isn't that they refuse to do it; you just never get the option highlighted in 2d map or 3d world control modes. If you teamswitched into the leader of the group that wanted transport you could order your men to get into a transport in another group though, so it isn't anything fundamental. May be an undocumented HC feature or something you need to configure as enabled as well. Who knows at this point? I think there may be a general support system as part of SecOps that may offer you specific support tasks (like air strikes, repair and medivacs) if you don't want total control of the units though. Not looked into that to be sure (and I may be totally wrong in that).

You seem to be able to do that; the only issue I've found though is that you can't tell a subordinate to get into the vehicle owned by another group (even if that transport vehicle is the only thing in the group). It isn't that they refuse to do it; you just never get the option highlighted in 2d map or 3d world control modes. If you teamswitched into the leader of the group that wanted transport you could order your men to get into a transport in another group though, so it isn't anything fundamental. May be an undocumented HC feature or something you need to configure as enabled as well. Who knows at this point?

A reasonably complex HC example (demo and screenshots).

The example missions still put lots of actual parameters into just 2 physical parameter boxes, so that doesn't sound promising.

Yep, that works fine for me. Great! Had tried it before in this way, but I think I had some group links slip in when they should all be syncs.

@Mike84: That makes frightening sense. Make people think things were fine while simultaneously make it harder for community scripters... Missing error messages ticketed at DH.

Yeah, I think that came in with 1.01beta (bad, bad idea if it isn't a bug!). Until they fix it, use a log viewer (with tail), like LogExpert, to watch what is happening in RPT!

Sorry to add to the pedantry, but you can't use this any more: _logic = "Logic" createVehicle [0, 0, 0]; In A2 you have to use: _logic = "Logic" createVehicleLocal [0, 0, 0]; or _logic = (createGroup sideLogic) createVehicle ["logic", [0, 0, 0], [], 0, "NONE"] EDIT: and, what I forgot to say, is that I've had no problems setPosing either type.

Anyone worked out how to know what the current setting is so you can resize and/or move your controls to fit the player's screen? The issue is that the screen coordinates change based on this setting, so you need to know the proportion that it is. i.e. in A1 A2 large UI, screen goes from 0 to 1, but it goes from about -1 to +1 by the time you have a tiny UI size in A2. Just being able to query this proportion would be great. Ideally an event, but you can always just check when you open your dialog... EDIT: Thanks looz for the answer: _visibleScreenCoordinatesRectangle = [safeZoneX, safeZoneY, safeZoneW, safeZoneH];

Trying to convert SPON Map to run with A2. They are very relevant to your tool, I think: * Display/control config in A2 have several more attributes, but running without them just spams warnings into RPT file. No on-screen error message. * Screen coordinates seem significantly different (SPON Map looked fine, but was small, about 50% of normal size, and only in the middle of the screen on one setting, but over the edges in another). This is an effect of the GUI re-sizing system in A2. This probably means that you really need to manually resize all components each time you open a display or expect people to play on "normal GUI" setting. * You must store all variables that contain control or display handles in the ui namespace OR put disableSerialization command at the start of your script (which allows you to be backwards compatible, which is really nice, but I assume this means you can't save the game safely). If you don't, you get on-screen error message and RPT spam every time you use such a variable without using the namespace. bad: SPON_Map_display = findDisplay 49; ... later ... SPON_Map_display displayCtrl ...; good: uiNamespace setVariable ["SPON_Map_display", findDisplay 49]; // ... later ... (uiNamespace getVariable "SPON_Map_display") displayCtrl ...;

I was rather hoping that A2 had reduced the cell size from A1, which would allow more undulation and allow terrain features such as you describe. As I said, the change from 10m cell to 5m cell we made in our Dynamic Terrain test for A1 made a massive difference; we could suddenly make reasonable, if not perfect, small rivers, craters and trenches. 2.5m cells would really make a massive difference, though it might be too much strain on the engine to be worthwhile.

Deano and I were considering something similar. 10m cells for the default terrain, but replace any deformed terrain with 2.5m cell sections. Never got around to trying it, but would work in theory. Of course, we aren't using regular terrain, but...