Jump to content
Bohemia Interactive Forums

Bon

Member
 View Profile  See their activity

  • Content Count

    556

  • Joined

  • Last visited

  • Medals

Posts posted by Bon

  1. Posted · Edited by Bon

    Hi Nemorz,

    I don't really understand what your .sqs does, actions are added to the player and 3 seconds later they will be removed, there is a loop layer but no jumps and branches.

    However to your major problem: Look at the very first line of the Spawn_*.sqf scripts. A player joining your session (which you host as you said) might be able to execute the scripts, which then exit at the beginning instead of spawn a vehicle.

    There is also one thing you should consider: the activation code of a trigger is always executed by every player, not only by the player who fires the trigger. So my suspicion is, when you run into this trigger area every other player, independend where they are, will get this aircraft spawn menu too.

    Another thing:

    if (!isServer) exitWith {};
Warthog = createVehicle ["A10", getMarkerPos "Spawn_Aircraft", [], 0, "FORM"];
Warthog setDir 150;
exit

    should be enough to spawn an empty vehicle.

  2. Posted

    Hmm, a bit tricky I guess.

    My first idea is to let every unit run a script which checks if there is a missile close by, then computes the damage difference and factorizes this by 3 or 4.

    Could look like:

    _unit = _this select 0;

While{alive _unit} do {
  sleep 0.12;
  _missile = (getPos _unit nearObjects ["<missile-type>",10]) select 0;
  if(not isNull _missile) then{
    _dmge = getDammage _unit;
    WaitUntil{isNull _missile};
    _dmge = getDammage _unit - _dmge;
    _unit setDamage (getDammage _unit) + _dmge*3;
  };
};

    Now write 

    init = [this] execVM "scriptabove.sqf"

    into the init line of every unit.

    Of course this have to be checked for every type of missile, but that is the only way for me without changing any hardcoded stuff. IF this is really working of course :cool:

    But could be an approach.

  3. Posted · Edited by Bon

    Unfortunately, or, I would say, luckily, you have to script a bit for that purpose. Luckily, because only with scripting mission writing becomes the REAL fun ;)

    But don't panic, I'll try to guide you through the basic idea so that you should be able to continue on your own.

    1. Create a file "weapons.sqf" in your missions folder.

    Write in it:

    switch (typeOf player){
  case "USMC_Soldier" : {_primweapon = "XM8"};
  case "othertype" : {_primweapon = "other XM8 variant"};
  case ...
};

removeAllWeapons player;
player addWeapon _primweapon;
player selectWeapon _primweapon;
player addMagazine "<whatever XM8 needs, i think the G36 mags>";
player addMagazine ....; // other/more magazines
player addWeapon ....; // pistol? launcher?
...

    With the switch-case control you set which player class gets which XM8 variant.

    2. Now, create another file "playerInit.sqf", and write in it:

    [] execVM "weapons.sqf";
While{true} do{
  WaitUntil{not alive player};
  WaitUntil{alive player};
  [] execVM "weapons.sqf";
};

    3. Last but not least create the "Init.sqf" file and write in it:

    WaitUntil{not isNull player};
