Jump to content

Rydygier

Member
  • Content Count

    4421
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Rydygier


  1. Quote

    I'm guessing that the end results will be pretty much the same as playing the current release in campaign mode

     

    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. 

     

    Quote

    Hopefully you will also consider an option to choose a role

     

    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).

    • Like 1

  2. Thanks! Glad to hear you like it. 

     

    Quote

    add some way of scrolling through the list

     

    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. 

    • Like 2

  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:

     

    Spoiler

    calculate-Path-1.jpg

     

    - result:

     

    Spoiler

    calculate-Path-1r.jpg

     

    - 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:

    Spoiler

    calculate-Path-2.jpg

     

    - 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:

     

    Spoiler

    calculate-Path-3.jpg

     

    - 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:

     

    Spoiler

    calculate-Path-4.jpg

     

    but:

     

    Spoiler

    calculate-Path-5.jpg

     

    And if destination is on land:

     

    Spoiler

    calculate-Path-6.jpg

     

    ...it goes weird but hey, what to expect?

     

    and opposite:

     

    Spoiler

    calculate-Path-7.jpg

     

    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. 

    • Like 1
    • Thanks 3

  4. Quote

    Would a value around 25 be too high or make much in the way of a difference?

     

    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. 


  5. Quote

    I see some things that refer to AA vehicles and anti-air infantry, I can't seem to figure out if there is a way to exclude them from making an appearance. 

     

    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. 

     

    Quote

    I would also like to know if there's something that could be added there to prolong the combat just a bit more? HWS is great but battles that sometimes end in the middle of a fierce firefight are a bit of a letdown. 

     

    Lately added way (wip version linked above): no armor setting. 

     

    Quote

    Being able to set my own victory or defeat conditions would be great even if it's not particularly realistic. 

     

    How exactly you imagine such customizable conditions?

     

    Quote

    whole map dynamic campaign features

     

    Not impossible, HAL has Big Boss after all, but current code is not designed in that direction. This may be some challenge. 

     

    Quote

    multi-terrain feature hard or even impossible to implement, the community would probably create ported versions in a fairly short time period

     

    Not sure, what actually means "multi-terrain", never really played DUWS, but anyway porting HWS is described at the beginning - very simple. 

     

    Quote

     and I've often wished that BIS would build such a system into the base games.

     

    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.

     

    Quote

    how high those values can go before they break something or get dismissed? 

     

    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. 

     

     

    Quote

    Also, is there a way to copy and paste text into the dialog box? 

     

    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...

     

     

    • Like 1

  6. Quote

    The only comment is that the factions are all intermingled. It would be better if they worked as self contained factions perhaps with one attacking from the flank .

     

    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. 🙂

    • Like 1

  7. 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. 

     

    Quote

    Is there a way to have all players be able to go into a parked heli and request a drop and then in the field its only a certain few that gets to call in an airlift/supplies/cas?

     

    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. 


  8. 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.). 


  9. 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. 

     

    Quote

    Hi, im getting this error when i try and use the fastrope landing

     

    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. 


  10. 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) :

     

     

     

     

     

     

    • Like 3
    • Thanks 1

  11. 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. 

    • Like 1

  12. Quote

    So basically if the heli was placed at a base in the editor like at a base on a helipad then thats where it will respawn at correct?

     

    Correct.

     

    Quote

    This would also still reduce the call by 1 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. 

     

    Quote

    so then if you were at lets say the last call, and the heli got shot down, then it wouldn't respawn

    as your out of calls is that how it works?

     

    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. 

    • Thanks 1

  13. 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. 

    • Like 1

  14. 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. 


  15. 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...


  16. Quote

     I was well impressed with how it handled the JIP player joining the mission, calling for support, then disconnecting. 

     

    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. 


  17. 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). :wine:

    • Like 2

  18. 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. 


  19.  

    Quote

    So changed "foreach _allPlayers" to "foreach allPlayers"

     

    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"));

     

    Quote

    Thomas Edison would say that finding more and more things that don't work is a form of progress, so I hope all this is helpful to you in some way.

     

    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). 

     


  20. One way, I do not like, would be grabbing allPlayers into variable at first, then waitUntil in allPlayers appear a unit, that isn't in that variable and then run foreach loop. That could work assuming, always and for sure at first new player is not inside allPlayers when this EH kicks in. And as for MP many things aren't certain nor guaranteed...

     

    Second way would be not using EH at all, just some permanent loop with a 1 sec sleep or so, that would cyclically compare previous allPlayers with new. This way:

     

    Spoiler
    
    	if (RYD_HAS_addJIPs) then
    		{
    		/*RYD_HAS_JIPEH = addMissionEventHandler ["PlayerConnected",
    			{
    			params ["_id", "_uid", "_name", "_jip", "_owner", "_idstr"];
    			
    			
    			
    			if (_jip) then
    				{
    					{
    					if (((owner _x) isEqualTo _owner) and {not ((_x getVariable ["RYD_HAS_Access",false]))}) exitWith
    						{
    						[_x] call RYD_HAS_NewUnits;
    						}
    					}
    				foreach (allPlayers - (entities "HeadlessClient_F"))
    				};
    			}];*/
    			
    		RYD_HAS_JIPLoop = [] spawn
    			{
    			sleep 5;//just in case
    			
    			while {true} do
    				{
    				_allPlayers = (allPlayers - (entities "HeadlessClient_F"));
    				sleep 1;
    				
    				if not ((allPlayers - (entities "HeadlessClient_F")) isEqualTo _allPlayers) then
    					{
    						{
    						if not (_x getVariable ["RYD_HAS_Access",false]) then
    							{
    							[_x] call RYD_HAS_NewUnits;
    							}
    						}
    					foreach _allPlayers					
    					}
    				}
    			}
    		};

     

     

    Here is new version:

     

    HAS 1.9 wip2


  21. Quote

    Tested this for you

     

    Thanks. 

     

    Since in this case I can't test my own code, it is tough one to implement. Especially, so far I never touched anything around JIP, so not sure, what to expect here. 

     

    Quote

    Replaced _unit with _x

     

    Good. It's within foreach loop anyway, definitelly should be _x there. 

     

    Quote

    But even with that change it still didn't work. Having dropped lots of diag_log lines into the code to see what is going on it seemed that the problem is with the content of the AllPlayers array. The EventHandler seems to be firing before the JIP player has been added into the array. 

     

    That explanation makes sense. It seems weird to me, that EH doesn't provide actual unit object, player is JIPing into, that would make everything much simplier. But it is "PlayerConnected" event that probably not necessarily imply "incarnation" into certain unit object and indeed may happen before such incarnation. I'll think, how to solve that. Thanks again for helpful input. 

     

     

×