dreadedentity

Fast jump - I've screwed around with this before, all you need is a simple speed check or a check to make sure turbo is held down (sprint key if player is not in a vehicle) Endurance - enableFatigue is is what you are looking for, it will only affect units on the computer where the command is activated. (on a client machine, it means that a unit will not lose fatigue). Argument must be a unit local to the machine where the command is activated, or else it "fails". Cold Blooded - I have no idea where to begin and no ideas. Unlockable - I have no idea where to begin and no ideas. Fast Hands - There is a command for this, but I just don't have the ability to comb the wiki for it as I am much too drunk. Regeneration - Can be done with setDamage, a loop, and a global variable that indicates if damage was taken recently. I assume you want a CoD/Battlefield-style regeneration where the unit stops regenerating if damage is taken during it's regeneration cycle. The ones that I know how to do are rather easy to implement, but Cold Blooded and Unlockable I simply have no idea where to start.

If I recall correctly, nothing has changed with FSM's so using a 10-year old program is fine, in fact, it's the only way to make them. The only thing that's different is what commands you are able to use inside of them (they are all scripting commands). I have not worked with FSM's though, I've been trying to find the time, so take this with a grain of salt.

You can see this effect today if you add a lot of mods to your game

Beware of this trickery! hintSilent str str str str str str str str str str str str str str str str str (typeOf player); (random ({true} count allUnits)) * true * true * true * false * true * false * false * true; str can be infinitely stacked. multiplying an output by true(1) or false(0) can be infinitely stacked.

There is no "player" variable on dedicated server

You should push the objects around with imaginary explosions, let the game engine do all the boring junk. It is not possible to create an infinite loop that goes fast enough to setPos without making the jumps noticeable unless you sacrifice performance.

Well they should be in the config for each part. Just means you have to look for them. They should be accessible with existing commands

This will actually make the script perform worse than before because it removes the lazy evaluation, with no change to it's effect. The issue you're having is that you're trying to see what side a unit is from, however, you can't do that because dead units get added to the CIV faction (this might have been a band-aid fix, I assume that in early stages of development the AI units would not stop shooting at a dead unit because it was still on the "enemy team"). The way you should probably do this is by setting a variable in the object namespace for enemy units after you spawn them. Then you can use some code like this in place of what you have: if ((player == _killer) && {(_target getVariable "obj_side") == east}) then You also don't need to put the parenthesis around the curly braces, you can consider the curly braces to work as a substitute for them (in this very specific and particular case).

hahaha you're funny. Anybody that could read a forum post and can steal your entire idea and create a working prototype faster than a team of devs that is 60% finished deserves it. Anyway just reading the little information you gave was enough to make it sound interesting to me, I'd love to see some early gameplay. Also, you have some super insane requirements for people you're looking for, are you paying people to work on this? If not, I'm sorry but you need to know this now. Pick two: Dedicated Versatile Knowledgeable Has time to work on project The chance of finding someone who has all these traits and will work for free (team development on a project this size is definitely a job, don't kid yourself) is ridiculously low. It seems like you're looking for someone that has some kind of CS degree and a complete expert on the Arma API; basically a BIS developer or ex-dev, who also happens to have absolutely no social life and is available almost 24/7 until the project is complete, and is also very rich. Some tips for you: Money is the greatest motivator. Forget finding people that are available for testing everyday. Anybody that is married/has a job/trying to make out with hot chicks will not be available daily. Instead use a paid GitHub account and create a private hub, tell your script writers that they need to download a new version daily or something. If you exchanged phone numbers you can create a group text message and anyone can send a message to the group when they push something to the hub, this can also be done by creating a private group on steam (since Arma 3 was a steam-only release, everybody that has arma, has steam). Trying to meet once or twice a week for like 2-3 hours is so much more realistic. Writers should only push completed, and error-free scripts to the hub. This prevents somebody from uploading a POS abortion-script and other writers that are creating systems that interact with that script from having to code around their FUBAR script. If I ever found myself in this position, I would likely re-write their script from scratch, which wastes time because you have 2 people working on the same script (one many times superior than the other) and the other script is having no progress made. This is also confusing for the other guys. Basically when somebody pushes a script to the hub, it should be done, ready to be revisited in the optimization/polishing phase. One system per script/script group (i.e. The script that creates objectives should not also change or keep track of player stats). Good design should nearly eliminate this altogether, though. The most experienced guy should be reading the scripts and adding them to the initialization cycle, if only one person ever changes any of the init scripts, this will completely eliminate overwrites in the entire project. Basically, during init is the time when people are getting their major systems to run, if you let each guy change the init scripts to add his system to it then you have multiple people trying to maintain a single/a few file(s) there will be situations where data is overwritten. Quality control (make people send their scripts to the project manager with instructions for how to merge it with the mission, and test it to make sure it is bug-free and that it actually does something, then the project manager should be the only one pushing files to the hub)

Can you tell us a little more about this mission?

Try it now, it should work. I've always just saved the mission. Description.ext should be re-parsed on save.

Actually Johnny, that's exactly what the GUI_GRID variables are for

Are you planning on using your _checkpoint variables at some point? I don't recommend using call compile, and if you aren't going to use the variables anyway, you may as well not even store them. However, if you do plan on using them at some point, I'd recommend an array anyway instead of a bunch of separate variables. _signs = []; for "_i" from 0 to _n do { _obj = createVehicle ["Sign_Circle_F", _posArray select _i, [], 0, "CAN_COLLIDE"]; _signs pushBack _obj; };

No big, I was kinda proud of myself. Did it work?

waitUntil {triggerActivated _trg}; triggerActivated

rofl, you get my first "like". This is too good.

Yup that's perfect, glad I could help

It's probably because of the str command you use here, you're making a string into a string, which adds another set of double quotes around it, but it's impossible to tell without seeing what parameters you pass when you call the function. for a better visual, run these 2 commands with a short sleep in between hint "string"; //hint box shows string hint str "string"; //hint box shows "string"

I've had this issue with BIS_fnc_spawnVehicle before, I decided to just use createVehicle to make the heli and the crew and move them into the heli with script

cursorTarget

I made a simple looting system that works by spawning a new thread at each of a building's positions, you can see it here: I did not experience any kind of script slow-down, but then again I was testing the script on an empty mission, the only thing running was that script. When code runs in a scheduled environment, each command gets sent to a queue and run when it's their turn. However, imagine that you had a sink that drained water at the same rate it added water. This will work indefinitely without the water building up, but if you take a cup and start pouring more water in it, the amount of water in the sink will slowly increase until it eventually overflows. Now imagine that the sink is the queue, the drain is how fast commands can be read, and the water is commands stored in the queue. Every time you spawn a new thread, dump a cup of water in the sink. If you spawn a thread with a loop, you're pouring a cup that never runs out. The sink is pretty full and even when you stop adding water, it will take some time for the existing water to drain out completely. This is what's known as script lag, when scripts take a long time to run their commands because there are way too many threads.

Just send it anytime in a PM, I'll get it whenever I look at the forum again

Hey, I couldn't get back to you very soon. I left to go to work pretty soon after I posted that code for you, then I went out for a night on the town afterwards. Anyway, I have no idea what is causing this behavior. Could you post a dropbox link for the mission?

We're going to need a lot more information than this. Like, the full mission file to download, or pieces of code posted in the forum. With this amount of information all I can suggest is look in description.ext for an effects class, and delete it.