Jump to content

Rydygier

Member
  • Content Count

    4705
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1210 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

5502 profile views
  1. Rydygier

    Auto Restart AI Only Mission

    Welcome to the BI Forums! I never tried such thing, I know, there are: https://community.bistudio.com/wiki/playMission https://community.bistudio.com/wiki/playScriptedMission but no idea, if/how they work exactly. There's also: https://community.bistudio.com/wiki/runInitScript but this does not exactly that. Question is, do you really need to actually restart the mission. Maybe just try resetting everything to initial conditions within same mission (in such case best, if everything is placed/initialized via SQF script). If this is about repetitive simulating something, such solution should suffice (and you don't need any multiplayer set up for it, just plain, local singleplayer). But depends, what exactly you're trying to do.
  2. Rydygier

    [SP] Warping Plague

    Great to see such a news! RPT logs may contain some hint about the cause of the problem. Landlocked terrain may be somewhat harder to explain, how quarantine works etc. assuming, you care about that... If I may advice, if you don't - I recommend to base the port on wip6 linked above. Good luck. 🙂
  3. The good news is, I like the idea of "init code field" and it is most likely doable and easy enough to implement. The worse news is not really a news, because I said that already. I'm occupied with other stuff currently and I've no idea, when I'll be back to the HAS topic.
  4. Things, that could be answered: does it happen in SP, MP or both. Player local/non local. Each try or erratic. Only certain helo class or all helos CDLC/vanilla alike. That kind of stuff.
  5. It has been long time but I recall, I encountered this issue in the past (it was on pure vanilla). IIRC, I never managed to nail down exact conditions that trigger this most peculiar behavior despite quite substantial effort I put into figuring this out. Mentioned demo works fine usually. Also no idea, when I'll be back here, most likely not anytime soon, so this probably will remain an unresolved mystery, unless in the meantime someone manage to define exact factors, that cause this.
  6. Found time for a tiny update, 0.71: - spellbook GUI should not appear if: 1. the player is not a battle mage; 2. in the map view; 3. other custom user dialog is active. Did only few tests, but seems, it prevents spellbook appearance also when inventory GUI is displayed.
  7. Not sure about multiplayer. I'm SP guy mostly. However, if you spawn the smoke and delete it from the same machine, say a server, it should work same, as in SP, at least I guess so. Otherwise smoke_1 variable may need publicVariable. Others may be more knowledgeable/helpful than me regarding particles in MP.
  8. OK then, here's an example, how I do it. Compare with your way for differences. If still no luck, I can look at vanilla repro mission, if you provide one...
  9. Depending, how/where you do it, it may not work, since _smoke is _local _var. Try instead run the code with global var, if you wish to delete it from other places, for example: smoke_1 = [markerPos "m1",1.5,180] call RYD_SmokePillar; then to delete: deleteVehicle smoke_1;
  10. Yes, that effect looks quite dense, like lots of paticles, so a single pillar may exhaust big part of particles limit. Had few moments and since I find this rather fun, made another variant, run with same parameters, as first one: _smoke = [markerPos "m1",1.5,180] call RYD_SmokePillar; should be still pretty "cheap" as for particles limit used, ( (180/0.6)*0.75 = ~225) while looking a bit thicker: RYD_SmokePillar = { params ["_pos","_size","_life"]; private _smoke = "#particlesource" createVehicle _pos; _smoke setParticleRandom [0.25 * _life, [2.5 * _size, 2.5 * _size, 0.1], [1, 1, 0.2], 0.5, 0.35 * _size, [0.05, 0.05, 0.05, 0.2],0.5,0.2 * _size,45]; private _col = [[0,0,0,0.5],[0,0,0,0.75],[0,0,0,0.7],[0,0,0,0.65],[0,0,0,0.5],[0,0,0,0.35],[0,0,0,0.2],[0,0,0,0.05],[0,0,0,0.01],[0,0,0,0]]; private _effect = ["\a3\Data_f\ParticleEffects\Universal\Universal", 16, 7, 48,1];//["\A3\data_f\ParticleEffects\Universal\Universal_02", 8, 0, 40,1];// _smoke setParticleParams [_effect,"", "Billboard", 1, 0.75 * _life, [0, 0, 0],[0,0,0], 1, 1.5, 1.275, 0.45, [8 * _size,16 * _size],_col,[0.5,0.1,0.05],1,0.3,"","",_smoke,0]; _smoke setDropInterval 0.6; _smoke };
  11. Using particle array one may spend hours shaping "the perfect smoke", tweaking and tweaking... Addicitve. Anyway, to get tall pillars one need to prolong particle's average life, so it may climb higher, before die, or to make it raise faster, but this may be not realistic. The longer each particle live, the longer it reduces available particles limit on screen. So especially with such tall smoke columns one need to be careful, or a single source of his smoke will eat whole particles limit. Maybe this will suffice: in the init.sqf etc.: RYD_SmokePillar = { params ["_pos","_size","_life"]; private _smoke = "#particlesource" createVehicle _pos; _smoke setParticleRandom [0.9 * _life, [2.5 * _size, 2.5 * _size, 0.1], [0.4, 0.4, 0.5], 0.5, 0.5 * _size, [0.05, 0.05, 0.05, 0.2],1,0.1 * _size,360]; private _col = [[0,0,0,0.5],[0,0,0,0]]; _smoke setParticleParams [["\a3\Data_f\ParticleEffects\Universal\Universal", 16, 7, 48,1],"", "Billboard", 1, 0.1 * _life, [0, 0, 0],[0,0,0], 1, 1.5, 1.275, 0.45, [5 * _size,25 * _size],_col,[0.5,0.15,0.1],1,0,"","",_smoke,0]; _smoke setDropInterval 0.2; _smoke }; Of course, it may be tweaked further to achieve better look. Executing for example: _smoke = [markerPos "m1",1.5,180] call RYD_SmokePillar; params: [smoke position,size coefficient,maximal particle lifetime in seconds] _smoke is the source object. Use deleteVehicle _smoke; to end the effect. If I'm not mistaken, with exemplary parameters used, the cost of this effect will be decent. Looks like this:
  12. Rydygier

    [SP] Warping Plague

    Thanks fot he suggestions, glad you like it! Yes, by the script. As long, you have the ammo resource, each shot guard's ammo is replenished, but it costs 1 ammo. If you have no ammo, they will run out of bullets, if they spend all their magazines. The code: _id = _civ addEventHandler ["Fired",{if (RYD_TS_Ammo > 0) then {(_this select 0) setAmmo [(_this select 1), 100];RYD_TS_Ammo = (RYD_TS_Ammo - 1) max 0;};}];
  13. Hi. Not sure about the cause of your issue, but since this thread, that piece of code was improved and integrated into this: You may either use HAS as a whole in your mission, either rip off the CAS code itself, which resides in the HAS_fnc.sqf, RYD_HAS_CAS function along with functions called from it. But it is a large and rather complex chunk of code... Currently I cannot assist with this sadly, being busy long term elsewhere.
  14. Rydygier

    Desert OPS Run - Tactical Arena v1.20

    The code runs through every single faction listed in the game's config ("CfgFactionClasses") and picks from them those, that "side" value indicates, the faction is of a side opposing to the player's side. In the said config are listed all vanilla factions along with all factions from loaded mods. Same code gather groups of such opposing faxctions found in the "CfgGroups". The function doing this is rather short in fact: RYD_DA_CollectOpposingFactions = { RYD_DA_HostileFactions = []; _facClass = configFile >> "CfgFactionClasses"; _opforSides = switch (RYD_DA_PlayerSide) do { case (2) : {[0,1]}; case (0) : {[1,2]}; default {[0,2]} }; for "_i" from 0 to ((count _facClass) - 1) do { _class = _facClass select _i; if (isClass _class) then { _faction = toLower (configName _class); _side = getNumber (_facClass >> _faction >> "side"); if (_side in _opforSides) then { _gps = [_faction,[8,12],RYD_DA_PlayerSide] call RYD_DA_GroupsFind; if ((count _gps) < 1) exitWith {}; _displayName = getText (_facClass >> _faction >> "displayName"); RYD_DA_HostileFactions pushBack [_faction,_displayName,_gps]; }; } }; publicVariable "RYD_DA_HostileFactions"; }; Used here RYD_DA_GroupsFind is more complex, but its logic is similar. As for the players though, it works differently. There's one, predefined class of player unit per side (player picks only his side). Giving to the player more choices would require serious script reworking and of course redoing the GUI. Highly unlikely anytime soon...
  15. RYD_HAS_LZ picks the final spot for disembark. If you want to alter embarking phase, you probably should focus on lines 920-970: _pickPos = [_signalClasses,_pickPos,true,200] call RYD_HAS_Signal; if not (_alive) exitWith {}; if (_unable) exitWith {}; if (RYD_HAS_CallCancelled) exitWith {}; RYD_HAS_done = false; _pickPosR = _pickPos; _wpRad = if not (RYD_HAS_AlternativeLanding) then { _pickPosR = RYD_HAS_Chopper getPos [(RYD_HAS_Chopper distance2D _pickPos) + 80, RYD_HAS_Chopper getDir _pickPos]; 50 } else { 0 }; _wp0 = group RYD_HAS_Chopper addWaypoint [_pickPosR, _wpRad]; _wp0 setWaypointType "MOVE"; _lvl = 4; if not (RYD_HAS_AlternativeLanding) then { _wp0 setWaypointStatements ["true", "RYD_HAS_Chopper land 'GET IN';RYD_HAS_done = true;"] } else { _lvl = 1; _wp0 setWaypointStatements ["true", "RYD_HAS_done = true;"] }; group RYD_HAS_Chopper setCurrentWaypoint _wp0; waitUntil { sleep 0.1; _alive = (alive RYD_HAS_Chopper) and {(canMove RYD_HAS_Chopper)}; if not (_alive) exitWith {true}; if not ([] call RYD_HAS_ifChopperReady) exitWith {_unable = true;true}; if (RYD_HAS_CallCancelled) exitWith {true}; if not (RYD_HAS_CruisingSpeed < 10) then { [RYD_HAS_Chopper] call RYD_HAS_TurningSpeed }; (((((getPos RYD_HAS_Chopper) select 2) < _lvl) or {(RYD_HAS_AlternativeLanding)}) and {(RYD_HAS_done)}) }; Two probably key differences, making heli to crash here, and not to crash at disembarking seems to be: 1. RYD_HAS_Chopper land 'GET IN' in the contrast to: RYD_HAS_Chopper land 'GET OUT' for disembark - you may try this one for embarking too 2. After the visible above waitUntil, that awaits till the heli is ready for embarking (low enough, landed), you may need to add second waitUntil with autoguide fucntion (that brings and keeps the heli at chosen spot and altitude), as it is for disembarking at destination phase. Also above waitUntil's condition may need to be changed, as currently it awaits for actual touchdown marked by RYD_HAS_done and altitude check. Or fiddle with alternative landing mode, which may be simplier way to achieve same thing (autoguide already applied, just its parameters need to be calibrated).
×