General Barron

See this topic: http://www.flashpoint1985.com/cgi-bin....t=63847

Just how big is this particle that you want to drop? Is it the size of a man? The size of a house? Without a p3d, how is the engine supposed to know how big your particle is, relative to everything else?

Camcreate only makes cameras now (seagulls are a type of camera). Use createvehicle or createvehiclelocal to create other object types.

Interesting project. Anyway, you *can* do this, just in a slightly different manner. The trick is to pass the variable names into the script as strings in _this. ["myvar1","myvar2",...] execVM "script.sqf" When you want to use the variable, *that* is when you use the format command, combined with the call command: _myvar1 = _this select 0; private "_currentValue"; call compile format ["_currentValue = %1", _myvar1]; //_currentValue now holds whatever "myvar1" held at this time call compile format ["%1 = damage player", _myvar1]; //"myvar1" now holds the damage of the player This is similar to the trick you were using before, only now the formatting takes place while the script is run, not when it is loaded. Oh, and no crashes from large strings.

Interesting use of the format command there; I haven't seen that done before. Anyway, is there a reason you can't just pass extra parameters in via _this, instead of using format? The only reason I can see you using format like that is to "pass" the name of a variable in to your script. If that is the case, a better solution might be to simply use one global array, instead of a bunch of individual global variables. Then you'd just need to pass an array index in thru _this (this is better on the CPU anyway; hence one of the reasons ECP changed to doing this in OFP). If you don't want to do that, or I'm completely off base, then just pass strings in via _this, and use the call or format command inside of your script to evaluate them as the script is run.

Are you sure it doesn't just override the 'moving' parameter? That is to say: if I've got a dialog with controls that have moving=true in them, but I tell the dialog that movingEnabled=false, then even clicking on those controls will not move the dialog? I'm pretty sure the HUD's work with some hard-coded engine behavior. Just like the main game menu is done via configs, but it has special hard-coded behavior like quit the game, open a mission, etc. So I'm saying, it isn't done JUST with dialogs. Almost correct. Cut/titlerscs must be defined in class RscTitles, dialogs are defined outside of any base class. Also, resources do not accept any input from the user (the mouse cursor isn't displayed), nor can they be affected by scripting commands in any way. And yes, the control types are much more limited than what dialog control types are available (since they can't take user input). The main advantage of resources is that you can still play the game normally while they are displayed. But anyway, my main point is that they are so very similar to dialogs, that yes it would be nice, and perhaps easy, for support for them to be included in such an editor (basically you would just disable certain controls when creating one, and n the output file you would put them inside of class RscTitles).

Correct, but it wasn't adjustable. Something like, if armor was greater than 10x weapon hit value, the AI wouldn't fire (see CAVS for more info). Damageresistance lets you adjust that level, for example, to 8x hit value, or 12x hit value, etc. I don't know any specific values or exactly *what* the relationship between armor/damageresistance/hit is, but some trial and error should figure it out.

Great work, and something that OFP/ArmA has always needed. Anyway, just to sort of build on what you've already found out... you shouldn't really look at that giant list of parameters and go thru them one by one. Rather, you should be thinking in terms of control types (type = CT_xxx). As you already noticed, not all control types use every parameter. Also, some (many) parameters do different things depending on what control type they are used in. So you would be better off setting up each individual control type, then testing each individual parameter within that control type. As a hint, you can find only the required parameters for each control type by simply leaving all parameters out (except type=), then trying to load the dialog. An error message will pop up, saying you are missing parameter XXX. Add that parameter in, then you'll get another error message telling you to add parameter YYY, and so on for every required parameter. Oh yeah, to make things even more complicated: sometimes different styles (style = ST_xxx) for the same control type means that the same parameters act different. This isn't very common, but I did notice this behaviour in resources, so I'd assume the same could be true of dialogs. Last thing, please do more work and make a resource editor as well! Resources are *very* similar to dialogs (only simpler), so this couldn't be too much more difficult to add in... see my tut on OFPEC for more info on resources.

It tells the AI how powerful a weapon they must use against the vehicle. I think it is multiplied by the armor level, then the AI compares their weapons to this number. If their weapons can't penetrate that much armor, they won't fire on the vehicle. Basically, by adjusting this value you could make the AI shoot pistols at tanks, or force the AI to only use missiles (not bullets) against cars.

Another idea that might work, though you will have to do some testing: Try the assignedTarget command. I'm not sure exactly when the AI starts assigning targets, but I would assume it would be right as soon as enemies are spotted. So basically, if anyone in the group has an assigned target, then the group is engaged. Again, you should defineately look into testing this, I'm just making some assumptions (though I have used this command before).

