General Barron

These are the overall effects classes (determines which light and particle effects to use): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Class MissileManualEffects Class MissileEffects These are the particle effects classes used in the above classes (determines how the particle effects look): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class MissileManualEffects1 class MissileEffects1 I believe they reside in ca.pbo, but I'm not sure.

The switch is working correctly. The switch returns the results of the very last command processed. In your example, the last command processed is: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">hint format ["%1", _index] Obviously, the 'hint' command doesn't return anything, which is why _index is being set to null after the switch.

Exactly. Upgrade to Arma, with a (slightly) better physics engine, and a (much) better scripting engine. You don't want to spend your time messing with "impact spheres", just to make a simple rotation. It will take you forever to build your flight simulator if you need to hack your way around limitations in the scripting engine like that! For Arma, try my set pitch/bank function. While you're at it, maybe you or vektorboson could use your (far) superior math skills to figure out the bug in my get pitch/bank function (see the thread). In Arma, there is also a version of FWatch available for Arma. Or, you can also capture keyboard / mouse input in a dialog, and use it there (no need for external apps). ------- You also have more control over an aircraft's flight model via configs, which in your case might make it easier to "switch off". Actually, in your case you are best off flying a static object around, not a real plane, because then the engine will only simulate gravity (and maybe drag).

As sickboy said, the problem lies with the original addon(s). Addons should NEVER have a class CfgModels in their config.cpp, because it can lead to problems like the one you are seeing. Instead, addon makers should binarize their addons, and use a model.cfg. I suspect that a lot of addon makers don't use the proper tools pipeline, but rather try to use community pbo packers and other tools to make their addons. That leads to problems like these, unless the addon doesn't include p3d models.

The problem is in the animation. Somehow, it is either not configured correctly, or the .rtm itself is messed up. But if you made your proxy you see in buldozer from the rtm you are using in your config, then I doubt it is the rtm. Maybe post your full config, or at least the animation's config + the turret's config?

I think it is a clever and interesting idea. The Arma physics engine is a bit... funky... when dealing with collisions though. I don't remember OFP being any better. So in practice, this might not turn out so well. But without actually trying it, there is no way of knowing that! So I'd definitely try it out, the results might be very useful. Bear in mind though, you are dealing with 3d objects, not points in space like in a math book. There is no way to locate an object's center of mass via script (that I know of), so you won't be able to fire your impulses directly at it. So in practice this might not work out very well, because part of your force might end up making a rotation, instead of a translation.

The very first time I ran the preview mission, I got an error which of course I didn't take a screenshot of. It said something about this line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _gameLogic action ["useWeapon",_x,_x,1]; I believe the error was saying that something was an array, not object. Of course, I haven't been able to repro the error anymore . ---------- Aside from that, it looks pretty good. It might help to know exactly what improvements this script is supposed to have, so far I only really noticed that the AI will fire randomly into the terrain around them when they know you are somewhere, but can't see you. This feature is pretty nice, but I'm keen to know what other possibilities the script has. Overall, very clean and nice script!

I'm very interested in this. I was only able to try the 3rd demo mission, since I don't have CEX. However, I was unable to really get a good idea of what the script was doing. I think the demo mission was part of the problem, because it basically led the blufor into a retarded, uphill assault, which made it difficult to tell if the script was making them act any more intelligent then normal.... Perhaps a simpler demo mission, on flatter terrain, where you can clearly see the difference in how the AI behave, would help. The one thing I *was* able to notice, was the radio chatter from the AI, which actually was a good feature just on its own. For those who haven't played Close Combat, or tried this script, basically groups will tell you when they come under fire. Better then that though, the groups will tell you when they are "pinned down", basically meaning they are taking HEAVY fire. I could see this as VERY useful in Command-Engine type missions, because it lets you quickly decide what groups are in trouble, vs which groups are fighting, but doing OK.

I haven't read thru the whole thread here, but I get the impression you are approaching the problem from only one angle. That is, to make sure the player loads the game with only BIS stuff, and no extra addons outside of a specific, publicly 'approved' set. Then all servers need to only allow that set. What if you kinda went the other way around? I'm not sure how Arma MP works and what kind of tools are available, but what if you had an external program like the old OFP Watch, which tells you what servers are available. Each server would have its own listing of "required" and "optional/allowed" addons. The program would know what addons you have available on your computer. Therefore, the program would be able to tell you what servers you can and can not connect to, and obviously it would be nice to be able to automatically download required addons. Anyway, instead of having to deal with mod folders, you could have all of your addons in a single location on your HDD. The program would then move only those addons required / allowed by the server you want to join, into a single mod folder, and start Arma.

