Magirot

You can find them in the BI Wiki (with images and has the latest version), =faction&options[sort_by]=name&options[faction]=&options[vehicleclass]=Men"]Six config browser (old version), or the editor's own config browser (the gear image at the top). The Nato jet is B_Plane_CAS_01_F for example. It's good that you asked about vehicles, because I didn't realise I used createVehicle to create an unit, which isn't what you should do. See the end of this post for correction. There are separate versions for for empty and crewed vehicles. If it's listed under a side in those above lists, it has crew in it to begin with. With more scripting, yes, but it's a relatively big hassle. Here it creates the unit with the correct command (createUnit which is for crewed vehicles as well; createVehicle is actually only for empty vehicles and objects). AppleGroup = createGroup blufor; Apple = "B_diver_TL_F" createUnit [getMarkerPos "hspawn", AppleGroup]; wp0 = AppleGroup addWaypoint [getMarkerPos "awp1", 0]; [AppleGroup, 0] setWaypointType "MOVE"; You can paste this to the trigger On Act. It creates a group (which is needed when spawning units, but you can also add it to an existing group), spawns B_diver_TL_F on marker "hspawn" and adds him to group AppleGroup, then adds a move waypoint to marker "awp1". As you can see, it gets quite crowded and hard to edit in the On Act. box at this point, which is why many people prefer to execute stuff like this through scripts instead. For giving other parameters to waypoints look at "See also" in this: addWaypoint Note that if there are no units for the given side placed in the editor, you need to add "center = createCenter side" before you can create groups for the side. So in this case "center = createCenter blufor". But adding an unit somewhere in the editor is easier.

This at least is directly related to the problem with addUniform not being global. Causes trouble when running into 1) possible desync at mission start, 2) join-in-progress players and 3) that respawn script from the eventhandler, which as far as I know is only run for the respawning player. I'm not familiar with respawn stuff, so I won't risk giving advice with glaring mistakes here. I assume there is some way to get it working properly, or maybe it already works, I don't know. At least you should add more safeguards to the loadout script to make sure a JIP player doesn't get to run it on an older player, because that'll result in the JIP client running removeUniform and addUniform, and as we've established, removeUniform is global, addUniform is local -> only removeUniform is run for everyone -> naked people. The way I've done this is like this: _unit = _this select 0; _unit call X39_MedSys_fnc_initializeUnit; // Probably needs to be called for everyone? _loadout_ready = _unit getVariable ["loadout_ready", FALSE]; if (!_loadout_ready) then { // all the regular loadout stuff here removeAllWeapons _unit; removeUniform _unit; // etc if (!isDedicated && (player != player)) then { waitUntil {player == player}; waitUntil {time > 10}; }; // loadout_ready broadcast to all clients and JIP players (last TRUE), // so the loadout isn't run for those who can get it directly from the server _unit setVariable ["loadout_ready", TRUE, TRUE]; }; However, I've used this mainly for missions which do not involve respawn, so I'm completely unaware of the problems that might arise there. I'm not sure if this is the best way to do it either, but it's worked so far. Wade into this thread for more info.

He's pointing out that it's a little weird to have it trigger when a side notices itself. "Activation" points the target and "Detected by OPFOR" means the trigger will activate when the target is detected by someone of this side. So it'll trigger when an opfor unit sees another opfor unit. More info on this if you're interested. Anyway, it doesn't affect the spawning. The reason why it's not working is that the "condition of presence" box is used for checking if the unit should be spawned when the mission starts. You could use it to, for example, have the unit spawn only if another unit that's been placed earlier in the editor isn't around (!isNull another_unit_name), but if it returns FALSE at the beginning, the unit is deleted and the condition is not checked again. To spawn a unit from a trigger you have to use createVehicle. In this case it'd be a line like this in the trigger's On Act. box: Apple = "B_diver_TL_F" createVehicle (getMarkerPos "hspawn"); This spawns the unit at a marker named hspawn. Note that if you use this for a multiplayer mission, you should add isServer as the trigger condition (condition "this AND isServer" or "this && isServer"), because otherwise it will spawn a unit for every player due to createVehicle's global effect.