Close. A group doesn't change combatmode, but it does change its behaviour. A group will automatically change their behaviour to "combat" when they see/engage enemies. After they decide the engagement is over, they will switch back to whatever mode they were previously in. The only exception is if they are in "careless" or "stealth" behaviours. In this case, they will stay in these behaviours, even if they engage in combat.

Interesting concept, I definately like the idea. Perhaps check out my OFP MP voting/admin console for some ideas regarding voting: download forum thread It also has a very simple but effective system of punishing players, where the player is simply placed 10000m in the air by the server, and keeps being replaced there every few seconds, ensuring they stay there even if they have their own scripting console. Some general ideas/suggestions: Would it be possible for a cheater to edit the map and change/disable the scripts? Or does the game do a check to see if the player's mission.pbo is exactly the same as the server's? Either way, it would be a good idea to store the scripts entirely in a .pbo which is only kept on the server (you can make calls to scripts in a pbo without it being in the 'requiredAddons' section of a mission). Mission makers would have to put a single line in their init.sqs, which is something like: ? local server : [] exec "\cheatDetection\init.sqs" All the anti-cheat scripts would then obviously be run from the server only, preventing tampering by clients with a debug console. This would be good because: (a) cheaters wouldn't be able to know what the script does unless they get a hold of the appropriate .pbo (which should be carefully distributed), and (b) you would be able to update the anti-cheat scripts by updating the one .pbo, without having to touch the maps (the one line in the init.sqs is all that is ever needed, from v1 onward, all other scripting is stored in the addon). As a little hint on implementation, the init code in the createUnit command is run on all clients. Using that fact, you can have the server execute whatever code you like on any client.

