Jump to content

Rydygier

Member
  • Content Count

    4419
  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by Rydygier

  1. Rydygier

    [SP] Pilgrimage

    Introduction The beauty of Pilgrimage is its effective combination of soldiering sim, orienteering adventure and detective mystery. PCGamer's "Mod of the Week" Alex, freelance PMC, is looking for the body of his brother, recently died on Altis during search of something very dangerous hid by their father. Island is in chaos after civil war, is terrorised by numerous bands of unleashed mercs and other marauders. Even worse, Alex knows only, that his brother fell at one of so numerous chapels or churches. It may be long, risky journey... Pilgrimage is free roam, semi-randomized open whole map SP mission with optional plot to follow set on Altis. I basically combined several well or not so well known ideas, few scripts etc into kind of semi-procedural mission adjusted for my personal taste and use. Should be liked in the first place by "lone wolves" who appreciate freedom of choice, yet want to be motivated by some certain goal and act for a reason. This mission is highly customizable. Gameplay dynamics is, depending on settings not very high, there are long intervals of calm journey across whole island separated by fights of various density if player choose to fight or is surprized by enemy. One gameplay may took many hours. It is designed as mod-friendly and should work fine with most FX, AI and immersion enhancers. Armaholic mission preview by RoyalGamersUK - Thanks! Mission Guides etc Leadminer21 aka alky_lee, an experienced pilgrim, prepared great compilation of useful informations, observations and advices about Pilgrimage gameplay. This invaluable source of knowledge is a must read for all new on the pilgrims' pathway: MISSION GUIDE TO ACCOMPANY PILGRIMAGE by Rydygier Excellent playthrough by BeachAV8R: Pilgrimage - AAR vol. 1 Pilgrimage - AAR vol. 2 Great youtube playthroughs for various mission versions (links to the first parts, follow the links provided there to continue watching): by Scott of Royal Gamers UK, first run by Scott of Royal Gamers UK, second run by leadminer21 by leadminer21, with mods by Starfish by llegostackr by Titus Groan, 1st by Titus Groan, 2nd by Carl Meyer Thanks to all! 🙂 My own playthrough with some features and specifics explained Download Altis, Bornholm, Chernarus, Lingor: Dropbox via Orangedox (1.951) Dropbox via Orangedox (1.951 open Altis) - open folder MANW contest edition Big thanks to all, who voted and supported my work! 🙂 To Do WIP 1.95_beta5 1.95coop_wip7 1.95coop_wip8d 1.95coop_wip10 It is my own "dev branch". Here I'll try to update the file on an ongoing basis each time, I find and fix any bug, so impatient may use it instead wait for the fix in the next official version. Please, play without -noLogs startup parameter, and provide me RPT file (path to the folder like: C:\Users\Rydygier\AppData\Local\Arma 3), if any issue encountered. latest fixes: - content from DLC, player doesn't own, shouldn't be spawned as loot, vehicles or AI units; - redone inspecting vehicle (each part treated separatelly insted of damage/setDamage approach, no FF taken, if inspecting not possible, for example no toolkit and difficulty at least Very Hard and fuel 100%); - updated credits; - significantly more doctors and mechanics, better chance for a doctor, than mechanic; - body has to be actually spotted before loading action available; - "NW" tooltip correction; - main settings track for Chernarus port a bit louder; - no more error message about lacking windMedium sound at the intro begin; - added green exclamation mark 3D icon to indicate recruitable POWs positions; - improved setting initial direction of the boat; - blue-3D marked civilians offering special services will not loose their icons after asking them for the intel; - Stuff sellers. Unofficial editions Download links to Pilgrimage custom versions/ports made by other people will be put/updated there if requested. In matters of these editions, please, contact their authors. a2012v's edition (v2016-08-05): Vafana's editions (v2016-08-22): rsoftokz's Tanoa edition thread Pilgrimage - Ported - ports compilation thread Changelog Requirements - Arma 3 Features - whole map reasonably yet dynamically each play initially populated with enemy garrisons and patrols with few possible behavioral patterns. Nothing is spawned later, every kill counts and has meaning; - dynamical adding of random loot to some buildings. Such buildings are, until checked, marked by 3D icon if player close enough; - cameral plot with some small, nasty surprise; - across whole island may be found few dozens of empty vehicles ready to use. If known to player, for easier spotting, also marked by 3D icons if close enough; - context-sensitive jukebox playing with reasonable intervals A3's tracks depending on situation (safe/enemy spotted by player/player spotted by enemy); - simple caching system to keep performance on decent level despite many groups on map; - fuel fund used for fast travelling and repairing or refueling player's vehicle; - kept as high as possible compatibility with mods. Recommended addons - Bigger Trunk addon (experimental); - INCOGNITO addon (alpha7: experimental) - Description; - TPW MODS; - some custom factions/weaponry addons for bigger variety of opposition and loot (African Conflict, CAF Aggressors...); - unlocked uniforms; - Dynamic weather (with init delayed by 30 minutes - In tort_DynamicWeather_config.hpp set "delaySeconds" to -1800 before starting Pilgrimage.); - any preferred low level AI enhancers (bCombat, ASR AI...); - any preferred sound and graphical FX enhancers (JSRS, Blastcore...). Credits & Thanks - zapat for code, that inspired some improvements of my garrisoning functions; - torskee and Law-Giver for language corrections and some new phrases for Alex; - Leadminer21 aka alky_lee for mission guide pdf. Known issues - some mods may cause "no sound at init" issue, often with on screen config errors. In such case troublemaking mod should be found and disabled, then mission restarted without it. Alternatively issue may be "wait out" (should disappear after some time); - since A3 v1.32 was observed sometimes minor issue with not visible "yellow actions" like "sell content" action for the boxes. Usually is enough to approach the box/other object again, otherwise save/load may be suggested. In some cases, if you play with AI companion, may be worthy of checking, if he could perform unavailable action for you via 0-6 order menu; - due to interaction of fast travel and caching system in rare situations may occur enemy units appearance "out of thin air" before player's eyes if hostiles was cached near target position. Tricks and advices - If you got green mark and message about finding the body, it is most likely not farther than 50 meters from you and you had not obstructed LOS towards the body position. If finding brother's body seems too difficult, you may temporary set Terrain Details in video settings to "LOW" to remove grass etc. To load the body bring your vehicle not farther than 10 meters from it and use load action at body. Then guard this vehicle well until reach the boat. - to enable unlimited saves: CONFIGURE -> GAME -> DIFFICULTY and enable "unlimited saves"; - to get a few more FPS, if you not loaded any saved game yet, try to save then load this save. For me it gives noticeable improvement; - game crashes (CTDs) during the mission may have various causes, but some of them, especially those happening at init, eg during loading screen, also probably some weird errors with vanilla config breaking loading screen may be fixed by allowing more RAM for Arma 3 (seems, Pilgrimage needs lots of it during initialization due to lots of things to set). This may be done via -maxmem startup parameter, eg -maxmem=6144 if you have at least 8 GB of RAM or even -maxMem=8192 for 16 GB of RAM. Lower value may be sufficient though, not tested. Should be higher, than 2047. In the Arma's own game launcher this parameter may be set in parameters -> advanced. Same trick may help to reduce greatly initial lag, making initialization much smoother;
  2. Rydygier

    [SP] Pilgrimage

    No. Nothing with the wind. There's a single code line, that makes initial ground fog disperse in time, that's all in the scripts.
  3. To let know out of dev branch discussions and for various insights about usage of this command. Please, share with own observations, if any. Tried new calculatePath command. Finds a path from Kavala to Pyrgos in 5-6 seconds. Then tested by putting BIKI example into some terrain-wise difficult cases. Troubles was expected and indeed encountered: 1. Destination cut off by water A: - Code: sleep 1; time1 = diag_ticktime; isNil {(calculatePath ["man","safe",(getMarkerPos "Start"),(getMarkerPos "End")]) addEventHandler ["PathCalculated",{ hint format ["time: %1",(diag_ticktime - time1)]; { _mrk = createMarker ["marker" + str _forEachIndex, _x]; _mrk setMarkerType "mil_dot"; //_mrk setMarkerText str _forEachIndex; } forEach (_this#1); }];}; - positions: - result: - time: 29,4s w/o drawing part Kinda expected - code goes to swim only, if there's no any land path and it checks everywhere for it first. That would be my explanation of long execution time. 2. Destination cut off by water B: - code: same, as in test 1. - positions: - result: NONE - gave up after two minutes of waiting. - time: ? Well, cause may be similar, as in test 1, but despite visually simplier situation, algorithm might have much harder time, maybe searching even larger area due to its logic. Not sure. Anyway, that's a warning about that command's use. Can keep you hanging forever in certain cases. 3. With loadingScreen - code: sleep 1; time1 = diag_ticktime; startloadingscreen [" ","RscDisplayLoadCustom"]; isNil {(calculatePath ["man","safe",(getMarkerPos "Start"),(getMarkerPos "End")]) addEventHandler ["PathCalculated",{ endLoadingScreen; hint format ["time: %1",(diag_ticktime - time1)]; { _mrk = createMarker ["marker" + str _forEachIndex, _x]; _mrk setMarkerType "mil_dot"; //_mrk setMarkerText str _forEachIndex; } forEach (_this#1); }];}; - positions: - result: NONE - code stuck behind loading screen. - time: ? I'm doing something wrong or it's a no go. A bit pity, it can't be speed up behind loadingScreen veil - will stuck forever there, maybe because it spawns an AI first and waits for it while simulation is suspended and spawned AI never ready? Now, to leave some specific question, I was planning to use it in the function checking, if there's a land path possible between two positions. Sadly, long execution time, if there's no such path paired with loadingScreen incompatibility makes this approach impractical and leaves me with only simplified scripted solutions that would, say, check for water along straight line between two positions etc. imperfect workarounds, unless I miss something here? BTW I guess, path points density isn't customizable? If someone's wondering, tried also with boats to see, if it will take into account peninsulas etc. with this code: sleep 1; time1 = time; isNil {(calculatePath ["boat","safe",(getMarkerPos "Start"),(getMarkerPos "End")]) addEventHandler ["PathCalculated",{ { _mrk = createMarker ["marker" + str _forEachIndex, _x]; _mrk setMarkerType "mil_dot"; //_mrk setMarkerText str _forEachIndex; } forEach (_this#1); diag_log "hop"; hint format ["time: %1",(time - time1)]; }];}; It does: but: And if destination is on land: ...it goes weird but hey, what to expect? and opposite: Didn't tested: land unit, both points on the water, land unit, start on the water, land unit, end on the water, boat, one point on the isolated water area (lake), other on the sea or another lake. Finally - does this EH code run twice? Diag_log check confirms that. In total my impressions - most welcome command, great to have it, but somewhat risky in use (a risk of long, even infinite like long execution times, if "unlucky" at picked positions), and giving weird results in some weird situations. In current state impractical in some supposedly promising uses.
  4. Happens in TAC-OPS? If does same also without any mods, would suggest game bug indeed. Similar story may be with elusive bug known as "the heli explode, each time my AIs gets in, and then suddenly not anymore".
  5. Introduction HWS is meant as very easy in use generator of dynamic, interesting battles conducted by HETMAN commanding AI. Unique each play battle experience powered by very complex scripting is created with few mouse clicks. No addons required. Optionally at init player may customize the gameplay by choosing fighting factions, scale of the battle, daytime, weather, forces ratio, persistency of the result (campaign mode, where results of past battles slightly affect every next battle) etc. Additional text field allows advanced users and Hetman veterans to apply also more complex setup code or even regular script, that will be executed at init. Resulting battle may vary greatly each try. War has many faces, nothing is guaranteed. You're only one of many cogs in the war machine controlled by HETMAN, so do not expect any special treatment. Those battles aren't player-centric in any way. One time you may found yourself in the middle of fierce firefight immediatelly, another time you may be kept as reserve long time before you see any action. You may die in the first few minutes or survive to the end without a single shot fired, but with few clicks in the legs. Both extremes are not very probable, but possible and perfectly OK - just do your part or act on your own. Create own war stories. HWS will utilize also units from custom addons when loaded if addons have configured properly groups. Additionally, player may any time via supports menu (0-8) activate passive spectator mode based on Smart Camera script, that will turn the game into kind of war movie to watch, showing autonomously chosen interesting spots of the battlefield - all without any interaction required. That mode may be switched off anytime by pressing a keybord key. In the same menu player may find also other useful in-game switches. Download HWS 1.06 (Armaholic) HWS 1.09 (Dropbox via Orangedox) HWS 1.09 open (Dropbox) - open folder WIP It is my own "dev branch". Here I'll try to update the file on an ongoing basis each time, I find and fix any bug, so impatient may use it instead wait for the fix in the next official version. Latest fixes: Changelog To do - tone down influence on the morale of previous defeats; - manual scene switch key/mode for spectator; - saving and restoring battles; - wrong unit is chosen a TL for mechanized squad?; - smoothening movement of camera in spectator mode, when attached to the vehicle (if possible...); - reducing camera interest on groups of unarmed, not moving vehicles; - investigate strange orders for tank platoon crews to abandon tank and take cargo places in commanding tank if one tank is disabled (vanilla bug?); - investigate repeating rest & regroup orders. Recommended addons - TPW MODS (especially for HUD feature); - any preferred low level AI enhancers, that doesn't mess with waypoints (bCombat, ASR AI...); - L_ExShake & L_Twitch; - some custom factions addons for bigger variety of forces to choose from (African Conflict, CAF Aggressors...); - Dynamic weather; - any preferred sound and graphical FX enhancers (JSRS, Laxemann's "Enhanced Soundscape", Blastcore...).; - Liability Insurance 1.1 (units hit by allied vehicles will take no damage, ramming enemies to death still possible - workaround for AI drivers hitting infantry, recommened, until BIS will fix driving AI); - RHS Merge (RU) - addon for RHS: Escalation users only, that merges all RHS' subfactions of OPFOR side into one faction, what enables for Hetman all russian equipment from RHS to choose from (put the pbo where all other RHS' RU pbos are. Then new faction named Russia (All) should appear in the initial settings window for EAST side. Choose it); Porting HWS to another map Although official ports will arrive not sooner, than when this version reach final state, porting process is easy and not require any scripting knowledge, so anyone is able to prepare port indepedently by following these steps: 1. de-PBO mission file using any tool doing that, eg from here; 2. locate resulting folder, where all mission folders saved in editor are (Win7 usual path: C:\Users\<user name>\Documents\Arma 3\missions); 3. Launch Arma 3 with custom map addon, where you want to port HWS, and whatever this map requires (only, no other addons!), enter editor with Altis and load this mission; 4. Copy (select and ctrl+C) all objects present on the map; 5. Load in editor empty target map and paste on it copied objects in any suitable place (sc1 object's location will determine initial GUI screen camera shot); 6. Set copied unit (dummyPlayer) as player unit; 6b. (Ignore this point, unless you're porting mission to the map from older games of Arma series (OFP, Arma 1/2/OA)) For A2 and older maps, additional step is required: Add in editor another object: an empty, square trigger, that will cover exactly whole map (not absolute exact, but best, if will fit maps size pretty well). So, trigger should be placed in the very center of the map and have radius equal to half of the map edge length. This trigger must be named: RydBB_MC. Length of the edge should be divisible by 500 (single sector dimension). Here is working example for Takistan map (HWS 1.06 beta 3 version, requires AiA TP and CBA). 7. Save the mission; 8. Go, where you stored de-PBOized HWS, copy everything inside HWS' folder except mission.sqm and paste that as is into newly created mission folder; 9. Return to the editor, reload and preview new mission. If is working - Mission is ready for use/pbo-ize. Notes - Idea behind HWS is to give HETMAN experience for all, also those, who up to now considered HAL as complicated to use; - HWS is on early development stage and wasn't thoroughly tested yet. I'll be grateful for solid feedback, any opinions, suggestions and ideas. Don't be silent - give me a word, if you're interested in further development of this. My worklist priorities are dependent on users' interest; - scripters and Hetman veterans may find the GUI text field very useful for advanced mission/Hetman/spectator mode setup eg by pasting favourite init configs. However keep in mind, not all Hetman settings have a sense on this stage. Hetman is set for the battle in quite simple way, no Big Boss for now; - yes, Hetman in HWS is able to make good use also for custom content without any manual RHQ mambo-jumbo. Is used special piece of code, that constructs RHQ set automatically. It is based on assumption, so unit's config is following some typical patterns established by BIS' vanilla configs. Weirdly configured custom units may be misused. Yes, I'm planning to apply this thing as option also for standalone Hetman addon. Hopefully soon; - used settings are stored for the next play. Hit ESC key to restore defaults. - heard, so in A3 1.24 some core artillery control scripting commands are malfunctioning. If so, artillery may not work as intended until this will be fixed by BIS. Mission is released under APL-SA license. Voice acting: DuddBudda, SiC_Disaster, nettrucker. Enjoy the war stories. Rydygier
  6. Rydygier

    [SP] HETMAN: War Stories

    Hard to say, it will basiacally make sides morale 25 times less sensitive to losses and such. IMO anything > 10 will practially make morale factor negligible. But, as you noted, there are also other than morale reasons, that may end the battle. If you make sides invulnerable morale-wise you'll start to see endings due to killing Leader unit or losses reaching 75% or too few forces left to take an objective (10 units by default) or even probably most rare - all units of one side farther, than 5 km from the battle center, but, I would guess, without "morale broken" ending possibility there will be also higher risk of never ending stalemates, like both sides bled out, but below 75% and stuck in defensive mode forever etc. BTW technically player can break the stalemate by finding and killing enemy Leader unit, which in time should break this side morale no matter, how high RydHQ_MoraleConst is. Anyway, due to 75% losses treshold, there is rather no risk of "searching for the last enemy hidden somewhere" situations.
  7. Rydygier

    [SP] HETMAN: War Stories

    Not sure right now, probably would need custom RHQ categorization - the units, that shouldn't be moved may be marked as "static" for instance. Applying such RHQ definitions should be possible via Advanced setup window, but again - not sure right now. Lately added way (wip version linked above): no armor setting. How exactly you imagine such customizable conditions? Not impossible, HAL has Big Boss after all, but current code is not designed in that direction. This may be some challenge. Not sure, what actually means "multi-terrain", never really played DUWS, but anyway porting HWS is described at the beginning - very simple. Exactly. If you think about it, it's really weird, they didn't. Such stuff fits perfectly Arma. There was something in A2 though IIRC. Mentioned variables are multipliers of Hetman's sensitivity to the factors changing morale in plus and in minus. This way: _morale = _morale + ((_balanceF - _lossWeight)/(_HQ getVariable ["RydHQ_MoraleConst",1])); _morale = _morale - ((random (_diff * 10))/(_HQ getVariable ["RydHQ_MoraleConst",1])) _balanceF - own forces/known enemy forces strength ratio factor _lossWeight - own losses factor, where older weight lesser (mostly for simulating an impact of recent, big losses shock) _diff - IIRC, total attrition factor As you can see, RydHQ_MoraleConst is a divisor of morale change value. The higher - the less morale will change. Can be as big number, as Arma's engine can properly compute in theory. Ctrl+c/ctrl+v should work in Advanced setup window... Thanks for that valuable input. Not sure, if I'll spend more time with HWS in the near future, but who knows...
  8. Rydygier

    [SP] HETMAN: War Stories

    Well, that depends. In some mods one faction contains all/only the tanks, other all the infantry - sometimes intermingled would be desired state. So player would need to have a switch to turn factions separation on/off. Since such thing (faction separation) isn't present in the current code at all, this requires some consideration, maybe someday... Thanks for the feedback. 🙂
  9. If fast roping does work in vanilla, but doesn't work with certain mod, I suggest either play without that mod either use touchdown disembark variant instead of fast roping. If however same issue happens during play without any mods, then it's either HAS bug either maybe some errors with doors/ropes config in your mission, both could be possibly fixed our end, if you provide vanilla repro mission. In any case, properly, if there's more units, than ropes, extra units should wait for their turn, not trying to go down simultanously. 1. Using simple scripting, perhaps inside some trigger activated at chosen moment. Quoting manual (recommended to read it): Unit1 setVariable ["RYD_HAS_canCall",false];//this will hide HAS actions for Unit1 In MP it may look this way if not run, where unit1 is local: Unit1 setVariable ["RYD_HAS_canCall",false,true];//this will hide HAS actions for Unit1 HAS 1.9 should give more options in this regard allowing selective switching availability of the calls per type per unit or globally. Newest wip version in HAS script topic does that already. 2. Other possibility, maybe better for you: If you want to allow all units initiate transport task by entering the heli, but only some of them to call helis by radio, set required item class in the config (RYD_HAS_RadioReq) and give that item only to some chosen units.
  10. If you prepare me pure vanilla repro mission, I'll gladly investigate this issue, without it can't do much, since it doesn't occur in my tests. EDIT: if you're using scripted version, first be sure, your RYD_HAS_DoorsToOpen array in userConfig.sqf is properly filled (or left empty). First element of each entry should be heli name (not group name etc.).
  11. You don't. In current mod version user need to use external respawn solution, if required. But you may try newest scripted version of HAS 1.9, where such option was added into HAS. Described here. Of course eventually the mod should be updated to 1.9 too. It's around door animation code. Are you sure, you synced with the module helicopters, not their groups or something? Is that vanilla heli or mod? With vanilla I get no such error, but some code improvement here may be in order for 1.9 anyway, not sure yet.
  12. Rydygier

    [SP] HETMAN: War Stories

    It was long time till last update, not quite planned to return to HWS now, but it sorta happened. For now it's just a "wip" in open form - I'll appreciate any feedback, bug reports etc. HWS 1.10 wip1 Changes: 1. New "Armor Density" setting: NONE. If chosen, both forces should be composed statistically around 80% of infantry and 20% of motorized (+supports). No mechanized/tanks. May be useful, if player wants more prolonged battles, especially on maps with lots of flat/open areas. 2. New "Faction" setting: MULTI. If chosen, additional list should show up with all factions of selected side. It allows to choose multiple factions per side (forces should be randomly picked from the pool of groups from all selected factions). Could be especially useful with mods, that make every type of forces a separate faction. If at least one side has no faction selected, pressing start mission button will be efectless. 3. New code for spectator mode. I guess, not many even uses this mode, but I couldn't resist to try this anyway. I called it "natural cam" (or shaky cam) because the aim was to make camera shot looking less artifical, and more like the camera operator was a human being (camera stabilized, but controlled "by hand"). So the script tries to mimic imperfections of human reflexes and accuracy - if current target swiftly changes speed/direction, camera adaptation may be delayed or inaccurate, requiring corrections. Usually works nicely with vehicles, sometimes gets choppy for infantry though, not sure, why, it is per frame loop, same code works well with vehicles, so this may be not fixable. Sometimes it produces really immersive camera work and in general I like it much more, than previous camera code. Here's a sample (that BTW demasks occasional dullness of driving AI) :
  13. HAS 1.9 wip6 Requested: optional feature to speed up heli's availability after task completion: RYD_HAS_FastReady = true;//if true, helicopter will be ready for another task at the begining of his RTB, not at the end of it. So, player should be able to call the same heli again just after disembark at destination/just after cargo drop/CAS provided. Of course in case of cargo, heli must anyway return to the base to pick up another container. That's the idea. Thing is, these parts of logic complex and easier to break than improve. This was tested in SP for troops transport only with few basic situations. That's not enough. If anyone interested in helping - much more tests in all three types of tasks SP/MP with/without middle waypoints feature enabled/disabled would be appreciated.
  14. Correct. Not the call limit, but will reduce RYD_HAS_RespawnHelis value (it defines separate limit for respawns). Unless RYD_HAS_RespawnHelis = -1; (any negative number to be exact), in that case there's no respawn limit. Call limit is decreased by 1 every time, a call is initiated and only then. So there are two independent limits: for calls and for respawns. To clarify: newly spawned heli will not automatically pick up a call, that was interrupted due to previous heli destruction in the middle of it. Helis will keep respawning when destroyed regardless of call limit, as long respawn limit is not equal to 0. Unless you have RYD_HAS_RemoveAtLimit = true;. In this case, whole HAS script will exit, when call limit down to 0. Respawns included.
  15. HAS 1.9 wip5 Added new variable: RYD_HAS_RespawnHelis = 1;//if positive, destroyed/immobilized HAS helicopter will be after 60 seconds replaced by new one, placed, where destroyed was placed when was added to HAS. Old one will be deleted along with the crew (to avoid potentially unlimited objects accumulation). Value represents number of respawns. 0 - disabled, -1 - unlimited It is now set to 1, but by default will be 0. "Immobilized" means grounded due to damage, without the pilot or fuel. This value can be changed on the fly, but it's not recommended. Helis added to HAS when it is equal to 0, will be ignored, also those destroyed when 0, may be not respawned, if later variable changed to other value. Let me know, if that's useful and if it works in various circumstancies. NOTE: although vanilla createVehicle supposedly tries to spawn a vehicle at some safe place near, if exact spot is blocked, from own experience I would recommend to avoid placing initial helis or adding new later, that at adding them to HAS moment are located in some weird/risky as for collisions places (or mid air...). Also better do not block such position with any objects later. But if anyone will do some tests, please, try thses things, I do not recommend to let us know the actual fate of spawned helis in such cases. To do: if CAS heli is destroyed during firing at the area, CAS task map markers seem to stay, should be deleted.
  16. Rydygier

    FSM vs SQF

    Therefore IMHO scheduled is better always except the case, where accurate execution timing is essential. Also never liked FSMs - too used to do stuff in SQF, complex or not.
  17. HAC 1.47 released. HAC 1.47 (Armaholic) HAC 1.47 (Zippyshare) HAC 1.47 (Dropbox) INTRODUCTION The addon â€HAC†is intended to enliven the battlefield in the same way that having a human leader would do. HAC does not deal with the manner in which orders are executed (unit level), but deals with the issuing of orders. In other words, this addon gives one or both sides of a conflict a field-commander level AI. One of most important goals of this addon is to keep high compatibility level with other addons, in particular those that extend the possibilities of AI for units and groups. HAC control is mostly based on issuing waypoints, and as far as possible HAC avoids interfering with low-level AI. In other words, HAC focuses on giving orders, rather than on the way in which orders will be executed. HAC gives new, higher level AI, rather than changing the existing AI. There are only a very few exceptions to this rule. HAC should therefore enrich the gaming experience with new features, without conflicts with other addons. HAC is intended to complement their effects rather than to compete with them for control over units (at least for those addons that do not mess with waypoints). HAC can serve as an instant battle generator as well as a general player opponent, or as base for complex missions and/or gameplay modes. 1.4 and above versions needs OA (CO) 1.62 or higher. Addon version requires Community Base Addons. ----- USAGE To activate HAC for one side, one of the units of that side must be named LeaderHQ. Essential also is the placement on the map of any object (for example, an empty trigger) named RydHQ_Obj1. The location is entirely your choice. Its position will designate a target point which the Artificial Commander will try to conquer at first (for example, a spot near the leader of the opposing side). Analogously, there should be placed in freely chosen areas (eg in cities, strategic positions or simply nearby opposite Leader) three other objectives (RydHQ_Obj2, RydHQ_Obj3, RydHQ_Obj4), which will be conquered in numerical order. If the mission designer wants less than four objectives, then simply place the unneeded objectives at same position as the ultimate objective. For the script version only, to initialize HAC the following code should also be executed in some way, e.g., by placing the following script in the init field of any object (for example, in the activation field of an empty trigger or waypoint): nul = [] execVM "RydHQInit.sqf"; Alternatively, that line may be placed at the end of a mission's init.sqf. Init.sqf is recommended place for init config variables (beacuse of better readability), especially for bigger configs, eg containing RHQ arrays. For MP client-side compatibility (script is run only on server, but client-side players should have visible tasks assignd by Leader) needed is always function module on map, and, for BB only, RydHQ_MC trigger (customized battlefield area). See included manual for all details, and there is lots of them. ----- RHQ CONFIGS THREAD For easy copy&paste at once all RHQ array sets with class names of new units. Use RHQ array as any other HAC's init config variable. Best: paste needed RHQ as is into init.sqf file (before nul = [] execVM "RydHQInit.sqf"; line, if HAC script version is used, same as for any other init config). Note, that for big arrays as RHQ can be, good practice is additional syntax check. Errors do happen. ----- ONLINE MANUAL Online manual for users, where anybody can leave own comments, notes, ideas and corrections visible to all other. ----- ALTERNATIVE SOUND SETS FOR RADIO CHATTER SoundSets (4) ----- HETMAN FOR ARMA 3 PROJECT Led by: zorrobyte (Thanks! :) ) "My ultimate goal is to simply get working as much as the A2 code possible in A3 while providing bug reports and documentation along the way to help development of official version." Repository Contact for interested: Skype: ross.fisher91 Forum ----- TO DO (closed for new ideas - HAC enters maintenance stage) ----- SAMPLE MISSIONS Created any kind of mission utilizes Hetman? Let me know, so I could link it here. LAST TRUCK Kind: SP Map: Chernarus Required game version: A2 CO 1.62 Addons needed: none Addons recommended: JSRS Estimated play time: 10-30 minutes Author: Rydygier Description: ----- MY THANKS ----- Earlier versions: Addon was created "by player for players", source scripts you can freely modify, copy, "cannibalize", to use in your projects. It is released under APL-SA license. I'll be grateful for notification about each such usage. I will be grateful for bug reports. Enjoy being under control. Rydygier
  18. Rydygier

    Pilgrimage - Ported

    I wonder, if anyone knows, what's the actual cause - what in the first post each update triggers spam alert.
  19. HAS 1.9 wip4 Mentioned disconnection of the caller should trigger transfering caller's privileges to another player same, as for killed caller event (good way to test: have two players, make JIP player to call transport, after it is confirmed - disconnect, switch to server player, wait for heli and see, if there are mouse actions appearing for destination/way of disembark choice). With hint message pointing new caller, but not sure, if it shows up.
  20. And here's yet another reason to "love" MP scripting: There's "PlayerDisconnected" event handler. When it kicks in, you cannot check, if current caller unit is no longer player-controlled, because at this point code still returns true for (isPlayer RYD_HAS_Caller) while it already returns different unit's owner (so we can't compare by owner, if that unit is a caller). LIke someone designed this in purpose this way... I can only put waituntil waiting, till caller unit will be no longer "isPlayer". But this EH kicks in for every disconnection, not only for caller unit, so this is hardly the solution. Luckilly, there's also "HandleDisconnect" event handler, that supposed to leave trace, what unit actually was abandoned by the player. Let's hope so...
  21. Hm. In fact, there's a problem, I need to deal with. If some player call the transport, his unit is designated as caller unit. Only this unit chooses flight destination etc. If that unit is killed, HAS handles that and another HAS-enabled unit becomes the caller. But apparently if the caller disconnects, his unit stays the caller, thus no one can choose the destination etc. So it seems, I need to add a code similar to one, that handles caller's death also for his disconnection.
  22. HAL 1.22 released. HAL 1.22 (Armaholic) HAL 1.22 (Dropbox) HAL 1.22 (Zippyshare) PDF manual HAL 1.23 wip for testing purposes. New config variables listed here. INTRODUCTION Same, as HAC for Arma 2, HAL is intended to enliven the battlefield of Arma 3 the same way a human leader would operate. HAL does not deal with the manner in which orders are executed (unit level), but mainly deals with the issuing of orders. In other words, this addon gives one or both sides of a conflict a field-commander level AI. The addon â€HAL†is continuator of A2's HAC for Arma 3. HAL 1.0 simply moves HAC 1.46 from Arma 2 to Arma 3. If you are familiar with HAC, you are ready to go. Others should check included manual and demo missions. HAL is relatively easy in basic use, but provides many optional features and config possibilities, that make HAL flexible, but also pretty complex mission making tool. Very few things was changed comparing to HAC 1.46 (MP, order notifications, artillery, some config variables…). However future versions of HAL may introduce new functionalities based on features provided by Arma 3. One of most important goals of this addon is to keep high compatibility level with other addons, in particular those that extend the possibilities of AI for units and groups. HAL control is mostly based on issuing waypoints, and as much as possible HAL avoids interfering with low-level AI. In other words, HAL focuses on giving orders, rather than on the way in which orders will be executed. HAL gives new, higher level AI, rather than changing the existing AI. There are only a very few exceptions to this rule, and generally these are optional. HAL should therefore enrich the gaming experience with new features, without conflicts with other addons. HAL is intended to complement their effects rather than to compete with them for control over units (at least for those addons that do not mess with waypoints). HAL can serve as an instant battle generator as well as a general player opponent, or as base for complex missions and/or gameplay modes. Addon version requires Community Base Addons. ----- USAGE To activate HAL for one side, one of the units of that side must be named LeaderHQ. Essential also is the placement on the map of any object (for example, an empty trigger) named RydHQ_Obj1. The location is entirely your choice. Its position will designate a target point which the Artificial Commander will try to conquer at first (for example, a spot near the leader of the opposing side). Analogously, there should be placed in freely chosen areas (eg in cities, strategic positions or simply nearby opposite Leader) three other objectives (RydHQ_Obj2, RydHQ_Obj3, RydHQ_Obj4), which will be conquered in numerical order. If the mission designer wants less than four objectives, then simply place the unneeded objectives at same position as the ultimate objective. For the script version only, to initialize HAL the following code should also be executed in some way, e.g., by placing the following script in the init field of any object (for example, in the activation field of an empty trigger or waypoint): nul = [] execVM "RydHQInit.sqf"; Alternatively, that line may be placed at the end of a mission's init.sqf. Init.sqf is recommended place for init config variables (beacuse of better readability), especially for bigger configs, eg containing RHQ arrays. See included manual for all details, and there is lots of them. ----- ALTERNATIVE SOUND SETS FOR RADIO CHATTER SoundSets (4) ----- TO DO - customizable scale of defensive perimeters; - problems with CaptLimit (doesn't work, spoil AAO?); - problems with AAO (only 2 objectives max at once?); - retasking (?); - code for effective usage of A3's UAVs?; - headless client support whatever it is (?). - alternative ("Eastern Bloc" like) attack doctrine mode (?); (wip: 1.?) ----- MY THANKS To all people, that helped me earlier with HAC and did first steps towards Hetman in A3 before me. But especially those, who funded me Arma 3 game, so I could release HAL so soon. ----- SAMPLE MISSIONS Created any kind of mission utilizing Hetman? Let me know, so I could link it here. HETMAN: War Stories ----- BUG REPORTING Any feedback, ideas, bug reports are highly appreciated. This allows me to develop Hetman further and faster. You can expect even faster fixing, if bug is reported properly. That means exact and detailed description of the problem and circumstancies of its occurance, any suspicious RPT logs. In most cases crucial is provided repro mission. That means uploaded, ready-to-play mission without any addon dependencies except HAL (so also CBA, bug must occur without any other addons), where I can reliably see reported bug "in action". Such repro is huge help. Helpful is also info about overall circumstancies, like kind of gameplay (single, server, dedi, client...), version of HAL (addon/script), game branch (stable/dev), if PC is good enough for Arma 3... ----- DONATIONS I'm with pleasure and satisfaction making scripts for free. This way it was, this way it remains. However fact is, I already spent many hundreds of work hours on scripting for Arma 2 and Arma 3 so far and this number is growing. So, if you want financially appreciate my efforts, or simply have no idea, what to do with money - here is the place. I do not expect anything, but any, even symbolic donation would be very helpful and appreciated. Will be also a sign for me, so my work is appreciated and needed. So, if you want... Donate ----- Addon was created "by player for players", source scripts you can freely modify, copy, "cannibalize", to use in your projects. It is released under APL-SA license. I'll be grateful for notification about each such usage. Voice acting: DuddBudda, SiC_Disaster, nettrucker. Enjoy being under control. Rydygier
  23. Meanwhile I just removed RYD_HAS_Access check, so regardless of this var, newly JIPed unit will get actions. In my tests it does the job - now that unit has options, that was lacking previously. Still need to be tested for possible side effects (+ few minor backstage corrections): HAS 1.9 wip3 PS Oh, it's today! 8th anniversary of my presence here (and, de facto, 8 years of my scripting journey).
  24. Figured, I can run Arma twice, where one instance hosts the server, and second JIPs in. So after all I can test this... No idea, what mess is going on about playable units in MP, it seems, if you tag a playable unit with setVariable then add to it some mouse actions or 0-8 options (that's the case for JIPable units synced with Base object), and after that JIP into it, the variable stays, but options/actions are gone (not a problem with AI disabled in the lobby, in such case perhaps actual new unit is spawned in at JIP, so have no variable tag yet and thus passes the check). Or is this something in my code causing this after all? I'll investigate this further, thank you for the assistance. 🙂 BTW found some stuff, I probably need to correct anyway, so that's a good thing.
  25. Ah, yes, indeed, otherwise we go through old array, before updating it with new players which leads us nowhere. To be 100% OK, it should be: foreach (allPlayers - (entities "HeadlessClient_F")); In this case he would be right. 🙂 We are going through rather typical debugging process, only this time I can't perform this myself. Thanks again, your help is very appreciated. So it seems, we overcomed the problem of new player not present in allPlayers for both variants. That's the progress. Now appeared, somewhere before this JIPing player gets his "access" variable true. This happens in three places in the code: 1. At the init, for the units initially included into RYD_HAS_STT array by hand or preliminary syncing with the RYD_HAS_Base object in EDEN: { _x setVariable ["RYD_HAS_Access",true,true]; _x addMPEventHandler ["MPRespawn", RYD_HAS_atRespawn]; } foreach RYD_HAS_STT; 2. Inside RYD_HAS_NewUnits function; 3. Inside RYD_HAS_atRespawn function, which is added as MPRespawn EH code as shown in p. 1. and inside RYD_HAS_NewUnits, in the same manner. Therefore unit can return true for _x getVariable ["RYD_HAS_Access",false] if it was already added into RYD_HAS_STT at init or if it was already added by hand via RYD_HAS_NewUnits. So it's a mystery. 😶 ...unless the player JIPs into AI unit, that was synced initially or added via RYD_HAS_NewUnits before. I would suspect the first case. (which BTW leads to the valid question: why even I bother with this feautre if all, what user needs in order to get same result is just initial syncing all playable units? Well, why not. it was requested, easy to do (not much code) and perhaps someone will want to keep playable units not synced for any mysterious reason. Still, it is kinda redundant...) Technically I could just not using "RYD_HAS_Access" check but instead do foreach ((allPlayers - (entities "HeadlessClient_F")) - _allPlayers) to run through all new players but that would be giving up on solving the mystery, which I don't like at all. And I'm not sure, if that would be 100% reliable (depending, what HAS user would do with some new players in other code before new loop cycle).
×