How does it behave on a dedicated server then? Nothing happens? You should put an isServer there in any case because random and BIS_fnc_selectRandom come up with different results on each client running them, and setPosATL is global, so the end result is pointless warping at the beginning, and potentially a reset to the starting position if a join-in-progress player enters the server. But it not working on a dedicated server might be related to something that's in shk_pos_init.sqf. Can you paste the contents of that file?

Same problem here, no idea of the cause. It's not very comfortable how often the game crashes when trying out different solutions, apparently in reaction to wrong aspect ratio. A similar crude workaround I could think of was to play the audio seperately with playSound, and it seems to work reasonably well. You might want to give it a try to see if it works with longer videos. Here's an example mission with both versions, and choices in the action menu if you preview it: videotest.Stratis.zip (4,3mb) I wish we got a surefire way to get it working straight from the .ogv.

It doesn't, actually, it says the parameters can be global, but the effect is local. playMove, on the other hand, is listed as being the other way around. Can't say I'm not confused.

This caught my eye since SpookyGnu said the scripts stopped working afterwards: I think you meant isPlayer and not player? player checks if the unit is the local computer, so in this case it'd be asking if the player's cursorTarget is the player itself. Sorry I can't help with the actual issue. :( Edit: And sorry I can't read, this was already pointed out in post #6...

If you call it from unit initialisation, you should use [this] instead of [_this] - though I'm not sure if the function is yet defined when unit initialisations are called? This at least seems to suggest it isn't, since cws_init.sqf is precompiled in int.sqf which is executed later. If it doesn't work otherwise, you could just put "[ai_unit_name] spawn CWS_Load;" at the end of init.sqf to test it. Or // call for units ai_unit1, ai_unit2, ai_unit3 { [_x] spawn CWS_Load; } forEach [ai_unit1, ai_unit2, ai_unit3]; // whole group of ai_unit1 { [_x] spawn CWS_Load; } forEach units group ai_unit1; Edit: Or did you try it through an unit name already, when you tried directly from init.sqf?

Just as a note (might be caused by something else too), this means time wouldn't be set if it's hosted through a non-dedicated server, OR in singleplayer. So if you're testing it in SP, it doesn't work. I'd drop that if completely, no harm in setting it to the dedicated as well since that syncs up with join-in-progress players.

The line's comment should probably be changed for clarity's sake, since it says "// Set value to 1 and a message in side chat will show when a unit is injured. 0 means this feature is disabled"

I'm not sure if that's true. Unless MCC modifies BIS_fnc_MP itself and makes it distribute the function as well, which it doesn't seem to do at a quick glance. I don't think you have to have the isPersistent flag in either case, since that specific BIS_fnc_MP will get run as part of the normal cws init.

cws_injury\fsm\cws.fsm still refers to folder ais_injury in some places, causing errors. I guess cws_ais_debugging should also be a setting in cws_config.sqf? Edit: Oh, it is there, just alone at the end unlike the other settings. Another question. At the end of cws_init.sqf you have this: //Load CWS on all playable units CWS_Load_Players = { { [_x] spawn CWS_Load; } forEach playableUnits; }; //Globally loads CWS Wounding on all playable units CWS_Load_Global_Players = { [b][[], "CWS_Load_Players", true, [i]true[/i]] spawn BIS_fnc_MP;[/b] }; The isPersistent part (last TRUE) of this BIS_fnc_MP probably doesn't do a thing, as JIP setup is executed before cws_init.sqf, and CWS_Load_Players isn't defined at that time. Currently it likely just wastes resources with broadcasting stuff which does nothing, yet would get run correctly anyway when the new player gets to cws_init.sqf.

