Jump to content
Bohemia Interactive Forums

Spooner

Member
 View Profile  See their activity

  • Content Count

    223

  • Joined

  • Last visited

  • Medals

Posts posted by Spooner

  3. Posted

    CBA v0.1.2

    Key Changes

    * FIXED: ALICE and SILVIE stop working when CBA is active

    * FIXED: Support for the "AnimStateChanged" event needed.

    * ADDED: JIP-persistent markers (CBA_fnc_setMarkerPersistent, CBA_fnc_getMarkerPersistent).

    * ADDED: Persistent player actions (CBA_fnc_addPlayerAction, CBA_fnc_removePlayerAction).

    Full documentation is available at DevHeaven.

    Download

    The addons, manual, functions reference and complete sources are included in the release.

    * DevHeaven

  4. Posted

    Do not name HC modules yourself. They are automatically named by the system, so unless you are telepathic, it is possible that you could give them incorrect or misleading names (BIS_HC_ prefix implies that a name has been given by the HC module itself, not that that is what you should force it to be named).

    In this case, it makes more sense to only have one subordinate module (multiple subordinate modules are used to group together sub-groups. You only have the 3 subgroups, so no need to group them). Thus, you should really just have one SL synced with one Commander module synched with a single Subordinate module synched to 3 fire teams.

    You might find my example clears up how to make a complex hierarchy, though for your simple hierarchy the example on the HC docs page might be plenty.

    Regarding trying to get an FTL to get into a vehicle, just wait until the HC module is fixed to allow this.

  7. Posted

    Yes, key event handlers should always return true/false. The real problem with this report is it is a bit vague and doesn't refer to the handler that returned the bad value (as it couldn't). Personally, I dislike making it idiot-proof (where ANYTHING except "true" is counted as a false result) because that just hides the truth and still allows you to pass the wrong value by accident (that is, you have a variable that is 5, when you wanted it to be true. By complaining that the handler MUST return true/false, it catches this problem. Assuming 5 is "false" hides an error from the user and since I think a lot of the woes in SQF are caused by BIS ignoring errors rather than dealing with them in a rigorous way, I want to keep this as it is. The warning should be made a lot clearer though...

    Regarding action-key support, I did have it in SPON, but not in the released version. CBA is getting a lot of the unfinished stuff that was in SPON Core but I lost enthusiasm A1 a lot in the last year. Some sort of merge might make sense, as this work is already partially done.

  8. Posted

    So is the official stance this isn't SP save friendly (ATM) like in Arma1 - loading causes it not to run anymore?

    Save games have nothing to do with SP any more :P

    Although this addon uses an inefficient workaround to deal with the issue, it should work fine with SP or MP saves. Unfortunately, there isn't really a better way to deal with this at present...

    We are looking at adding a simple framework to manage this in CBA. Even if this just means that we get to inefficient once on behalf of all CBA-dependent addons :D

  10. Posted · Edited by Spooner

    PreInit and PostInit are only run once. You are quite correct and thus you don't need the usual global-variable test to stop it happening more than once. The former is run before any objects are created, the latter after they are created. In your case, you might as well use PreInit unless you need the player object for something. The syntax for the once-only handlers is a bit different though (not associated with an object class):

    class Extended_PreInit_EventHandlers
{
   S_NVG = "[] execVM '\S_NVG\init.sqf'";
};

    CBA has just been hot-fixed, by the way, since the first release was a little bit borked. Sorry, I realise you were probably waiting to release until you had an official XEH to use, but anyway, everything is fine now (fingers crossed!).

    @Zipper: The FR should work with the new version of CBA... Sorry, that was our fault, not sholio's!

  12. Posted

    I assumed low, medium, high, very high refered to none, 2x, 3x and 4x AA and thus were lower than the 5x, 6x, 7x, 8x options. Your card may not support all the options, but I guess it defaults to the next lowest setting if it doesn't.

    Essentially, each 'x' means the screen is drawn that many times bigger before resizing to be viewed (well, this isn't literally what is going on, but good enough for a simple explanation). So, for 4xAA on a 800x600 screen will be rendered at 1600x1200 and then resized to 800x600 before the user sees it.

    I did indeed see that MSAA was many times faster than the equivalent fill-rate. That is, 4xMSAA is vastly faster for me than 200% fill-rate (I think because graphics cards are optimised for hardware AA, but not for fill-rate, which must be done in software).

  14. Posted · Edited by Spooner

    Rather than continually adding and removing the actions, it would be simpler to use the A2 action condition (same as the A1 action condition, but it can be applied in scripts as well as in config). I'd also prevent people outside the vehicle opening and closing the doors, but that is my choice.

    Either open or close action, as appropriate, available for anyone in the vehicle:

    _vcl addAction ["Open C-130 doors", "C130_openDoor\openDoor.sqf", "", 0, false, true, "(not (_target getVariable 'NORRN_openDoor')) and (_this in _target)"];
_vcl addAction ["Close C-130 doors", "C130_openDoor\closeDoor.sqf","", 0, false, true, "(_target getVariable 'NORRN_openDoor') and (_this in _target)"];

    Thus the whole init file can be about 8 lines.

  15. Posted

    Yes, absolutely! Multi-levels make a lot more sense when all commanders are players. However, there is no reason that complex fsms could not be written to manage multiple-levels of command, but really, the effort would be enormous if the sub-commanders are to act as you would like them to. You are actually asking for more intelligence in HC sub-commanders than I've seen within single AI groups that aren't part of a structure. No surprises that they aren't perfect yet...

  16. Posted · Edited by Spooner

    Well, as a USMC SL, you have command over a medic and 3 fireteams (=4 entities under your control). The problem you are having is with the idea of delegation, not with the system as such. If you want to micromanage 13 guys, then use a single group. If you want to manage 4 entities, make each a subordinate group. There is a reason why military units have a chain of command - it is precisely so commanders only manage a small number of subordinates rather than each commander having complete control over every man.

    In an army squad of 9 guys, 2 subordinate groups might be a bit limiting, so you might consider having 4 buddy teams (4x 2 men) to give you some more fine tactical control.

    CAVEAT: Currently, the subcommanded AI are particularly dumb and so having only lose control over them doesn't work. What is needed is for the HC AI to be improved, rather than changing HC so you have fine control over every man, which rather defeats the point of the CoC altogether.

  17. Posted

    1.02 doesn't tell me the full version, but I'll assume you mean 1.02.58134. I don't know why BIS tells us hard to remember build numbers and doesn't just have 1.2.0, 1.2.1 like most other games. Anyway, that is another issue...

    BIS_HC_0 refers to the first placed logic, where the second one will be named BIS_HC_1, etc.

    I think the easiest thing would be to add to ALL logics:

    this setvariable ["chainofcommand",true];

  18. Posted

    72;1317327']I am on 1600x1200 (21 CRT) and i run windows in that with 85hz so no flickering. but this is way too much for ARMA2 with my puny 8800GTS 320MB.

    In this case' date=' you'd run A2 at 1600x1200 [i']with a low fill-rate[/i]. The GUI would be as crisp and clear as you are used to getting on the desktop, but the 3D rendering would run as though you were running on a lower resolution (so running as fast as if you were running the game at 800x600 resolution if you are running at 1600x1200 with 50% fillrate).

  19. Posted · Edited by Spooner

    Secret is to always use your TFT's native (maximum) resolution, but alter fill rate until you have the optimal FPS:

    * If you have a very weak 3D card: Use native resolution with low fill rate (< 100%). You will probably never gain anything by using FSAA.

    * If you have an average 3D card: Use native resolution with 100% fill rate. Perhaps consider using FSAA after it is available, since it is optimised over using an equivalent high fill rate.

    * If you have a very strong 3D card (or SLI): Use native resolution with high fill rate (> 100%), until FSAA is available, then probably use that instead.

    What is a weak/average/strong card is rather dependent on the resolution of your monitor compared to your cards power, so I can't be more precise.

    If you have a CRT, things are a bit different, but you are still best using a higher resolution with a lower fill rate over a lower resolution with a higher fill rate.

    EDIT: For CRTs - Nevertheless, don't run it at a resolution so high you wouldn't run your desktop on it (I once had a CRT that was rated to 1600x1200, but at that resolution it was so flickery and blurred, I couldn't see anything, so I ran my desktop at 1280).

  23. Posted

    dhtopbanner.png

    A new community site delivering services tailored for developers, their projects and user-base

    DevHeaven is a place to learn, share, discuss and collaborate:

    • Project Spaces: Request a workspace for any of your ArmA or ArmA 2 projects, large or small, public or private. This gives file and repository hosting as well as forums, a wiki and an issue tracking system for your project.

    • Forums: Discuss your ArmA 2 finds, express your thoughts about development topics, find interested people, let others review your code and much more in our forums.

    So, after about 6 months of preparations and testing, we are proud to present you DevHeaven. The project has evolved under the lead of kju and Sickboy, together with the help of Spooner, Squelch, Vigilante and our ever-growing community. We all hope you, and your project's fans, will enjoy the service!

    If you have problems, or requests to improve the site or any public projects, please share them with us.

    See you soon at DevHeaven!

  25. Posted

    Massive player squads are necessary in OFP/Arma1 if you want to have control over more than a few people, in spite of the fact that having more than a fireteam is unwieldy and more than the magic 10 (so you have multiple screens) is approching meltdown. This sort of structure is obsolete in A2 with HC module, so who cares?

    And yes, I think more small patches is significantly better than a few large ones. I'll even go so far as to have massively more tiny patches, but you need a distribution system like Steam to make that feasible. This wasn't my original point though.

×