blackmamb

Performance wise, I guess not really. On the other hand, in terms of amount of scripting (and also in filesize), they are. Keep in mind that I'm trying to make something as simple to use as possible, even for not very experienced mission-makers, somewhat along the lines of what F3 does. Overwhelming them with incomprehensible code is not always the wise thing, and letting them do most of the stuff from the editor, without going into too much scripting is the goal here.

Amen to that. Although it might lead to some confusing stuff when it comes to actual objects. That's what I'm currently doing, except I define the to-be-deleted triggers by syncing them to a gamelogic. It's working fine, but feels a bit overkill, if you know what I mean. I've been tempted to explore the marker way, but triggers do have interesting uses when it comes to spawning, that markers couldn't have without quite a bit of additional code, and I'm trying to keep this thing as light as possible. I'm not willing to elaborate to much on this project as it may not ever be released under any form (some Community scripts do all that already, and much more), but the goal here is to add to the F3 framework a simple spawning script to help in-house mission makers cater with the possible future addition of an Headless Client for our sessions.

Thanks, Taijin. Makes sense. In a weird, twisted, Bohemia-like way. The setVehicleVarName idea was quite cunning! Unfortunately, I can't seem to get it to work. I guess I'll quickly update the OT to explain that I need editor-placed triggers (the whole point of the thing is to spawn units easily from editor-placed triggers. Not using editor-placed triggers would be surprising). Maybe I'll even ask BI to get us a deleteTriggerLocal command. That'd be most useful. In some very rare occasions.

Just reproduced it in regular and elite: they don't appear on elite. So it's related to the difficulty, although it still seems to be a bug, as it doesn't happen with editor-placed waypoints. I'd suggest writing down some good repro steps and opening a tiket on the feedback tracker, papy.rabbit.

Sorry, my question was somewhat unclear, so I'm not sure what you're saying here. Using isServer wouldn't solve things. The trigger would still constantly check on each machine if they are the server, which is not what I'm asking here. Then you say the trigger exists locally, when my test seems to show that they're actually existing as a global object. Is my test flawed?

server setvariable [_gateID,_gateAction, true]; should broadcast the new value over the network. Currently, you're only setting the variable on the local client.

Actually, _this is not the player. The second one refers to what is passed to the script by the action, e.g an array containing [caller, target, ID, arguments] position (_this select 0) should do it.

There are a whole lot of uses to reading config files in scripting, but it wouldn't make any sense to even start listing them. Regarding modifying configs from the mission file, that's unfortunately not possible. It was introduced in an A2:AO beta some time ago, but quickly removed due to a shitstorm on the forums. So, yeah, an addon is the way to go here.

That's quite a hacky way, but it's the only way I found as well (I thnik the probability of getting exactly 0.25 damage is negligible anyway). HandleHeal doesn't detect self healing. Upvoting this might help.

I don't think we'll switch to A3 that soon though. We're still missing content (even though mission makers are starting to work on that as far as I know). We'll see how stable A3 is on release as well. (and a proper medical system. Damn you, handleHeal). But then again, I'm no official voice in FA.

I'll add some more grass in a chapel, at Agia Stemma (078 146).

Tiny issues: the Agios Kosmas chapel (085 073) has grass inside it. http://cloud-3.steampowered.com/ugc/597013097393166137/41C2257320D2E3960F1C472DB4C9C8952CFF1481/ The Xirolimni Dam (092 137) could use a slightly better geometry. I understand it's probably not supposed to be a walkable surface, but falling on it is possible, will wound you and get you stuck. http://cloud.steampowered.com/ugc/597013301921731835/F43812EE63C802456E5A0E0BFFA899B9AA1C53CE/

I need to have a proper look at that yet, but I think these functions have been included in Arma 3. Have a look at the function library, I think it's under A3/Misc (or network, don't have the game launched right now).

Nope. The headless client doesn't have any rendering to perform.

Do you run one of the latest betas? I think those are added by the CCP so that you can't have a AS50 and a backpack simultaneously.

As I said, that code works just fine. But so there are no misunderstanding here, whatever you do, it won't change the model of the weapon: you can have a Mk19 if you want, but it will look like an M2. Otherwise, you need a mod, and you're not allowed to modify BIS content.

Well there are already humvees with mk19. Why don't you just use those? By the way, that code works just fine.

This issue was fixed quite some time ago already. There is no issue with HC exept from the fact that is needs quite a bit of work to adapt existing missions to it.

_actionid can't have been already added. It always increment everytime you add an action, even if the action you had is the exact same that the one you did two seconds ago. One good way to keep track of what you're doing with objects is to use setVariable. _isAction = _target getVariable ["TAG_ActionAdded", false]; // checks if the action was already added, returns false as default. if _isAction exitWith {}; // gets out if the action was indeed added _actionid = _object1 addAction ["Stuff", "stuff.sqf"]; // adds the action _target setVariable ["TAG_ActionAdded", true]; // remembers the action was added

You don't need the if check here. _IHR = getNumber (configFile>>"configAmmos">>"Explosion">>_explosive>>"indirecthitrange") < 5; already makes it a boolean. Edit: Basically what you were doing amounts to if (true) then {true} else {false};

In your example, the variable is referenced as _isMan. A good practice, though, is to make those _isSomething variables boolean. Makes it easier to read. So: _isMan = (getText(configFile>>"CfgVehicles">>"Land">>"Man">> "displayName") == "Takistani (turban)"); _isMan will be true or false, depending on whether your dude is actually a Tkistani with a turban or not. Although this would work, the displayName is probably not the best option to check on the identity of a unit. faction, or typeOf might be better, depending on the case.

No it's not.

On player connected probably happens a lot earlier than the client's init.sqf. So data1 is actually overwritten in the init.sqf, and goes from "lol" to nothing, not the other way around.

Oh. Didn't see it that way. Damn.

Hey Robalo! I'm pretty sure I once knew the answer to this, but can't find it anywhere anymore. Is there a way to override the AI skills on a per-mission basis (meaning not tweaking the config, so that the next mission uses the usual settings)? For example, if i use setSkill on some units (I guess not immediately, so that happens after ASR AI init on those units), will they be forced back to ASR levels? If not, is there a way of knowing when a unit has been initialized by ASR AI (That I'm pretty sure there is, but since I'm here, I'll ask anyway)?