They can. You can use CTRL + TAB to change your speech volume (talk - shout - whisper).

Are any problems with current? No actual problems as far as I know, just that playwithSix users have their CBA updated, while the archive has the old version. So there might be some confusion from differing version messages.

Should the new CBA be included in the current archive?

Not possible anymore probably due to performance reasons: http://forums.bistudio.com/showthread.php?166345-Last-update-disabled-hideObject-function-for-Wreck_Base_F-why! (Replying to an old thread since I was looking around for the same answer)

Sorry, I used a poor wording in the beginning. We weren't testing the system in the sense of using scripts to change the weather, rather we were just taking a look if the weather would sync properly in regular gameplay. However, it resulted in bad performance stutter even though the mission didn't have any scripting relating to weather, just the mission's starting overcast set to 50 in the editor. Only scripting we used was when we later ran "0 setOvercast 0" (doesn't affect clouds, but it did seem to stop the rain), which helped with the problem. forceWeatherChange is a new command?

While it's awesome that this is finally finding it's way into the game, we quickly ran into problems in missions with rainy weather while testing it. In the first game, the clients started looping the "rain starting" visual effect with ~1sec frequency, every loop causing a noticeable drop in performance. Then the rain stopped altogether and the game ran fine for some time, but when the rain started again some time later the performance drop was so drastic it made the game almost unplayable. The problem went away whenever the rain was fully halted, like when we ran "0 setOvercast 0" with the developer console, so it seems probable that the weather sync system causes this. A second mission ran fine even with light rain until the weather went into transition state, after which there were similar problems again. The aforementioned first mission had overcast set to 50, so someone might be able to test if this holds for them as well. I'd make a feedback ticket, but it'd be nice to get a clearer view of the problem first. Here's a video one of our players recorded:

Since the map works fine with AiA, would it be possible to set that as an alternative to A3MP in play withSIX? Or is there some way to download an addon without the dependencies? There also seems to be problems with lighting at night. Beside looking a lot like ArmA 2, weird black squares appear in flames, and particles in general seem a bit glitchy. This seems to be the case with every custom map, though, so I assume it's a larger problem. The map itself is wonderful, thank you and congratulations for the release.

I think this is how you do it: class CfgPatches { class your_addon_name { units[] = {}; weapons[] = {}; requiredVersion = 1.0; requiredAddons[] = {"Extended_EventHandlers"}; }; }; class Extended_PreInit_EventHandlers { extraInit = "extraInitVar = [] execVM ""\your_addon_name\init.sqf"""; }; as your addon's config.cpp, and then just add an init.sqf file with what you want to set as its contents. I haven't tested it, though. Our problem has mostly been with missions that have an irregular starting position. Or more often that people just forget to pick them up... But it's not a real issue.

I agree. I was thinking of creating a small addon only for purposes of setting the flag, but I'm not sure if it would then be necessary to distribute it to all players, or if it's enough that the host has it. Edit: Eh, didn't read the above post. I guess not, if even the TS channel setup is only needed for the host.

It's documented on the site. You need to put tf_no_auto_long_range_radio = true; in your mission's init.sqf, and then use addBackpack for the units you want. tf_rt1523g for blufor, tf_mr3000 for opfor, tf_anprc155 for independent.

Are there any plans towards a system where spectators (dead players etc) could hear those who are still alive, and talk among themselves without the survivors hearing them? Just curious if it's under consideration or if it's technically hard, it's not really an essential feature. And I just noticed I haven't even thanked about this great addon. Thank you from me and everyone in our group! That's all that is needed, yes.

Still the best mod, oh yes it is.

I got classname errors when I put down a regular Red Army group in the editor - as well as this when I tried to start a campaign - and I can't find anyone mentioning them in the bug tracker. Should I submit a proper list of the errors in there, or is this issue known already? Otherwise, thanks a lot, guys! It's currently not possible to donate to tierprot without a WebMoney account, right?