Jump to content
Bohemia Interactive Forums

Rydygier

Member
 View Profile  See their activity

  • Content Count

    4805

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Rydygier

  1. Posted · Edited by Rydygier

    Great. :)

    There may be best to keep in mind few tings:

    there are new RHQ arrays for 1.1 (RHQ_FO - FOs, RHQ_MArmor - medium armor, RHQ_BAir - bombers,RHQ_Fuel,RHQ_Ammo,RHQ_Med,RHQ_Rep - support by kind, RHQ_RAir - recon air (UAVs etc), RHQ_NCAir - unarmed air), there will be more Leaders, and there is very easy way to make these configs smaller:

    RHQ_Something = ["bla1","bla2"];

    RHQB_Something = RHQ_Something;

    RHQC_Something = RHQ_Something;

    and so on, instead of:

    RHQ_Something = ["bla1","bla2"];

    RHQB_Something = ["bla1","bla2"];

    RHQC_Something = ["bla1","bla2"];

    ...

    RHQH_Something = ["bla1","bla2"];

    Also may be good to give people some tips about optimal look of such entry to keep all thread clear and good looking:

    Bolded name of addon/DLC etc

    Here some description and additional info if needed

    RHQ_Something = ["bla1","bla2"];
RHQB_Something = RHQ_Something;
RHQC_Something = RHQ_Something;

    something like that with spoilers and php/code box...

  3. Posted

    Well. Found some time, so...

    Nice_Boat's Tank Damage System 2

    News:

    - lags reduced or even removed (I hope so);

    - no more juggling with pbo versions: see readme to know, how to on/off debug and Towards Enemy System (TES is based on temporary waypoint assigment, so effects may be imperfect, when tank already has waypoint assigned) with two simply config variables;

    - script version added (see readme, how to init);

    - added handling of ARTY module ammo, but untested, so effects unknown.

  5. Posted · Edited by Rydygier

    Ambulance was sent for injured but did not help because they weren't close enough (or maybe ASR_AI influenced negatively here, idk). Some other instances of support assistance did not do its job either.

    I think, that problem here is as follows:

    Target point for a support is located at position of unit, that needs support in moment, when support is sent. But after this unit often still moves (only seriously injured/damaged are withdrawn and waits for support, others continue their missions). In tests in smaller scale there was not a problem - support gets destination early enough to "catch" units in 500 meters range, but here unit has enough time to move to far. Well, hope, that regardless of this problems support doing something useful often enough.

    In future version will try to tweak this aspect. Most simply idea - group that calls for support should to stop and wait or, if on mission and still effective, should wait with call until mission is over. Or maybe support unit should get waypoint attached to target unit? But then I affraid, will happen many... car accidents. :)

    EDIT: Currently new content of manual is ready, but there is a chance for correction maded by english native speaker to make this text more clear and understandable, so here will be some wait, meanwhile will be multiplicated next Leaders and soon must to inform MSO module creators, that code is ready (although still there will be some work for them, beacuse did not used CBA marker and any other functions, also suppose, that there will be needed some changes for MP compatibility)

    I also think that this mission is kind of unbalanced towards West side, and it looked a bit of a piece of cake to them,

    It is. War is unfair. :) But it is not so simple. I hope, that there is possible to notice, that lack of coordination between west Leaders gives OPFOR some advantage. First CDF only slowly continues its offensive, and USMC, if UAV early dicover OPFOR units, is far sooner involved in fights with all OPFOR power. Situation changes when CDF forces are finally discovered by OPFOR, but still - most of OPFOR objectives is located in USMC part of map. Also USMC has air support, but has only a few tanks and not so much AT firepower, especially wheeled/tracked. AAVs and LAVs are quite easy targets for BMP-2. There was moment in my test, why I thought, that USMC will be broken...

  7. Posted

    Hmm. So indeed, HAC requires a lot from CPU, since its presence has such a big impact on FPS when processor is pretty weak. Although my Intel Core2 Duo E7400 2800 Mhz swollows three commanders without any impact on FPS. My bottleneck is graphic card, old GF 8400 512 MB and I have in Chernarussian forest 8-10 FPS on very low resolution and minimal graphic setting regardless if with HAC or without it. I wonder how it will be with all eight commanders and what hardware handle them smoothly... In the future I definitely need to explore ways to improve the efficiency of the code.

    However good to hear, that new version works better. Preprocessing did its job, but still lot to do in this matter.

  10. Posted

    Now writing new manual content - significant amount of work itself...

    Until it will be finished waiting for reports about newest demo. Especially these lags - someone else experienced lags? When? All the time, or in particullar moment (what happens on battlefield in this moment). How big lags? Acceptable, or too big? On what hardware? Comparing to earlier versions (eg CargoDemo)? For sure caused by HAC, and not by some else active addons? I have lag all the time with FPS about 10-12, but in Chernaruss I experience that even on empty map without HAC, so can't compare, only that, with HAC FPS isn't worse for me than without...

    Have you had full squads get in trucks?

    If you mean 13-men USMC squad in MTVR with driver - it is impossible and never will occur with HAC, or without. One man always will stay outside, because MTVR has 13 places including driver's.

    http://forums.bistudio.com/showpost.php?p=2096020&postcount=534

  11. Posted · Edited by Rydygier

    Sure:

    NBT_TDS

    It's been a long time since I looked in this code, I remember that remained a problem with lag when tank is under rapid fire (because each hit fires an eventhandler), there is also no support for ARTY_ amunition used with BIS_ARTY module. There is some chance, that I will return to this project, now I have some new knowledge, that may helps with these lags a bit, although seems, that only a few people are interested in this addon.

  12. Posted

    To be honest I prefer the 2 commander version.

    With this version there is still possibility to play as in previous versions - two commanders, two armies, two objectives, no fronts and other complications, all as you wish. Scale and complexity depends only on mission maker. Now mission may, not must, be more complex. Additional commanders or four objectives - this are optional & additional feauters requested by people.

    However worries me these lags...

    Still more to do (can't let you off THAT easily) but it is looking good.

    Yeah, I doubt, if this will be last version, but also I doubt, if next one will be created so quickly as 1.1... Real life calling me louder and louder. :)

  14. Posted · Edited by Rydygier

    Two notes:

    - teleport relocating leaderHQ, not player unit :) so in player's default unit init field leaderHQ must be changed to Player.

    - perhaps too long takes to capture given Objective. After an hour and half forces are at second objective (plus one major battle), but still, there are big distancies and action is growing slowly - rather realistic, but maybe too realistic? Three factors have influece on this: interval between resets, required number of ally units nearby objective (default 30, maybe to many) and radius within allied units are counted. First and second is user-adjustable, but third not. So maybe radius should be greater than 250 meters? Will adjust to 300... EDIT: I know: I will make this adjustable too. Default will be 300 for now...

    Third note:

    - maybe leaderHQ should be relocated after capturing objective to this objective area? EDIT: universal rule: if you have doubts about something, make it optional, let user has these doubts instead of you. :)

  15. Posted · Edited by Rydygier

    So here it is:

    HAC 1.1 alpha4 (demo mission)

    What's new:

    - fronts: by setting with specific name an empty trigger on map you can create front area for given leader. He will pay attention only for hostiles inside this area;

    - third leader, side C;

    - voice notifications for player controlled Team leaders in two versions: mimimal - only beep&text or with some dialogs, recommended for USMC faction;

    - some efficiency changes (please, when testing, pay attention whether there is a lag, and whether the gameplay is smoother than in previous versions, or vice versa);

    - removed sidechat with info about new cycle - diag_log into .RPT instead implemented;

    - new air units category for recon planes (UAV);

    - another bugs eliminated and fixes maded.

    New config variables (default):

    RydHQ_VoiceComm (true) - voice notifications for human controlled team leaders with dialogs if true, and only with beep&text if false;

    RHQ_RAir ([]) - array for non-generic recon planes;

    RydHQ_Front (false) - if true and "front area" trigger is prepared, then leader will pay attention only for enemies inside this area. Do not set this "true" without front trigger prepared!

    RydHQ_Obj1 to RydHQ_Obj4 - new names for main objecitves. To play with only one, set on map RydHQ_Obj1 and add to init config following:

    RydHQ_Obj2 = RydHQ_Obj1;
