Jump to content
Bohemia Interactive Forums

Rydygier

Member
 View Profile  See their activity

  • Content Count

    4805

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Rydygier

  1. Posted

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

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

    • Like 1

  5. Posted

    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. 

    • Sad 1

  10. Posted

    14 hours ago, pierremgi said:

    Probably due to rendering during frame...

     

    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
	};

     

     

     

    • Like 1

  11. Posted

    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:

     

     

    • Like 2

  12. Posted

    Thanks fot he suggestions, glad you like it!

     

    2 hours ago, Dragon Layer said:

    do they re-arm automatically

     

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

    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. 

     

    • Like 1

  14. Posted

    1 hour ago, Gunter Severloh said:

    how the factions script works in terms of how the factions being listed in the menu show up based on the side you choose?

     

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

    • Thanks 2

  15. Posted

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

    • Like 2

  16. Posted

    No repository, but there's a version in open script form:

     

    also, if you prefer, feel free to dePbo the mod, unless @Gunter Severloh has something against?

     

    Code is rather complex, so be careful with changes. To enable picking sea destinations, go to HAS_fnc.sqf, find 

     

    RYD_HAS_MapPoint and RYD_HAS_MapPoint2 functions and remove/disable this exit code from the first:

      

    	if ((surfaceIsWater _pos) or {not([_pos] call RYD_HAS_isOnMap)}) exitWith 
		{
		//hint 'Destination must be on land.'
		'Destination must be on land.' remoteExec ['hint']; 
		};

     

    and similar from the latter:

      

    	if ((surfaceIsWater _pos) or {not([_pos] call RYD_HAS_isOnMap)}) exitWith 
		{
		//hint 'Destination must be on land.'
		'Destination must be on land.' remoteExec ['hint'];
		RYD_HAS_clickedPos2 = [-1000,-1000];
		publicVariableServer "RYD_HAS_clickedPos2";
		};

     

    Implementing desired way of disembarking over the water will require more work of course. 

     

    A good spot for choosing disembarking way may be here, note also waitUntil lines below these:

      

    		if (RYD_HAS_FastRoping) then
			{
			[RYD_HAS_Chopper,RYD_HAS_STT] spawn RYD_HAS_FastRope;
			}
		else
			{
			if ((RYD_HAS_AutoInOut) or {RYD_HAS_AlternativeLanding}) then
				{
				[] call RYD_HAS_AutoDisembark
				};
			};

     

    RYD_HAS_AutoGuide and RYD_HAS_AutoGuideB functions are responsible for "forced" making the helo to reach and maintain certain position and altitude at disembark, respectively for fast roping and touchdown.

     

    Note, RYD_HAS_FastRope function responsible for... fast roping/rapelling passengers, possibly could serve as a base for new disembarking way, as it already includes pushing passengers outside. Just remove all the part about ropes creation/removal and sliding units down the ropes and you have "hop into the water" disembarking. Namely note these lines:

      

    				[_unit,_heli] remoteExecCall ["disableCollisionWith", 0,_unit];
				[_unit] remoteExec ["unassignVehicle",_unit];
				[_unit,["GetOut",_heli]] remoteExec ["action",_unit];				 
				waitUntil
					{
					sleep 0.1;
					(isNull (assignedVehicle _unit))
					};
					
				[_unit] orderGetIn false;
				
				waitUntil
					{
					sleep 0.1;
					(_unit == (vehicle _unit))
					};

    There may be some redundancies, as I was fighting in various ways with MP issues that tend to happen sometimes... Or just write own disembarking function. Good luck. 🙂

     

  18. Posted

    29 minutes ago, Janez said:

    It's just unfinished.

     

    Exactly. Makes me wonder (again) why devs (well, whoever actually decideds that matters) even bind themselves by public declaration of planned release date. All the drama would be poof-gone otherwise. From the other hand, people should know by now, that, pathologically, in this market "1.00" means usually "expensive early access to public betatests". Terrible habit but normal thing nevertheless. 

     

    Apart from that, I see no practical reason to make any special fuss, best just keep waiting for the real premiere or, even better (unless you wish to support devs), few years more for a ready product, which means all the patches, DLCs and lower price. Development of the game continues till then de facto. 

    • Like 1

  20. Posted

    Quote

    Yeah i place say a Kajman down group it to an officer it turns to bluefor, un-group, remove pilots delete them and put in Blufor pilots,then sync to module,

     

    Well, that's, what I meant here:

     

    5 hours ago, Rydygier said:

    if he tries to swap native heli's side with some scripted workaround, then obviously he must repeat same trick for each respawned heli, as vehicle of given class always will spawn with his native side.

     

    With the correction, that he needs to repeat same procedure with the crew of respawned heli. Crew, same as the heli, will always respawn on their default/native side, will not mimic his described side-swap workaround. 

  21. Posted

    24 minutes ago, Gunter Severloh said:

    So basically his helicopter he initially has placed and synced to the module doesn't respawn, what respawns in place of it is a vanilla heli like the

    respawn falls to a default heli instead of the one he placed on the map.

     

    OK, that sounds like something specific in his setup, which would mean a repro request probably, because there's no any default heli class in the HAS code, that could be referred to at respawn, I mean, in the whole code any such specific heli class doesn't appear at all IIRC and the spawning code itself doesn't use any defaults. 

  22. Posted

    4 minutes ago, Gunter Severloh said:

    exploding heli

     

    Lately I was mentioning this as a known issue of unknown source (despite tests, I performed). I even suspect some kind of game bug. Wasn't that happening in some scenario, you mentioned too? I'm still focused elesewhere, so I will not check that that soon. 

     

    6 minutes ago, Gunter Severloh said:

    As for the other point he's stating that he has a heli of his choice setup for respawn but when it actually respawns, a Nato heli respawns instead of his heli of choice

     did we set that up at all before for respawn, or is this something new you'd have to code in?

     

    The code grabs heli's type synced with module, as it was at the mission start and uses that type each respawn. Not sure, what exactly he mean by "change it to Nato", but if he tries to swap native heli's side with some scripted workaround, then obviously he must repeat same trick for each respawned heli, as vehicle of given class always will spawn with his native side. 

  25. Posted

    Well, I was interested in this topic only when I was writing Hetman AL, so I do not know anything else. Inside HAL there are lines for fully autonomous AI-by-AI heli transport from A to B, including all the "thinking" responsible for all the choices - who to transport, by which vehicle, why, and where and in what manner, but it's highly integrated with the whole decision-making thing and therefore divided across few interacting mutually files, thus hard to extract, easier may be even to write such script from the scratch... Or indeed reassemble HAS for particular, interesting parts. 

×