I don't understand what you're asking at all . What I'm saying, is that there is no difference, speed-wise, between the following scripts: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> myfunction = compile preprocessfile "myfunction.sqf"; [] call myfunction; [] call myfunction; [] call myfunction; [] call myfunction; [] call myfunction; <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> [] call compile preprocessfile "myfunction.sqf"; [] call compile preprocessfile "myfunction.sqf"; [] call compile preprocessfile "myfunction.sqf"; [] call compile preprocessfile "myfunction.sqf"; [] call compile preprocessfile "myfunction.sqf"; There is a perfectly reasonable assumption that the first script would be faster, because the second one looks like it would be loading the file over and over, while the first would only load it once. This assumption is incorrect. In the second script, the engine already 'remembers' that it compiled myfunction.sqf, and it is smart enough to not reload the script over and over again. So the first script basically wastes a global variable, for no real gain/reason. -------------------------------------------------------- A better practice would be to write the following: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #define myfunction compile preprocessfile "myfunction.sqf" [] call myfunction; [] call myfunction; [] call myfunction; [] call myfunction; [] call myfunction; This is just as "nice" looking as the first example, but it uses no global variables. Instead, the define is used to do a find/replace operation when the file is preprocessed (when loaded in-game, this script looks identical to the second example I gave above). If you have a lot of functions, you can throw all the #defines in a separate header file, and use the #include instruction at the top of your script to include that file. This same trick is great for other constants, such as IDCs. I've seen a lot of scripts that waste a LOT of global variables, storing data that never changes.

The weapon appears to be configured properly, I'm guessing the vehicle simply cannot "see" far enough to use the weapon at maximum range. Some parameters that might influence how far a vehicle can see (placed in the vehicle's config): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> sensitivity sensitivityEar irScanRangeMin irScanRangeMax irScanToEyeFactor irScanGround laserScanner Its also possible that the ammunition parameters are preventing the AI from using it. I think I read somewhere that "maxSpeed" in the missile's config is used by the AI to determine how high to aim rocket launchers. Perhaps that or another parameter is making the AI think that the missile simply can not reach that far.

It might be more efficient to add 'fired' event handlers to all units / vehicles on the map. If they fired somewhat in the direction / vicinity of the player, then you could follow or extrapolate the path of the bullet to see if it goes near the player.

Nope, it only compiles the FIRST time it sees the 'compile preprocessfile' command. Subsequent commands take no time at all. Example: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> for "_i" from 0 to 100 do { [] call compile preprocessfile "myscript.sqf"; sleep 0.1; } In this code, there will be a slight delay the first time "myscript.sqf" is run, as the engine compiles it. But every subsequent time it is run, there will be no delay, because the engine doesn't need to compile it anymore (its already been compiled). This is simple to demonstrate via experiment. Sorry, I really didn't mean to hijack your thread though...

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">/* PreProcess the File to save load times and easier execution. */ Storing code in a variable does NOT save load times. There is NO reason to use a global variable to store a constant; use #defines instead. The engine caches scripts when you use the compile command, so it only loads a given script ONCE, even if you issue multiple "compile preprocessfile" commands. This is easy to prove via experimentation. Sorry for being picky, I just wish this little misnomer would go away...

Yes. Unfortunately, I couldn't tell you exactly how this is done.

I can understand the resistance / hesitation to the idea of using a computer to train infantry skills. Bear in mind, that the USMC has been using "simulations" like sand tables, simple games for fire support adjustment, etc, since 1775. VBS just seeks to make these simulations a bit more useful. I think the main point, is that no one is saying VBS should be used to train skills that are easily trained in real life. In no way can a computer replace getting dirty, crawling in the mud, digging fighting holes, etc etc. The important point though, is that you can train some things in VBS which you simply *can't* train in real life. Read some of the above posts for examples. Also, you can train faster and more times, compared to real life. I'm sure you know the phrase "hurry up and wait" quite well. Sometimes it takes so much logistics, just to run a simple exercise that doesn't really have much training value. On one such roleplay, I spent 3 days sitting in the desert, waiting for a *single* convoy to drive thru our little "Iraqi town", so we could pretend to be harmless Iraqis. There was a *bit* of training value to the scenario, but if you ask me, it wasn't worth the enormous cost. It could have been run 50 times over in VBS in the same amount of time, plus they would have been able to see AAR between each scenario, so their NCO's could point out what they did and didn't do well. Bear in mind, earlier in the week, we had been slugging simunitions at each other as they practiced house clearance. THAT is something I will never forget, and I felt 100x more prepared for a house fight after that single afternoon. No way could a computer do that. There is definitely a place for computers to help train the warfighter. The USMC, and others, are trying to find that place. What they need is people like you, who know what they are trying to teach, and what they can and can't teach well with the current tools. People like you are the ones who can help figure out this new tool's place in the training schedule.

To remove the smoke/fire destruction particle effects: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class DestructionEffects {}; To remove the secondary (fuel/ammo) explosion: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">secondaryExplosion=false;