[] execVM "playerInit.sqf";

    Ok, this is the basic idea:

    The Init.sqf is being executed every time the mission starts, i.e. the player joins the mission.

    The Init.sqf now executes the "playerInit.sqf". Of course you can avoid creating an Init.sqf file by writing

    init = [] execVM "playerInit.sqf";

    into the init line of the player unit. I prefer this variant for no special reason. Anyway make yourself familiar with the Init.sqf, it is an essential tool in writing missions.

    However, the Init.sqf executes the playerInit.sqf, which checks permanently if the player died, waits until the player respawns then gives back the player your customized weapon configuration.

    Thats the way I always do it, perhaps someone has a more convenient method. Of course the names of the files you can choose on your own, except the Init.sqf.

  7. Posted

    I cannot find any errors in your description.ext. You also said it is working in MP when hosting locally, but not when running a dedicated server.

    So we should probably stop examin your description.ext and take a look at your server files.

    Redownload the server files just to eliminate the possibility these are broken. Then send us your server configuration. (However, I don't know a relation between the server configuration and the mission content, but as I said, the reason is certainly not the extension file).

  8. Posted · Edited by Bon

    Hi,

    first of all, SWITCHING to another unit won't give this unit the action. Reason is simple: When the init.sqf is executed, it gives the PLAYER the action. Only the player. Then switching to another unit this does not have the action since it was never applied to it. And switching to another unit will not rerun the Init.sqf.

    The action stays with the initial unit, so getting close enough to it the action will pop up in your action menu. This, however, is only the case on your machine, not on anyone else's. Another client getting close to the unit will not have the action popping up, since the other clients init.sqf refers to another player.

    Next thing:

    Variables being defined or changed within a script normally have to be broadcasted. You can do this by 

    publicVariable "armordone";

    Defining or changing variables within triggers, scripts which are executed by triggers or initialization code of objects placed in the editor will normally effect every machine.

    A small example:

    - Adding your player unit the action "Request Armor Division" in your init.sqf, and you use this action ingame, then the script "armor.sqf" is only executed on your machine, and you have to broadcast your variables.

    - Having a radio trigger which provides you to request armor support and klicking on it ingame, the "armor.sqf" would be executed on every participating machine (what'd cause some problems in t his case ;-) ).

    Hope that helps a bit.

  10. Posted

    1.

    Trigger activation: NONE

    Trigger condition: 

    not alive Ammo1 && not alive Ammo2 && not alive Ammo3 && not alive Fuel1 && not alive Fuel2 && not alive Fuel3

    Code executed when trigger is activated: 

    Objective1=true; hint "Objective 1 accomplished."

    2.

    Trigger activation: NONE

    Trigger condition: 

    not alive Officer1

    Code executed when trigger is activated: 

    Objective2=true; hint "Objective 2 accomplished."

    3.

    I assume you want the mission to be finished when Obj1 and Obj2 are done and the player reached the area.

    Then the trigger (which will describe the area) has to be activated on BLUFOR (or OPFOR when the players side is EAST), PRESENT

    TYPE: End #1

    condition:

    this && Objective1 && Objective2

    Perhaps this should be a multiplayer mission, then the last trigger must only be activated when the whole team reaches the area. In this case my only idea is to give every unit a name, e.g. Unit1, Unit2, ..., and the condition of trigger 3 must look like

    Objective1 && Objective2 && (Unit1 in thislist || not alive Unit1) && (Unit2 in thislist || not alive Unit2) && ...

    Should give you the basic idea.

  11. Posted

    changelog

    - fixed: "spawn-in-box" issue of respawn point when base is lost

    - fixed: using the laser marker in base will not give the "base-under-attack" warning anymore

    - set default viewdistance to 5000m; viewdistance now as a mission parameter

    - player can set individual viewdistance in base (near ammocrate)

    - decreased fog

    - enemy AI moves in wider circles around main target now

    - decreased base attack preparation time from 20 to 10 minutes

  14. Posted

    Hi,

    please make sure you are playing the current version and that ArmA2 is patched to version 1.03. The current missions version is v1.1.03, where the .03 indicates which version of ArmA2 you have to run.

    A few minutes ago I tried it out myself TEN times (no kiddin), and Waldo did not die in the sea once.

    The thing is that Waldo is set into a house on the map by using the houses IDs. With every ArmA patch (so far) these IDs changes. And when the IDs are wrong Waldo will spawn into the ocean.

    Sometimes the game engine let Waldo die even when placed him correctly, perhaps because he was set into a wall. I guess that happens 1 out of 30 times. Then simply restart the mission, should not be a big deal :cool:.

    Once again, make sure you are running ArmA2 v1.03 both client and server, then download the mission (must be v1.1.03) again from the download page. Tell me if it is still not working with you. Otherwise enjoy.

    Cheers, Bon.

  15. Posted

    Hi Desiderus,

    thanks for your feedback.

    Checked this airfield problem out and can confirm it. Playing on a dedicated server it is not working anymore (well, I'm pretty sure it did previously).

    The trigger which gives u the taskhint that Strelka is cleared is also responsible for the server to spawn the enemies on the airfield, so my suspicion is, that this trigger is not triggered on server side. If this suspicion is correct I am scared. Really. :eek:

    However just in case this is the cause I added a simple workaround. If you like to play it again in the next time download it again and tell me if this issue is fixed.

    Thx again and have fun.

  20. Posted · Edited by Bon

    Hi,

    even if you solved your problem by using another respawn script, let me explain what I think is the reason for the misfunction of your own script.

    I think the setIdentity command is not the correct one for this intention. It should work with the command

    _ap setVehicleInit "tanka=this";
processInitCommands;

    EDIT: For this special purpose it should also work just by using the "setVehicleVarname" command. But you might meet a situation when scripting a multiplayer mission where you want the spawned vehicle to give functionalities available for everyone playing, not only being available on server side. Then you have to use the code above. Anyway, "setVehicleInit" is always your friend.

  21. Posted · Edited by Bon

    I've noticed that there still seems to be the bug on losing your weapons when you're swimming for extended for long periods of time.

    Is this an ArmA2 bug or mission bug?

    It really ends up killing the fun when I have to bail from a chopper after being shot down, only to swim to the island with no gear :/

    This is an ArmA2 issue, was already there in Armed Assault. But I don't know this to suggest as a bug but as a feature. It must be intended from developers to loose weapons when in water I think.

  22. Posted

    is there a guide to this mission :confused:

    How do you use the RHIBs and and move the Spawn Box? I ferrying people to and from the island in the chopper Cant seem to get into the RHIBS.

    Not 100% on how to move the spawn box is it an option for one of the team to create ?

    I think all you have to know is written in the ingame notes, just to answer these two particular questions:

    - Clear Strelka/Airfiled, then the pilot can use the UH1 to load the box on the carrier and drop it. Near the box the engineer can build your spawn.

    - The RHIBS are not usable. They are only there for having sea environment sounds at the carrier :cool:

    Perhaps some day the landing bay down the carrier can be used, then the boats are perfectly placed for usage.

  23. Posted

    Here the first official version of this mission, hope you'll enjoy it.

    Cheers, Bon.

    changelog v1.1

    - every player class can now take RPG launchers from enemy corpses

    - FOP weapon box fix for JIP players

    - added cover stuff to construction (still space for more construction objects, reserved for future)

    - increased enemy presence

    - "Destroy Radar" sidemission task update fix

    - decreased target number from 8 to 6

    - changed mission goals from clearing city to destroying HQ located in city

    - fixed small vehicle service issue

    Download page

  24. Posted · Edited by Bon

    changelog v1.4 (final, no more updates for this mission)

    - fixed a small vehicle service issue

    - now all special weapons in ammocrate at respawn point for JIP players

    - fixed task updating for JIP players

    - increased enemy reinforcements

    - removed commander, squad leaders can request artillery instead.

    - refactored code for a very small performance improvement

    - once again, removed annoying AI <-- forgot to mention that, thx kdjac :D

    Download page

  25. Posted

    Hi SnR,

    the presence of the enemy increases from target to target, so at the last there's a lot more than at the first target.

    Anyway at the beginning I actually had more enemies at all, but then thought I overdraw the whole thing and cut some.

    So putting in more enemies just means to uncomment some lines in a script. If you guys were a bit bored because there were too few enemies, the final v1.0 (what will be v1.01) will just have some more.

    Thx for your suggestions, only by those I can improve the whole gameplay.

    20 of us gave this a good go and found that the amount of Opfor % was a miss match. No much action within in the towns, did find the odd contact out and about, would love to see them have an increase in presence.
×