Jump to content

Rydygier

Member
  • Content Count

    4421
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

843 Excellent

About Rydygier

  • Rank
    Second Lieutenant

Profile Information

  • Gender
    Male
  • Location
    Poland, Pomerania

Contact Methods

  • Twitter
    _Rydygier_
  • Google+
    +Rydygjer
  • Steam url id
    rydygier
  • Linkedin
    witold-narwojsz-534183119

Recent Profile Visitors

3079 profile views
  1. Rydygier

    [SP] HETMAN: War Stories

    It's rather pure Big Boss way, without any additions. Which means series of locations to take in order to win. After all - HAL in HWS includes Big Boss already, just unused in normal modes, so it was natural choice to wake him up. Main problems are "space to forces count" ratio, which from one end affects gameplay, from the opposite - CPU performance. Small amount of units will make the gameplay rather dull most of the time - travelling long distancies from location to location through mostly empty landscape, probably less exciting, than you hope - while big amount of units will choke the CPU. Workarounding that via gradually spawned reinforcements would require brand new scripting and will not solve everything, just mitigate the issue a bit. For example - one way or another, taken locations may require garrisons. Also, since it is not player-centric battle, one way or another vast area need to be populated with AIs densely enough. Another way would be to reduce the area of the campaign, but that's against the whole map idea. Only amount of locations picked as strategic will be limited. Anyway, for now I just want to make it functional anyhow. Improving is more long term goal. Maybe in time I'll incorporate some HAL-friendly variant of caching, similar to Zorrobyte's concept, who knows. Good news, it is implemented already, from the beginning IIRC. All units of your side are set as switchable/playable. Use default Arma way to teamswitch between playable units (U key in my case).
  2. Rydygier

    [SP] HETMAN: War Stories

    Thanks! Glad to hear you like it. Some types of GUI elements provide scrollbars. Unfortunatelly - this is not one of them. AFAIK I can't even dynamically change its size or font size/number of the rows. If I do not find any other element type, that could work instead of this one, but with the scrollbar, the only thing, I can is enlarging hardcoded element size and number of rows (with reduced font/row size), but there will be still a hardcoded limit of factions, that will fit within GUI boundries (seems 50 is reasonable meximum per single column). My advice would be disabling mods, that provide factions, you don't plan to choose. BTW currently I'm implementing "whole map" mode using Big Boss, it's tedious - many code adaptations required, also not sure, how it will turn out in terms of gameplay fun factor. Most of the time it will be like empty locations capturing one by one and much less actual fighting, while gameplay will take much longer. Also I must significantly increase amount of forces per side to cover such big area, which means extra CPU load.
  3. 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.
  4. 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.
  5. 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".
  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.
×