I haven't read thru the whole thread, so I don't know if this has been solved already or not, but here goes... ------------------------------ To give a config to a visitor-placed object, you need to configure the object with a special classname. The classname of the object MUST be: land_modelname Example: model name: genb_myHouse.p3d class name: land_genb_myHouse You MUST use this classname convention, it is the only way to tell the engine what config is used by your visitor placed model. Using this classname, you would then configure it as you would configure any other house / ladder / whatever. There should be examples all over the forum, else look at BIS stuff. Also, your model must have the named property "class = building" or "class = house" in one of the LODS (not sure which, might as well put it everywhere though). If you have some other class property (like fence, tree, etc), then the engine will ignore your config. ------------------------------ Notice that the config of the objects has nothing to do with the visitor process. They are separate processes, so the locations of the building models vs the location of the map are irrelevant. I could make some building models and release them as an addon, and you could place those buildings on your maps without needing the configs or the unbinarized building models. As long as the end user has both addons installed, and as long as the buildings are configured as mentioned above, then the buildings will work fine. Later on, you could change the config of the buildings, and you'd see the changes in-game, without repacking the map. They are separate processes. --------- Also notice that this means model names must be unique, otherwise configs could get overwritten! For example, lets say BIS has a 4-door house, with a model name "housebig.p3d". Now, say you create a 5-door house, and call the model "housebig.p3d". Now your config is in conflict with BIS's config, so one or the other house will not function correctly when both addons are installed. For this reason, its best to use OFPEC tags for all of your p3d model names that you will place on a map.

Or, you can download them all from here. These include all the source configs, so all the #defines / etc are still there. Plus, they are organized in the source folder and config.cpp structure, so they should be better organized (as opposed to being one big file).

Don't waste any more time with those commands, they are a nightmare! Grab my set pitch/bank function here. They are easier for humans to work with. So then, all you would need to do, is find the angle between the missile and its target, and then set the missile's pitch to that angle. So, if the target is at height of 5m (ASL), and the missile is at height of 20m, and the missile is 50m away, then the pitch required by the missile would be about 16.5 degrees. You can find this using some simple trigonometry, which isn't really that hard because all you are doing is dealing with triangles sin/cos/tan. I'm hoping you already know all of this, because then I don't have to draw a diagram, which is the only real way to explain how to do this stuff.

You are speaking from a gaming perspective. Firing a rifle in the game is not simulation, it is gaming. In NO way does using a mouse "simulate" using an actual rifle, any more than holding the W key "simulates" running. I'm not saying it is right or wrong to want to have to practice to be good at this aspect of the game. Games are about competition, and for some this would be part of the competition. But don't make the mistake of thinking that somehow a mouse can simulate a rifle.

Exactly. I'm guessing this is why the flight sim place didn't survive. I think you'd find that the cost of LABOR would be far, far more expensive than a relatively small one-off payment for the software. I guess this is the case for many businesses though, which is why my car is built by a robot and my calls are serviced by Indians.

Most people are quick to dismiss other people's business ideas, but remember that most people in fact work for someone else's business. I'm not saying this *would* work, but it *could* work. The only problem is that VBS caters to a small niche market compared to video games in general. Your target niche might be even smaller. I remember a business called "The Other Side" when I was a kid, it was a LAN place that specialized in flight sims (and Duke Nukem 3d). They had these enclosed pods in this dark room that you played in, with the full flight sim controls, radios to talk to your friends, etc. They even had trained pilots who would administer scenarios for you. Before you started playing, the admins would actually take you into a special briefing room, where they would give you a top-gun style mission brief. It was a great place, but it eventually went out of business. Maybe they didn't push their niche hard enough, or maybe it just wasn't able to stand up against the increasing numbers of people with their own home computers. But it was a unique experience, something you couldn't get at home or even at a friend's LAN party. What most sets VBS apart from ArmA is (1) the real time editor, (2) the after action review, and (3) the compatibility with other sims. So you'd be best to exploit these differences, and find a target market that finds these important, or else stick with ArmA. (1) would be very useful if you had administrators for the scenarios, because new and interesting scenarios could be created on the fly. (2) might be of interest to very serious gamer groups who want to train together. Maybe you could set up a league with prizes to encourage groups to train together. It would also be fun for party groups to see how they completely murdered their friends. (3) would be very cool, because you could get Steel Beasts for the tankers and Lock On or some other flight sim for the pilots. This way you would expand your market niche to cater to these other hard-core sim fans. Imagine if you are a flight-sim fan, your buddy is an ex-tanker, and your other friends like first person shooters. You could all play together in the same scenario, and yet not have to sacrifice any level of detail for your individual roles. Anyway, like I said, I think it *could* work, but I think you'd have to work *very* hard to exploit your niche.

Unfortunately, surface penetration is rather limited. A bullet's speed determines how well it penetrates, nothing more. So a .50 cal bullet isn't going to penetrate as well as a 7.62mm bullet, due to the higher speed of the 7.62mm round. Also, the thickness of the surface in the fire geo LOD is what determines the surface thickness, not anything in the .bisurf file.

I guess this wasn't the problem here, but it is worth mentioning anyway: String comparison is case sensitive when using the "in" command! When using == string comparison is case insensitive. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> Example: "soldierwpilot" in ["soldierWpilot"] //result is FALSE "soldierwpilot" == "soldierWpilot" //result is TRUE Also, when using the "switch" command, this is also case sensitive. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> Example: _var = "soldierwpilot"; switch _var do { case "soldierWpilot": {}; //this will never be reached, due to the uppercase "W" case default {}; }; The safest thing to do when using "in" or "switch" commands and strings, is to first convert all strings to lower case using the "toLower" command.