Jump to content
Bohemia Interactive Forums

Defunkt

Member
 View Profile  See their activity

  • Content Count

    2558

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Defunkt

  3. Posted

    We all use mods and we're all capable of selecting and combining mods to our own taste. We don't all find it necessary to go into threads for analogous mods and make video comparisons with the work of others. It's bonkers, and frankly bloody rude, even before considering that you're comparing two whole freakin' different generations of the game. It's great you've found a mix of A2 mods you like, just enjoy them and stop trying to beat everybody else over the head with your representation of them as some sort of gold standard. Hardly anyone here plays A2, and it has its own forums, we're in *this* thread to discuss what's possible and developing within A3, now, by snkman.

    • Like 3
    • Thanks 1

  5. Posted

    47 minutes ago, wansec_6 said:

    What is the Smart AI mix you mentioned above?

     

    God, no, please don't ask that. Basically there are a couple of weirdos eccentrics who keep popping up in ArmA 3 discussions on AI and banging on about their secret-sauce AI 'mix'. You'll eventually find out that these (collections of existing mods by other people) are actually for ArmA 2 and thus not really at all relevant to the current discussion.

    • Like 1
    • Thanks 3

  6. Posted

    8 hours ago, pognivet said:

    There is no risk, no downpayment, no investment for Bohemia but they make incredible returns and profits by doing virtually nothing.

     

    You are seriously naive when it comes to how the world works. Why do you imagine all those Internet giants that lose money year after year are valued so highly? Because they've captured a market, established a recognised brand and accumulated a userbase, same as BIS, and that was a very risky proposition when they started out. That's now capital and this is how it yields a return.

    • Like 5

  9. Posted

    2 hours ago, snkman said:

    Oh well... Yes i know... Bit late to the party... ARMA 3 developement almost has reached it's end and IF there will be another ARMA game it will by very high chance use the Enfusion engine which will make T.C.L. kind of useless because of the new enfusion script language.. Pretty sad... :icon18:

     

    Given we've not yet had an announcement that's likely still years away, and still more years until we have the level of content available now in A3.

    • Like 1

  10. Posted

    Something else I'd encourage you to keep in the back of your mind is AI that only has a melee attack and possibly cannot open doors. Dogs or zombies are an obvious example but an even better one I think is Raptors chasing you around a hospital or other large facility. I guess there'd need to be logic that allows a route to be interrupted by the need to close directly with a discovered enemy.

     

    Understand this might not be a priority but just wanted to make mention in case it informs some choices you might have to make.

    • Like 1

  13. Posted

    Agree with what's been said on the apparent speed with which accurate knowledge is disseminated among AI.

     

    Wonder if I might also posit that one of the things I find unnatural about combat involving AI is the shear volume of fire, like once engagement begins it's just constant firing where most combat footage I've watched small arms fire is vastly more sporadic. Most players I think also shoot significantly more sporadically than the AI. Support weapons (i.e. suppressive fire) aside I think authenticity would be increased by making AI less inclined to fire (i.e. only with higher certainty of target location and when the shooter is not under fire themselves). Might come about naturally if AI are less adept at sharing target knowledge.

     

    But I'm looking forward to trying TCL. Doesn't require CBA, works with (rather than against) the native AI - where have you been all my Arma-life TCL?

  14. Posted

    Nice. Watched it several times (with Froggy's soundtrack 😉).

     

    First two turns at the bottom of the stairs he appears to rotate through the less natural of the two possible arcs.

     

    Don't know what exists in terms of suitable moves but ideally they'd go up and down stairways sideways (facing toward the opposite stairs or the next landing) so as to appear to be  covering emerging threats - think it would also make each rotation on the landings look a little more natural. Possibly best implemented as properties of the 'waypoint' (rather than the script trying to add smarts which might prove not to be appropriate) - this may already be the case and the route just needs some tweaking


    Can't help but want to drag those markers around a little to improve the path (for instance when he clips through the wooden ramp because the preceding marker wasn't as aligned with the base of the ramp as it might've been). Are you anticipating a facility to tweak marker positions visually in the editor?

  16. Posted

    21 minutes ago, johnnyboy said:

    a mission maker can choose that path

     

    Beyond choices by the mission maker it'd be good to see this as an action menu entry for any player with subordinate AI, most likely calling up a dialog listing nearby buildings and available assault plans for each then executed for all units in groupSelectedUnits.

     

    But you're right of course, carefully defining an extensible path data format and creating a handy tool for generating it is the most important thing at this stage.

    • Like 2

  17. Posted

    Cool bananas 🍌. Could be quite a big deal and a must-have mission include.

     

    In addition to whatever turns up from the script challenge I hope you might accept submission of predefined pathing information by building class name for a data file distributed with the script. There are only so many unique buildings in the ArmAVerse and we might eventually get them all indexed (more reliable and efficient than real-time calculation). With the script acting as a fallback where the class is not present in the data file.

     

    EDIT: Something else, hopefully weapon use, and particularly grenades might be moderated by some overall ROE (specified at the time of execution) in terms of likely threat level, presence of non-combatants and the like. Ranging from "Enter with Minimum Necessary Force" (no lethal grenades) up to "Breach with Maximum Prejudice" (shoot first, open doors later).

    • Like 2

  18. Posted

    6 hours ago, phronk said:

    BI still hasn't added any commands to locally mute/unmute players -- it's still on their To Do List to be reviewed/approved but it has also been there for like 2 years. They may still add it, but so far no commands or functionality has been added to do what is necessary to fix the exploit and make the script viable. Until then, the project is indefinitely on hold.

     

    I've never played A3 online, so may not understand the whole issue, but I've always been interested in this script because I recall from running an A2 server how addon-free functionality is pure gold. Correct me if I'm wrong but as I understand this;

     

    Quote

    Did you mean you heard 2 people talking in a channel you were in, but can't talk in because it was disabled due to range? This is kind of an Arma VON "exploit" I can't really negate unless they add the mute feature I requested BI to add.  Adding static when out of range may reintroduce the persistent static bug.

     

    The only thing this prevents you from adding is a maximum range (beyond which players cannot communicate at all)? If so, is that really such a problem? Consider that without this script a public server (with random players not in TS) is only going to have vanilla VON for which there's no maximum range either. But separation by such distances is likely to be a relatively small subset of actual use cases and it seems to me that this script suite is still an unalloyed good just by virtue of adding squelch and range-based static. If there's no way to effectively cap range then I think just settle for maximum static at and beyond that range and allow players to transmit at any range given they're going to be able to listen to those conversations - ideally with lots of noise.

     

    In short I'd encourage you to continue development because (as far as I can see) there's a lot of utility here even without being able to implement a maximum range.

  19. Posted

    These look very nice and I completely understand the desire, I can't bring myself to place any of the bug-eyed CSAT units even for testing (RHS is A3).

     

    Assume by scripts you mean configs (all that should be required for this sort of replacement). They're actually incredibly simple once you know 3-4 patterns that need to be used (and the right time to use them). The main thing is to preserve the inherited hierarchy, at some point in your patch this will involve what I would call a 'backward declaration' introducing a class defined elsewhere to be used as the parent of a class you're amending. 

    class Parent; // This tells the processor that this class has been/will be defined by another config.

class Derived: Parent { // This is the class you're changing (including its original inheritance from Parent).
   ... // Your changes.
};

    Where it gets a bit trickier is when you have to backward declare sub-classes within the parent declaration. 

    class Uniform_Base;
class UniformItem;

class SomeUniform: Uniform_Base {
   class ItemInfo: UniformItem {
      ... // Your changes.
   };
};

    Or (more involved);  

    class Parent {
   class ItemInfo;
};

class Derived: Parent {
   class ItemInfo: ItemInfo {
      ... // Your changes.
   };
};

    Choosing the correct pattern is just a matter of preserving the original hierarchy for which you'll definitely want an All-In-One config dump (and something like Notepad++); 

     

    • Like 1

  21. Posted

    10 minutes ago, CUP said:

    could you elaborate a bit more on this? what do you mean exactly?

     

    Sure, it's just a CfgPatches class which is guaranteed to load last so any addon that wants to derive from the given CUP module's config only has to name this as a RequiredAddon to ensure it loads after all of the addons whose config it might want to subclass. Vanilla has the same thing in the form of load order patches for each of the DLCs. So  RequiredAddons[] = {"A3_Data_F_SAMs_LoadOrder"}; ensures my addon loads after all of the A3 content. So something like "CUP_Maps_LoadLast", "CUP_Vehicles_LoadLast" etc.

    • Like 2

  22. Posted

    On 3/29/2019 at 9:55 AM, CUP said:

    The next patch is only a few days away and its gonna come with a lot of great new content.

     

    It's possible such a thing already exists and has escaped my notice but if not I wonder if you'd consider adding 'Load Order' patches to each CUP component (so it's easy to derive from the CUP config tree).

  24. Posted

    2 hours ago, infinity_loop said:

    that is exactly what I had in mind

     

    Excellent, was part of a solution I was day-dreaming about just a couple of weeks ago (there I further posit the possibility that one might hand off calculations that require map data to a separate instance of the dedicated server running a partner extension).

     

    Look me up on the Arma Discord if you decide to proceed and want some direction on Arma's ways - lots of super helpful experts there; https://discord.gg/9KEgz3

  25. Posted

    As kju said, you're probably going to encounter some severe limitations when it comes to the amount of tactical control that can be exercised through mods. A lot depends on the nature of the changes you hope to make. Probably a good overview of current issues and recent improvements might be this thread; 

     

    Some information on the subset of FSM routines that may be scripted here; https://community.bistudio.com/wiki/Arma_2:_Operation_Arrowhead:_AI_FSM

     

    If you like working in C++ and/or have a body of existing code you may well want to write an extension (a native DLL that can be called from SQF); https://community.bistudio.com/wiki/Extensions

     

    As you probably know, Arma isn't terribly multi-threaded so if you do write an extension I'd suggest running complex decision making in separate threads. Maybe maintain a table of best-next-course outcomes, prioritized by proximity to action for all units in play, ready to be fetched by an in-game script as is required/expedient. One obvious problem with threading this though is you wouldn't have real-time access to game/map data for doing LOS checks or pathing.

     

    You may also want to look into Intercept (https://github.com/intercept/intercept) which I believe would allow you to fetch aspects of game state directly from your C++ code (though I expect only within the thread of the calling SQF).

×