RydHQ_Obj3 = RydHQ_Obj1;
RydHQ_Obj4 = RydHQ_Obj1;

    or set all four objectives at same position.

    RydHQ_ObjHoldTime (600) - how long (seconds) should group with "capture" task stay in objective area before will become again available for other tasks;

    HET_FA, HET_FB, HET_FC... HET_FH - names of triggers which position, shape, size and direction determine the boundaries of front zones (one per leader).

    This time it is really last alpha... I suppose... This a last chance for bugtracking before public release of HAC 1.1. :)

    Enjoy playing & testing this demo. Default player's unit has teleport (there is needed small fix in init field of this unit :change "leaderHQ" to "Player") on map click and is resistant to damage. Is also excluded from HAC control. See map markers and init.sqf file for more details about config.

    ---------- Post added at 20:01 ---------- Previous post was at 19:14 ----------

    PS. This is long mission, forces are moving across all Chernarus. If someone want to speed up fights, may of course re-locate units and triggers or make resets occurs more often, which will speed up capturing objectives: RydHQ_ResetTime = 300; RydHQB_ResetTime = 300;RydHQC_ResetTime = 300; for 5 minuts for example.

  16. Posted

    Cargo demo has some bugs here and there; I'm not sure, why they not fly in this mission. I have UNSUNG, so can test yours mission, if units are not from other addons, but, if I remember right, on my hardware this jungle map was loading about 20 minutes when I tried. All these trees... :)

    I decided following: 1.1 will be without bigboss, unless you, people, prefer to wait another week or two until I will be sure, if this is ever to be done and until I will do this, if so (but I'm not sure, how many time I will have in February).

    Bigboss will come up later, if at all (I hope so), and for now there will be only five commanders more (three of them for now are ready) to do, manual to write, MSO module to wait for and... release!

    Anyway, decided also to give one more alpha with demo mission (today perhaps), need to know, if there are some efficiency changes and some things to fix before will start with further copying all these files.

  17. Posted · Edited by Rydygier

    Also about main objective: how long does HAC keeps it occupied when it captures it? I need it for timeout duration.

    How about this: I will make, that group will stay busy with capturing mission by given time after SAD waypoint completion? This time may be customizable, and by default... 10 minuts? In fact there was 60 seconds of sleep after SAD, now is 600 by default and may be changed dynamically (such change will be considered by next capturing mission).

    Maybe you should use HAC only in a Sandbox, before he will take over your Computer.

    Are you sure, that you talking with human right now? :)

  18. Posted · Edited by Rydygier

    Im not exactly sure about conditions for triggers that spawn random enemy groups, should it be guerrillas not present or something else?

    You may want to keep certain number of groups on map, so maybe some quantitative threshold? And some interval between spawns? And, important in my opinion, there should be not units of second side in certain radius, especially player controlled, so spawns shouldn't occurs in close proximity to enemy units.

    Also about main objective: how long does HAC keeps it occupied when it captures it? I need it for timeout duration.

    Hard to tell actually... It is fluid. When capturing mission is over, group will stay there until it receives a new mission elsewhere. Although when capturing missions are issued often there is not much more to do at this time, but still there are idle missions. However given objective will be considered as "captured" as long there are no enemies in give radius or if there is more allies than enemies around. Exact conditions checked every reset (10 minuts by default):

    to "capture" - no enemy units in 500 meters radius (or very few of them - depends on leader's recklessness) and more than 30 allied units in 250 meters radius (or other number of units chosen by misson maker);

    to "lost" - there is more enemy units in 250 meters radius than allied units in 500 meters radius.

    Pending some testing, if this works, but it is not easy to test.

    Heh, they may have been called to pacify those rowdy teenagers that keep protesting about that ACTA thingy.

    Possibly... :)

    If I give conventional forces commander side objectives place in those camps will he try to reinforce the garrison there in case of troubles? Also HQ tries to protect its position, right?

    Affraid not. :) Not directly. Only thing, that leaderHQ will do about secondary objectives directly is sending sometimes idle groups towards such objective with guarding or patrolling mission. This mission may be interrupted any time when given idle group is needed for some primary tasks. There is good chance, especially, when sec objectives are far away, that no one will get there at all... But if someone will be there (eg garrison) and will be attacked, then HAC become aware about new enemy and will send primary attack missions at this position to engage hostile units.

    ---------- Post added at 14:56 ---------- Previous post was at 14:45 ----------

    Wow, it looks like HETMAN Artificial Commander is shaping up to be a legendary, must have script for the Arma series. Thanks Rydygier and everyone contributing. I have been watching this unfold and ideas put back and forth. This is why I love the Arma series!

    Yep, HAC has grown so monstrously that merely I embrace it already. Often surprises me and I do not know why he does what he does. Now I wait only until HAC will work out E = mc2 formula with markers or will start oppose to me vulgar words. Maybe that was him, who sended these Hinds at my house... Still, bugtracking gets more difficult...

  19. Posted

    Added + 20 morale gain if objective captured, and - 5 loss, if lost...

    ---------- Post added at 13:41 ---------- Previous post was at 13:28 ----------

    If I set insurgents and guerrilla to work together, then will HAC order both factions?

    If not civs, needed only this value high enough: GetFriend. Plus additional conditions, if some limited control mode is on.

    If HAC has an order to capture an objectives how close units will be placed? I want to know as AI dosnt have enough brains to destroy tent so I used "seized by" and I want to know how big radius has to be.

    After tactical flanking positioning (100m from target spot) capturing group will receive "SAD" wayypoint exactly on spot, but SAD means, that they will move here and there. From Biki about SAD waypoint:

    "A leader on foot will rarely search more than 50m from the waypoint, while a leader in a helicopter will search up to 300m from the waypoint."

    You say that HAC wil delegate reserve forces to secondary objectives. I think that will suit my idea pretty well. My guerrilla faction would get secondary objective that moves along with conventional forces main objective. I would mean that there would be high chance that guerrillas would always have someone guarding their camps in case enemy comes.

    You also always may exclude some group as camp guard, or, better, make them garrisoned (there is such array in HAC, but lately found some bug in this code, will be reapaired)

    PS. WOOOW just heard some noise behind window, so look at white, winter world and what I see? Five Hind (?) helicopters above my house flying somewhere towards east... Excersises? Routine relocation? War? Did I miss something when coding HAC? :)

  21. Posted · Edited by Rydygier

    This is not hard to move object by script/trigger. Currently used also is moveable. Objectives are and will be moveable as any placed in editor object, and HAC will notice this movement, but HAC itself will not to move them, because principles of this movement will be very different depending on mission maker's concept. To move objective object in chosen moment, may be used eg. "setpos" command. The trick is, to determine appropriate conditions under which movement should occur and to where should be moved. In yours warfare concept it may be "not presence" of OPFOR in given radius around camp. If main camp building/tent will be named eg "Camp1", "Camp2" and so on, then movement code may looks like : RydHQ_Obj1 setpos (getpos Camp2); or maybe even: RydHQ_Obj1 = Camp2; (not tested), without need of movement, just given tent-object itself becomes a current objective (caution, this should be indestructible object, otherwise, if destroyed, therefore objective disappear from the map), but HAC in this case will always clear camps in the same order, so there may be added some randomization of first and next target, and so on...

    Also if you for example want only one objective (as currently) and to move it across the map, there will be some ways do do that: First: to place all four objectives in same place and to move them together. Second, better, because simplier: to place only first objective (RydHQ_Obj1) and to add in init config following:

    RydHQ_Obj2 = RydHQ_Obj1;

    RydHQ_Obj3 = RydHQ_Obj1;

    RydHQ_Obj4 = RydHQ_Obj1;

    Should work, although it is not tested.

    Still, there be also, as is, two optional secondary objectives per leader, but leader will pay only little attention on them - some idle groups may be temporarily directed there and this is all. This is usefull, if mission maker want to relocate some forces towards given areas in not invasive way during mission or to simulate capturing of village, strategic point or whatever. It is not guaranteed although, because it is randomized, and idle groups may be any time redirected to attack.

  22. Posted · Edited by Rydygier

    Yes, it is all to consider yet. BB should at his own discretion to manage with fronts (this may prove hardest to implement), objectives, and leader's positions, depending on the overall situation on the map. Not easy, as I said, so implementation such strategist's view will last long.

    ---------- Post added at 19:15 ---------- Previous post was at 18:57 ----------

    For now implementing "moveable objectives". There will be four main objectives for each leader. On start current will be always first of them. If certain conditions will be met, this objective will be considered as "captured", then next objective (Obj2) will become current one, and so on. But if enemy retakes area near of one of already captured objectives, this one would be current again. This may prove usefull for mission makers and for bigboss.

  23. Posted · Edited by Rydygier

    More leaders means more cycles in one turn, and cycles aren't executed simultanously unless "fast" mode is on, so yes, each round will last longer beacuse of longer queue, but maybe "fast" will work without choking CPU. Of course additional commanders are optional.

    They will work together only (but not exactly in this way, there will be no "borrowing" units or support), if I manage to implement bigboss level, and currently I'm thinking just about that. Also considering, if do it in version 1.1 or maybe in some later version, because there is all strategy to invent and implement, there is still many questions without answer, this take some time, so in later version this will be better refined. Without boss level, if you want cooperating forces, just give them one leader, and voila... :) You may also to give same front area to each leader, then they will fight with same enemy, but without coordination.

  24. Posted · Edited by Rydygier

    Note: Its rather hard to disable debug mode, I had to edit RydHQInit and change those "if" conditions to disable it.

    Yeah. My mistake. To play without debug there must be not defined RydHQ(B)_Debug at all (nil) or changed to false during play/after HAC init. Repaired that.

    ---------- Post added at 14:32 ---------- Previous post was at 13:23 ----------

    Just implemented (not tested yet, I wonder, if this work) optional "fronts" mode. Concept is based on "locations", because this gives me possibility to very easy & quick test, if given position is in front area. Mission maker will have to set particullary named, empty trigger with shape, size and direction corresponding to planned front sector and should remember, to set objectives inside front and, if there are also other leaders for that side, to set limited control for leaderHQ to avoid strange situations. HAC will automatically set configured identical to this trigger location. How front works? Simply. Given leader will pay attention and take into acount only enemies currently located inside given front area. This is all. Its forces will be send only against such enemies, also flanking routes will be based and calculated only on enemy groups inside front area. However controlled by leaderHQ forces may be localized outside front, also leaderHQ may to set waypoints outside front when issuing orders agains enemy inside front. Given area may be covered by more than one front area, also chosen area may stay not covered at all. Controlled by given leaderHQ forces may to attack also enemies from outside, but only if they "by the way" completing they mission come across such enemy group and decide to engage, beacuse this behavior is not controlled by HAC. I'm not sure, but I think, that in similar (trigger&location) way may works zone setting in DAC.

  25. Posted · Edited by Rydygier

    Setting hight for UAV is not a problem, limited speed also, but I affraid, that on higher level its spotting ability may be worse due to greater distance to targets. It is also very easy to set individually by init field (this flyinheight 200;this limitspeed something) so perhaps this I leave to mission maker. Careless will be added however by HAC.

    About choppers without ammo: teoretically such choppers should stay on ground except recon missions, but maybe I manage to add some additional filter that will check every cycle, if there is such chopper in the air and to make it land at its initial position if so.

    About topography: some time ago I saw this clever Ruebe's code, but still had no time to test it also it maybe quite heavy perhaps. Maybe in some future version... For information purpose: currently HAC utylizes four different methods for finding suitable position:

    1. "Field of view" scanner - code, that looks for places with not blocked (but only by terrain) FOV in given direction at given area for given distance (is set to 320 meters not blocked by terrain field of view). It is based on stepping comparison of differences in height on distance between the point of being checked, and point which is to be visible. It is rather heavy (many iterations) - used often in defend mode. This are those black dots in defend mode.

    2. "SelectBestPlaces" + "surfaceisWater" scanners for finding given kind of terrain (forest or city for infantry, on the contrary for vehicles, and of course not sea...);

    3. FOs choose their positions on recon mission by randomization of 50 points around target area and choosing most elevated amongst them;

    4. For idle guard and defend hold position missions there are sometimes chosen positions at nearby roads (unfortunatelly regardless of some safe-system, sometimes also on roads).

    Also I'm aware about fifth method: by finding nearest location of "Hill" type or other types, but this one is not implemented and not tested by me.

    About file formation and aware for idle groups: Decided, that file formation will be given only, when infantry actually is in aware (there is one kind of mission, when long movement and aware are togheter - main flanking maneuver). Why not for idle and safe movements? Because in aware mode groups starts to look for terrain covers, rarely use of roads and often moving with rised weapon. EDIT: added also for movement from "halfway" point to target point, if halfway was assigned for cargo.

×