_name = squadname index = lbAdd [113, format["%1", _name] or in ArmA: _name = squadname index = lbAdd [113, str _name]

This is set via initSpeed in the magazine's config.

I think a simple conversion would be relatively... simple (though maybe time-consuming) for someone who understands the differences between ArmA and OFP scripting. The dialogs would likely have to be reworked a little as well, due to differences between ArmA/OFP dialogs. Radio model/configs would have to be removed or updated. And last, the anims would need to be changed, which is something I know nothing about. One thing I am worried about is the new FSMs, which I have heard can cause havoc with the 'domove' command. If that command doesn't work properly, then the whole system won't work at all. Aside from that, the only major issue is the anims, which can be left out temporarily, or placeholder BIS anims used, anyway. ----- This would take a ton of effort, but it really would be the best way to go. It would be the best way to fix the current bugs (such as buggy vehicle interaction, rally command, slow formations), and it would make it so much easier to add further improvements. However, I wouldn't expect anyone to do that, especially anytime soon. ----- I will give guidance to anyone who wants to seriously take on either of these tasks.

Yes actually, I've heard of people using a free program called Shoot! with great results. I never got around to trying this out myself, but it should be fairly easy to set up as many voice commands as you want. You'd just need to bind them to a key via Fwatch, then configure Shoot! to 'press' that key when you say the appropriate command. It should work great, would just take some time to set up. Relevant threads: http://www.flashpoint1985.com/cgi-bin....d+voice http://www.flashpoint1985.com/cgi-bin....om;st=0 http://www.flashpoint1985.com/cgi-bin....;st=105 (scroll down to lecholas' post)

I'm a blatant self-promoter, so the link is in my signature. But I'll post it here as well: http://www.flashpoint1985.com/cgi-bin....t=48000 If you depbo it and poke around inside, feel free to PM/email me with any Q's about this or that.

Enter Kegetys Fwatch, one of the most powerful and under-used scripting aids for OFP: http://ofp.gamepark.cz/index.php?showthis=8361 Fwatch can't detect joystick input AFAIK, but it can *kinda* detect mouse movement. Detecting keyboard input is easy enough though. Below is a template of a simple keyboard input script I've made for my handsignals mod (link in my sig). It should make sense after you read the Fwatch documentation. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">;Keyboard input detection script template. This script should be started from init.sqs. Requires Kegetys Fwatch. _k = [] #Top @call {_k = call loadfile ":input getkeys"; ({_x in _k} count ["1","2","3","A","B","C"]) != 0} ;check which number key was pressed ? "1" in _k : (do something); goto "Wait" ? "2" in _k : (do something); goto "Wait" ? "3" in _k : (do something); goto "Wait" ? "A" in _k : (do something); goto "Wait" ? "B" in _k : (do something); goto "Wait" ? "C" in _k : (do something); goto "Wait" ...etc #Wait ~0.5 * accTime goto "Top" List of all keys detectable by fwatch (and the name returned): A-Z, 0-9, F1-F12, NUMPAD0-NUMPAD9, TAB, CAPSLOCK, SPACE, ALT, CTRL, SHIFT, BACKSPACE, ENTER, DELETE, INSERT, END, HOME, PAGEDOWN, PAGEUP, UP, DOWN, LEFT, RIGHT (arrow keys), SUBTRACT, ADD, DIVIDE, DECIMAL, SELECT (math operations on numberpad).

Yup, I did just that. I verified Hawkins' link and it does contain v1.2. Sorry about the confusion, but I've removed the broken link so it's all ok now. Thanks a million for the mirror an the help . Absolutely. The stringtable should already support a number of different languages, check the readme for a list (but Russian is broken, though the readme says it works). As far as voice packs go, I would love to see those made in other languages as well. You can contact me for instructions on how to do just that, because I never got around to making a readme with instructions. With all the new scripting commands, FSMs, etc in ArmA, someone is going to be able to make a MUCH better version of this than my little hack-job . As for me, due to RL I won't really be doing any more public ArmA/OFP projects. I'll still be 'around', but I won't be taking on projects like this one anymore.

---meant to edit this post, but made a new one by accident. Moderator please delete this post.---

Functions (that is, stuff run via the 'call' command) are faster and more efficient than scripts (that is, stuff run via the 'exec' command). In OFP, you can not pause execution of a function, only of a script; so any waiting *must* be done in a script (exec). If you kept everything in functions you possibly could, only using scripts for delays, you might be theoretically better off (unless you try to do something like 100 drop commands in one function). However, most people seem to under-estimate just how efficient scripts really are. A single aircraft causes more lag than like a thousand simple scripts. The only times you *need* to get picky about performance is when a script is going to be run *very* often (i.e. each bullet fired), or is complex and runs a ton of copies of itself (i.e. for each man on the map), or is running in MP and needs to communicate over the network (via publicvariable). No. OFP scripts are not "strongly typed" (wikipedia it) like C++/Java/etc languages are. Any variable can hold any type of data, so there is no reason to declare a variable ahead of time as a specific type.

The game engine will automatically make soldiers go to heal at medics, no need for scripting or anything. It helps if the medic is in the same group as the wounded soldier, but that isn't really required (since soldiers can heal at medic tents for example; they just need to know about the medic if he is in another squad). RHS might have done some scripting beyond this; I dunno as I've never tried them out. Try the exact same situation, only with BIS units and medics, and see if they behave differently. If so, there might be some scripting going on (or just depbo the addon and look).

MAJOR thanks to you Garcia! Sorry about the delay, but I've now updated the first post with the details. I've also taken the liberty of modifying the download package a little bit, please use this one instead of Garcia's link (and Garcia can you host this version instead please?). Download link: (see first post) I'm also going to announce that I'm officially ceasing development of this addon. Okay, I ended after I released v1.1, but I mean to say that I won't be working on this in Armed Assault. If anyone wants to continue working on this addon, feel free to do so and release it under your own name/tags. Also feel free to contact me if you want any help/advice. I appreciate all the support and interest that has been expressed in this little concept, and I hope people continue to improve on it in the future!

That will only apply the direction the player was facing when the event handler was added, not the direction the player was when hit. The parameter your adding is a fixed constant. Um, yeah, that's what I said . I guess I didn't explain myself very well, but I was rushed . Anyway it is tough to follow what I've written, but it uses the same principles that are used to dynamically name global variables, if you've seen that done before. It's a very powerful and handy trick. I got halfway thru a tutorial on the subject quite a while ago... maybe I'll finish it off sometime.

Sorry I don't have time to make a proper post but you need to use the 'format' command to dynamically change the code issued to the eventhandler. Example: player addeventhandler ["hit", format["(_this select 0) setdir %1", getdir player] ] This is a non-sense example, but what it does is this: When the eventhandler is added to the player, it 'types' the direction the player is facing at that moment into the EH code. For example, the player is facing 30 degrees when the EH is added. From then on, whenever the player is hit (i.e. the EH code is triggered), the player will be set to face 30 degrees. If you ran the mission again and the player was facing 90 degrees when the EH was added, then the player would be faced to 90 degrees whenever he is hit. You can only 'type' specific data types into code this way: numbers, bools, sides, strings, and arrays containing those types (not objects or groups). If you don't understand why, look what happens when you 'print' out a variable using format: hint format ["%1", my_variable] For some data types, the text that is printed out is the same as the text you type into a script (for example, a variable holding the number 1 will print out '1', the same thing you type into a script to refer to the number 1. A variable holding the player will print out something like 'west alpha black', which is not what you type into a script to refer to the player). That was much longer than I meant to type, and I'm sure it doesn't make much sense. But the idea is you are using the 'format' command to dynamically write your code into the script after the mission starts.