Jump to content

Rydygier

Member
  • Content Count

    4404
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

821 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

2905 profile views
  1. 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.
  2. 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...
  3. 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.
  4. 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).
  5. 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.
  6. 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).
  7. 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: Here is new version: HAS 1.9 wip2
  8. 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. Good. It's within foreach loop anyway, definitelly should be _x there. 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.
  9. Rydygier

    HETMAN - Artificial Leader

    Complete arty handler logic is spread across several functions. Essential bulk you can find in the HAC_fnc.sqf: RYD_ArtyPrep//initial arty preparation - ammo, Fired EH... RYD_CFF//main handler run from HAC_fnc2.sqf inside RYD_StatusQuo function, allocating fire missions - here arty firing begins. RYD_ArtyMission//checking, if arty mission at chosen target may be handled by some arty piece, also direct executing illum and smoke types of missions RYD_CFF_TGT//picking the suitable target (only if found any, RYD_CFF will seek for battery to conduct the fire mission against it) RYD_CFF_FFE//targeting, calling RYD_CFF_Fire - main fire execution code run once the target and arty fire "provider" are determined RYD_CFF_Fire//actual arty firing procedure
  10. HAS 1.9 wip1 - also units added via RYD_HAS_newUnit later in game should get back HAS calls after respawn (not tested); - added new user variable (cannot be changed on-the-fly - attempt will be futile) - RYD_HAS_addJIPs = true;//if true, JIP-ing players will automatically get access to HAS calls without necessity of manual calling RYD_HAS_newUnit function for them. (not tested, can't test on my own anyway - testing requires two players); - provided global and "per unit" switches for selective enabling/disabling access to each type of support. Global: RYD_HAS_Switch_Taxi = true;//global switch for troops transportation support availability RYD_HAS_Switch_Supply = true;//global switch for supply drops support availability RYD_HAS_Switch_CAS = true;//global switch for close air support availability Exemplary usage - disabling access to supply calls for all players: RYD_HAS_Switch_Supply = false; publicVariable "RYD_HAS_Switch_Supply "; Per unit: unitName setVariable ["RYD_HAS_canCall_Taxi",false,true];//disabling troops transportation support availability for 'unitName' unit unitName setVariable ["RYD_HAS_canCall_Taxi",true,true];//enabling troops transportation support availability for 'unitName' unit similar for the rest: unitName setVariable ["RYD_HAS_canCall_Supply",false,true]; unitName setVariable ["RYD_HAS_canCall_CAS",false,true]; These are enabled by default. Note to both: as observed during tests, if at that moment some player has currently opened 0-8 supports menu, currently displayed for him support options will be not adjusted accordingly. Only after closing 0-8 GUI. Even when global switch is on, if unit's switch is off, that unit will have no access to that type of calls. Also if unit's switch is on, but global switch is off - there's still no access even for that unit. In other words both, global and unit's switches need to be "true" in order to provide respective support access to that unit. This one was tested, but only SP. I'll be grateful for further testing, especially in MP and for first and second features.
  11. Rydygier

    HETMAN - Artificial Leader

    Hello. For sure use all lower case for artillery vehs classes ("pook_2s19_opfor" and "pook_9k58_opfor"). Also few things: 1. You can also try to rely on autofiller and do not define manually that config (RydHQ_RHQAutoFill = true;, it is enabled by default). 2. With modded arty you can't be sure, if it will work, depends on how well the mod is done. 3. Even if all is set OK, arty may not always fire when you think, it should. Script has own ideas about that.
  12. Rydygier

    [SP] Warping Plague (wip)

    Hi, thanks. Since logic structure of these anomalies is based on parallel threads without any handles left and utilizes some additional spawned helper objects, particle sources etc., in order to get control over once placed anomaly, I would need redo its code to add and collect all threads' handles and spawned object into global arrays, from where these can be terminated/deleted/moved. Possible, and even less work than enabling suspending, but for now decided, I'll just scatter number of them at mission init in the northern part of Malden and leave them be.
  13. Rydygier

    [SP] Warping Plague (wip)

    Ah, good. Even better:
  14. Rydygier

    [SP] Warping Plague (wip)

    Yes, I think, each mission pbo change makes new game required? Nothing, I could plan or decide. I can wait a bit longer with the next update though, especially, I've to think now, ho to approach rest of todos. Anyway, if one want to play longer to test long-term balance, may postpone own file updating and continue with older version.
  15. Rydygier

    [SP] Warping Plague (wip)

    File updated: - 11 new anomalies by @aliascartoons, part of them actually acting like another, rare types of (semi)intelligent warper creatures/life forms, not anomalies in this scenario meaning. Two of static anomalies possible to scan, but since these do not move nor relocate, they do not leave any traces, thus here completing the scan will give immediate, one time per type, reward. There's 10 of them spawned prermanently in the northern part of the island, some may be of the same type as other, but each gameplay typically at least half of types should be present. Was thinking, if these should be dangerous also for other warper creatures. Decided, because of their nature, they will be. Should be also more dynamic this way. Be extra carefull, these new are typically even more deadly/nasty. BTW this made mission file much bigger, as expected. - added 0-0-0 quick save, as requested. By default 0-0 menu IIRC requires radio item assigned in the inventory; - added crafting the ATV, available at the Stash if previous own quad is destroyed (can be one at once, quads possibly found elsewhere doesn't count here)) - costs 250 Materials; - currently assigned vehicle (the last embarked, default ATV if none embarked) will be for player's convenience marked on the map. If no such vehicle - marker will disappear; - added kind of dynamic jukebox, chosen tracks will be played from time to time (semi-random, around 20 minutes interval, similar as in Pilgrimage), the kind and interval depend on the situation (calm, weird or combat (these two with shorter interval)). Tracks chosen amongst Arma 3 music. Sad surprise was to learn, there's no Contact DLC tracks visible/avilable (I do not own this DLC), same for sound effects. Seems even this is behind the paywall unfortunatelly. So we have, what we have, I'm not satisfied, but... - MBG Alien Ground Forces units should now use provided by this mod alien radio protocol language; - experimentally warper creatures will use this weapon: https://steamcommunity.com/sharedfiles/filedetails/?id=942209374 if mod is detected. - corrected pointed out grammar errors. As for future plans, currently under consideration (details unknown): - mental stability parameter (negatively affected by anomalies and creatures, positively affected by time/resting); - some quests bound with diary entries?; - adding more optional alien weaponry to warper cratures. Perhaps there's a hope, MBG Alien Ground Forces mod may get such addition in the future, but that's just my guess, there was requests in this regard, no idea about actual author's plans. Or perhaps someone is awared about Arma 3 mod intriducing such weaponry? The smaller mod, the better. - perhaps new kind of Weird Matter to be obtained with different properties?; - using Contact DLC stuff, but seems, apart from some props, there may be nothing useful on the free side of the paywall, not even sounds or music tracks, which is disappointing; - more language corrections when errors reported; - more activities/presence for The Fittest.
×