Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

628 Excellent

About Rydygier

Profile Information

  • Gender
  • Location
    Poland, Pomerania

Contact Methods

  • Biography
    I was born, now I live and I will die someday.
  • Twitter
  • Google+
  • Steam url id
  • Linkedin

Recent Profile Visitors

2351 profile views
  1. Last portion of 1.4 features to test: HAS 1.4 wip3 - fixed a bug with no destination choice actions appearing, if task was triggered by the unit entering the chopper at base, while player unit wasn't the first in the array (with current, syncing method order in the array AFAIK is same, as order of unit placement in EDEN - first placed unit will be the first etc.); - minor code improvements; - caller can now redirect the chopper during the transport if initially was't chosen "RTB" option (because adding such ability also for RTB task would require extensive rewriting of core logic structure). Method: if not RTB, action to choose "another location" will be not removed after initial choice and can be re-used to point new location during the fly again and again as long the heli reach current destination and enter landing pattern - at this point actions are removed. To cancel choosing, click on some invalid position - water or out of the map boundaries (hint about cancelling should appear). If you don't, new destination choice will be auto-cancelled just before landing stage at current destination. Initial choice of "RTB" is final, actions are removed immediately. I'll wait around 24 hours from now on, then, if no bug reports appear, I'll push forward to Gunter package for 1.4 release.
  2. Quite possible, unless I'll be flooded by new bug reports. :) Apart from that, I have just one or two more features to try, if possible to implement. We'll see. PS Indeed, initial code was 35 lines long, current is about 4000.
  3. Thanks. Good, the erros are gone. This way is by design, on Gunter's request. The goal is, to make able the caller to decide, when to send the heli towards the destination. Be it all aboard, only some got in or even no one in the heli. Before code was waiting, till all STT units was in. "More control for the player" approach.
  4. New wip for tests: HAS 1.4 script wip2 - now custom rope attachement points defined per each heli separatelly (helis have to be named in EDEN for that). - at destination choice two variants for choosing target location: touchdown, for traditional landing, and fast rope. Usage of the fast rope switch in userConfig removed. - added RYD_HAS_SafetyMargin = 10; user config variable. Value set here is added to the heli size when calculated radius for flat and empty area search at landing zone (where fast rope or RTB not used). 10 is reasonable minimum. The higher - the safer LZ as for collisions with map objects. The lesser - bigger collision risk, but also bigger landing accuracy (closer to the spot chosen by user). If 0 - only heli diagonal model radius will be used as search radius. If set with negative number like -100, final search radius is 0, thus collision checks ignored, but landing most accurate. Especially with RYD_HAS_AlternativeLanding = true; may produce hardcore landing accuracy experience indeed, but beware, where you mark the spot :). Without alternative landing in such case if there's object colliding at LZ, it may produce a bug of premature heli lift up. So, use with caution, decrease below default on own risk.
  5. After some tests - no problem. Most troublesome seems changing destination en route - not compatible with script's logic architecture, I've some idea, but chance is slim. Choosing method of insertion possibly easier, I'll look into it.
  6. Machine learning / AI projects using ArmA?

    You know, player also may use High Command. Also, he may be lead by another high level AI. There are players, that enjoy being thrown into some big battle revolving around, where player isn't a center of events, just one of the cogs in the machine, where armies of both sides are lead by the AI. Years ago I made high level AI commander (but not learning one, sadly) mostly for singleplayer, and it is still in use. Lastly there are some people, like me, enjoying just watching, how fancy AI does its thing. Well, that I understand - technical limits. The only way would be solo "MP" session...
  7. Machine learning / AI projects using ArmA?

    Maybe I misunderstood. Doesn't it command chosen AI groups against opposing side?
  8. Machine learning / AI projects using ArmA?

    Man, would be great to have such well trained (or still learning) neural network as high level AI opponent mod/script also for singleplayer.
  9. Added, works. :) In case, someone want to test newest changes, here are: HAS 1.4 script wip1 - now defining units, helis and prepared boxes (if any) same way, as in module: via syncing them with RYD_HAS_Base Game Logic. This should fix script errors when unused AI slots disabled in the lobby. - [unit1] call RYD_HAS_NewUnits; run server side works for me in this version. - if set on server: unit1 setVariable ["RYD_HAS_canCall",false]; unit1 losts access to HAS calls. Use: unit1 setVariable ["RYD_HAS_canCall",true]; To give actions back. Can be switched back and forth any time. Other stuff next time.
  10. Seems, above works and solves the issue BTW. Tested such code: [unit1] call RYD_HAS_NewUnits; (where unit1 is me, the player) In the singleplayer and on dedi, run server side only, for both variants - mouse actions and 0-8 supports and in all cases it worked for me - my unit, initially excluded from HAS actions, got that actions when added via NewUnits, and could properly use them.
  11. Tested. Disabled units are just not present. And the first error because of that appear already at userConfig's RYD_HAS_STT definition. I could catch nil variables later, but one rule: user simply can't add into RYD_HAS_STT variables, that he plans to make nil before HAS init. Not sure, how it could work otherwise. There's no error for the mod, as it reads synced units after some of them was deleted, so no problem here. Hm... An idea then. We have Base game logic there. What if to give up manual definig this array, same as choppers etc. entirely (or rather, will stay undefined by default, but may be defined manually and only then will be used), and by default use same way, as in module version also here? By syncing with Base object? Promising. Simplier for the user. I'll do that. Yep.
  12. Thanks for the feedback! I see the problem, not familiar, how blocking AI affects the disabled units (deletes them?), will test that to check, what's exactly is going on in such case. PS general request: if you want to tell me about any erros - include RPT logs of this error, please, knowledge, there are some errors may be not sufficient. Often isn't. EDIT: tested. Disabled units are just gone. And the first error because of that appear already at userConfig's RYD_HAS_STT definitioin. I could catch nil variables later, but one rule: user simply can't add into RYD_HAS_STT variables, that he plans to make nil before HAS init. Not sure, how it could work otherwise. There's no error for the mod, as he reads synced units after some of them was deleted, so no problem here. Interesting. Feel free to mention any differences between both version in any thread, it may be helpful. Then only one unit is supposed to use HAS features. That's how it works by design and the problems, you described, are expected in such case. If you wish only one be able to call, but several to be transported, add an assigned item class restriction and give the item to only one unit. GPS perhaps? Or just radio, most logical? Hm. Perhaps I'll add setVariable to optional disable calls for one of HAS-enabled units without any items juggling. Don't know much about JIP. Doesn't they just fill playable characters already defined and added to the STT? If so, it should work as is? Sadly, I've no means for testing HAS with more, than one player, the more on-the-fly, as I code, so I can work only blindly here, and only collecting feedback after release. Both rather no, I'm affraid. First may work for some, but become an issue for the others, if they want only some units of the group to be HAS-enabled. Second means, the code each time need to go through every single unit on the map to check, which at the moment has this variable. Some may be doable, some not, I'll think about them, thanks for the suggestions. HAS doesn't lock anything. Not touching that seats at all.
  13. Rydygier's Trivia Vault

    Well, I'm not willing to work on this right now, other stuff on mind, but you may try yourself. Here's not tested hint. Find this line: _unit setVariable ["RYD_INC_Compromised",((_unit getVariable ["RYD_INC_Exposed",false]) or {(_armed) or {(_wrongVeh) or {(_firing) or {(_recognized)}}}})]; and change it this way: _unit setVariable ["RYD_INC_Compromised",((_unit getVariable ["RYD_INC_Exposed",false]) or {(_armed) or {(_wrongVeh) or {(_firing) or {(_recognized) or {not ((toLower (uniform _unit)) in ["here","uniform","classes","all lower case"])}}}}})]; Lower case classes of uniforms, that should give you the chance for incognito put inside [these] instead of current content: ["here","uniform","classes","all lower case"] If also some other object - code in this line will change/become more complex depending on the kind of object (its location in the inventory).
  14. Rydygier's Trivia Vault

    Thanks. You mean Incognito, right? Rather not. As I see, uniform's config has no value for native side nor faction, so no reliable way to determine in the code, if given uniform should alarm someone or not.
  15. I did some test with said VTOL in 1.3 scripted, where Blackfish simply pretends to be a helo. And it kinda worked. I mean, this beast requires lots of room to maneuver or land, but successfully picked up and delivered my team in demo mission (but doesn't work well with slingload, seems unable to hook the box, only circling around). I still affraid, the code is not prepared for the vehicle of this size, mostly as for searching for safe LZ (too low flat&empty space radius), thus it will stay officially not supported in 1.3, but I just added small change in our next release, so also module will accept VTOLs (planes of "VTOL_Base_F" kind) as helis. Use on own risk.