-
Content Count
556 -
Joined
-
Last visited
-
Medals
Posts posted by Bon
-
-
Every accessable vehicle has its own vehicle list, containing crew and cargo.
Now when you want a unit to leave a vehicle, you have not only to let them exit the vehicle but also remove them from the vehicle list, using the unassignVehicle command.
-
Don't know if this really helps, anyway, use setPosATL instead of setPos.
-
You just have to add the command to wait for the player to be alive again after he died so it will wait to give the player unit the weapons until the new entitiy is created, i.e. the player respawned. I think on sqs format this is done by
@(alive player),
on sqf format it is done by WaitUntil{alive player};
Thus this script is executed by a "killed" eventhandler you can be sure the unit is dead already when the script starts, all what's left is
to add the wait command to the appropriate line in your script:
; Get the unit parameter given _unit = _this select 0 @(alive _unit)
That's it.
But: it really is a good idea to learn sqf and not use sqs anymore. Do yourself a favour and write all your future scripts in sqf format.
-
Hi All,
altough a thread for this mission is already open here, I open a new one.
Firstly, because I have completely restructured the code of this mission, and secondly because the previous one was already overflowing.
Thus, officially, this is only the notice of the update to v1.5. Although I mentioned previously I am not going to write another update for this mission, I was forced to review my code after my current project is close to finish (a preview of it is available as a pdf manual on my download page atm).
So for all who do not know my Hunt Waldo mission on Utes, here is a small description (again):
Actually, it is just a fun mission for about 4 to 14 players, but in which the various responsibilities of the particular players make teamplay and communication among themselves to be of utmost importance.
The mission is simple: find the oppositions leader, codename 'Waldo', and bring him to your initial point. (Yeah, I know, find Waldo. Funny, isn't it?)
You start at the U.S.S. Khe Sanh with entering the island.
- First, clear the LZ south of the island so that we have easy access to Utes for the further operation and that we can deploy our artillery there.
- Head for Strelka and clear it of enemy units.
- There is also a radar station in Strelka which serves the enemy to call in reinforcements from time to time. It is not required to destroy it, but recommended.
- Next, conquer the airfield of Utes so that the way is clear to Kameny, where we expect Waldos remainder.
- On the way to Kameny there is once again a radar tower, same story as with the one in Strelka.
- (Clear Kameny), Search Kameny for Waldo, who should hide himself in one of the houses.
- Bring Waldo to the LHD, alive. Mission succeeds when Waldo is on the carrier, mission fails as soon as Waldo dies.
There are different soldier classes the player can slip in, each with different skills and weapon pool:
Squadleader: can call artillery fire missions once the LZ is clear and while the artillery units are alive
Anti-Tanks: have access to anti-tank launchers of course
Machinegunner: have access to heavy full-automatics of course
Medics: can heal of course
Sniper: have access to precision rifles of course
Engineer: can build a respawn point
Pilots: can fly the UH1Y and the Blackhawk helicopters
For one time, the pilot, mounting the UH1Y, can load a supply box and drop it wherever he wants. Standing close to this box then, the team's engineer can build a respawn point, which also comes up with a weapon box.
Unless the respawn point is built, the team respawns on the carrier, with the box on the carrier the only source to weapons and ammunition. Thus the pilot's most important role is to play taxi for the other teammembers.
The pilot can also use the Blackhawk helicopter to lift some technicals, a LAV25, a HMMWV-TOW and a HMMWV-M2.
The official changelog from v1.4.03 to v1.5:
- code restructured, clean server-client architecture now, much easier to read (not just for me)
- also cutted out the dependencies to some building ids - therefore more reliable to further ArmA patches
- respawn point can now be build without restrictions to any objectives being accomplished, but only once
- loadout can be saved at the weapon boxes
- spawn dialog renewal
- added settings dialog, you can now set viewdistance and grass layer whenever wherever you want (by pressing 'T')
- enemies now move in randomized but structured patrol routes around and through the main target areas
- amount of enemies dependend on number of players currently playing
- strength and number of enemies can be set as mission parameter now
Mission can be downloaded at the link in my signature or:
on ArmedAssault.info <- thanks to Old Bear
on Armaholic.com <- thanks to Big
So, just hf I'spose.
-
AFAIK putting a condition to the waypoint means that the waypoint is not done unless the condition is true.
I.e. the statements of this waypoint are only executed when counter is true;
For your purposes, you either:
- Add a first waypoint before your current one, and set the condition there. I assume the enemy then will move to this first waypoint, but waits for counter becoming true, then continuing their route.
- Or you just press F5 in the editor and synchronize the trigger with your waypoint.
-
Well for me its the Combo "R CTRL + M", but just look into your control settings, should be listed as "Toggle GPS Map" or something like this.
Having this GPS minimap enabled is also dependend on your current difficulty settings, so check them, too.
AND of course you need to have GPS in your inventar I believe.
-
Call a script out of the init line of one of the to extracting units, which could look like this:
if(not isServer) exitWith{}; _unit = _this; _helis = []; while{count _helis == 0} do{ _helis = nearestObjects[_unit,["MH60S","UH1Y","whatever choppers u use"],100]; sleep 3; }; { _x assignascargo (_helis select 0); [_x] orderGetIn true; } foreach units group _unit;Didn't try it out yet, just written out-of-the-fingers, but I think the idea is clear.
-
I suggest to put
({alive _x} count crew tank1) == 0into the condition.
-
Hey aulias,
feels so cool there are still some people playing this mission as I did not expect that.
So I did not really checked for issues after 1.04 released and I will catch it up in the next weeks.
My current project, which is kind of a regeneration of Hunt Waldo 2, is still in progress (think this is an opportunity to point to the preview available on my download page).
In this project the most of the things you mentioned above I implemented already, what causes me to give the Hunt Waldo mission on Utes a makeover when the time is right.
-As the mission progresses, sometimes the task list on the map gets duplicated so you end up with the same task entries repeated many times. Everything still works okay and it doesn't affect finishing the whole mission etc, but it gets messy on the map screen. Could be a game bug, not sure, its not a big issue really but might be an easy fix?
Will rewrite the whole tasks thing by implementing a simple but effective server-client architecture as I did in my current project, dropping the trigger-based task creation. Should kill all the issues of that kind.
-With the artillery, I had thought it simply doesn't work as I called it in again and again for nothing. But reading this thread, it seems that it takes 25 minutes to fire after you request it? Is that right? Maybe you could reduce the fire time a bit? It could have a one or two hour recharge though, so you can't just spam it all the time. Or at least mention this firing delay in the mission briefing?
If I understand right, you experience that you request the fire mission and 25 minutes later the shells go down.
Of course that's not intended and I wonder why I never noticed this bug. Will check and fix it.
You should be able to call firemissions 20 minutes after join and then all 25 minutes after every request. I think these delays are appropriate, since the artillery is very powerful.
Nevertheless, I will take care of putting hints where needed.
-It would be great if you could save your kit loadout, as most of us alter it from the default loadout.
-One observation - we've noticed that the enemy infantry are just standing there doing nothing at the first LZ and also at the airport until some firing starts, then they all spread out and counter attack. Whereas the armoured cars do tend to move around on the island on patrol routes. So maybe you could make some of the infantry groups move in patrol sweeps around the perimieter of the LZ/coastline and also airport perimeter? It would make it a bit more challenging and less predictable for more replayability.
No problem, since I've implemented that already for my newest mission.
Once again thx for your encouragement,
hf.
-
Good idea. Should become a sticky.
Here some questions coming up very often and are answered in less than 2 posts:
-
You have to write
this setPosASL [getPos this select 0, getPos this select 1, 15.9]
in every units init line that has to spawn on the carrier.
No problem unless you are going to enable respawn. Then you have to include a script that detects when a player died and respawned, then set his position again with the code above.
Also note that, placing the LHD with the LHD spawner by ArMaTeC, the last value depends on where you place the carrier. But on the Khe Shan on utes it is 15.9.
-
What you just said.
not alive boss1 && not alive boss2 && not alive boss3 && not alive boss4
-
No, told it to fly in height 900 or something, and it is also not the problem it doesn't have enough speed. It takes off after at most 75% of the runway.
It just takes off, turns to the left or right (independend of any waypoints I set) and ends up exploding in the trees.
Thought of setting the waypoint to careless and full speed might help, but it didn't.
My only idea is to detect when it touches off the ground and then add some speed to the z-value of its velocity.
But I am quite sure this would just result in unclean code ant that's not worth it.
Stupid AI. :681:
-
Yes, exactly.
-
I guess we all thought about something like this already.
But I think it is not possible, since I even don't know how an animal can cause damage to a unit.
-
-
Hi all,
does anyone of you ever succeeded with getting the drone airborne (without creating it already flying of course)?
For me I always experience the following issue:
- UAV spawns at airfield,
- UAV gets Waypoints,
- UAV moves to runway,
- UAV speeds up,
- UAV lifts off, turning 90° to the left or right,
- UAV crashes into the trees.
No matter where the waypoints are, always the same story.
Ok, its a funny thing, but...
...how could I fix / work around it? Any suggestions / ideas?
-
the disabledAI statement in de extention file only affects the AI that is set to playable in the editor.
But such specific exceptions you cannot define.
EDIT: Too late ^^
-
So you get the nearest Object of type "LocationLogicCityCenter" and store its position array in _locPos.
Then you try to get the nearest house to an array containing the x value of _locPos. Am I right?
-
@tobmic: I recommend putting this in a script file, perhaps as I did in a separate script called "checkWeapons.sqf" which then would be called by the init.sqf. But don't do it in the initline. Thats dirty, and it will be executed on every single machine for every single unit.
@Binesi: As long as there aren't too much of them, such Waituntil checks/frame are really no problem, even with older hardware. Anyway, I always try to keep the performance of my missions smooth, and always having this checkweapon thing and the checks wether the player is alive or dead in my missions, never had bad experiences with it.
But every WaitUntil statement you can replace with a
While{not condition}{sleep time};if you want.
Btw, it is a script running local checking only the own unit, so my own machine doesn't effect any performance of other machines by these checks.
@kylania: nice ^^
-
In my new mission only ATs can carry launchers and only snipers can carry sniper rifles.
I did this by running this very simple script:
scriptname = "checkweapon.sqf"; While{true} do { WaitUntil{player hasWeapon "JAVELIN" || player hasWeapon "M136" || player hasWeapon "SMAW" || player hasWeapon "Igla" || player hasWeapon "MetisLauncher" || player hasWeapon "Strela" || player hasWeapon "DMR" || player hasWeapon "KSVK" || player hasWeapon "M107" || player hasWeapon "M24" || player hasWeapon "M40A3" || player hasWeapon "SVD" || player hasWeapon "SVD_CAMO"}; if(typeOf player != "USMC_Soldier_LAT") then { player removeWeapon "JAVELIN"; player removeWeapon "Igla"; player removeWeapon "M136"; player removeWeapon "MetisLauchner"; player removeWeapon "RPG18"; player removeWeapon "RPGV7"; player removeWeapon "SMAW"; player removeWeapon "Strela"; }; if(typeOf player != "USMC_SoldierS_Sniper" && typeOf player != "USMC_Soldier") then { if(typeOf player != "USMC_SoldierM_Marksman") then {player removeWeapon "DMR"}; player removeWeapon "KSVK"; player removeWeapon "M107"; player removeWeapon "M24"; player removeWeapon "M40A3"; player removeWeapon "SVD"; player removeWeapon "SVD_CAMO"; }; }; if(true) exitWith{hint "DEBUG: You should never read this."};When anybody else but ATs try to pick up a launcher it will just disappear, same with snipers and sniper rifles.
-
As it is written in the ComRef of the synchronize thing, this ingame synchronization must be done due to the very first 0.5 seconds. After that all the synchronization is set in stone.
Had the same problem with the Coin module for my first hunt waldo mission until gave up and implemented a build menu by hand.
I don't know what's the sense of this synchronizeObjectsAdd command when synchronizing with modules can take place only in the first second of the game.
They changed that with the first aid module in 1.04, since the module is resynchronized with the player after respawn, and it seems Big_Daddy made a nice workaround for the UAV module (btw nice work). But for the Coin I think there is still some hax0ring requiered.
-
Think its because the syntax of "if" is
if(condition) then{ code }Look at the braces.
But for this I recommend to use the extendend syntax of addAction where you can also add a condition which must be true to be able to use the action.
player addAction ["Nemocnice", "mash2.sqs",[],1,false,true,"","typeOf player == 'USMC_Soldier_Pilot' && typeOf vehicle player == 'BMP3'"];
Don't forget to reassign this action to the player after respawn.
-
in the trigger:
{_x setCombatMode "RED"} foreach thislistEDIT: OMGWTFBBQ this forum is ranked now. 's crazy.
EDIT EDIT: Should now get rid of editing posts and create new ones instead.

vehicleInit not synchronized to JIP players
in ARMA 2 & OA : MISSIONS - Editing & Scripting
Posted
Hi,
since 1.04 the initline code of vehicles seem not to be synchronized with jip players anymore.
I have a helicopter initialized out of the editor with the helilift script. As the servermachine I always can lift vehicles with this chopper, as a client I cannot.
Creating a new helicopter and set the code with setVehicleInit, all machines can lift vehicles with this helicopter, server as well as clients.
But for all then connecting players it does not work, the helicopter must be recreated.
Quite sure it worked with ArmA2 v1.03.
Can anyone confirm that issue?