Pulverizer

Hi. You can find one in WarGames League mod (WGL), under addons/wgl_ui.pbo->compass/ Looks like this: http://dslyecxi.com/images/ofp/ttp/weapons/wgl_compass.jpg Default compass is in dta/(hwtl/)data3D.pbo->kompass.p3d You may need to change the texture paths with this tool or a hexeditor to get it working: ftp://ftp.ofpr.info/ofpd/unofaddons2/TxtPathSwap.rar

There's literally dozens of non-Valve games that use VAC, get banned on one and you can't play on VAC secured servers in any game: http://en.wikipedia.org/wiki/Valve_Anti-Cheat#Games_that_support_VAC

You can camCreate tracer ammo but it's really weird seeing them without hearing the shots, given the low view distances. You could use real gunners with invisible targets for a more authenting feel, but scripting life-like movement for them would take some effort.

You could use condition: player knowsAbout general > 0.5 Player could then use binocs and right click on the general to "reveal" the target. For a camp without the general, knowing about other units there could be used as the condition.

Yes I am sure. If you don't see it, you just haven't placed enough units to cause a noticeable fps drop. With 756 units standing still doing nothing, on my PC I get 52 fps and if the AI is running forwards 30 fps. Without the AI it's 220 fps on Everon. The scripting commands simply don't allow you to exceed the limit (createUnit will not create a unit, join grpNull will not disband the unit from its group). If you'd manage to bypass the limits with some trickery, it would probably cause the game to crash or some other unexpected results such as schizophrenic AI. DAC was originally made for OFP.

Even idly walking AI use considerable CPU because of the path finding. Yes, it would involve scripting, why, is that an issue? Spawned units count, you cannot exceed group count or group size. If it's internet MP, with these kinds of numbers you are pretty much forced to create the AI dynamically or have terrible desync as every moving unit will use server bandwidth constantly. There are several ready MP compatible solutions but you will probably have to modify them slightly for your needs. Dynamic AI-creator (DAC) and Chain of Command AI-on-demand come to mind.

Is spawning civilian AI only to exist near the player out of question? That would solve both bad performance and the group limit. When I tried maxing out two sides (1512 units) with every unit fighting, my fps drops to single digits. OFP wasn't programmed to have that many AI active at once.

They're still douchebags. Why?

Try using createVehicle instead of camCreate. I think camCreate is intended for creating special fx, so the planes might not have all the necessary properties that "real" planes do for the trigger to activate.

Not really, a trigger can also have a condition to only activate locally (eg, condition: local serverLogic && this, onActivation: obj1done=true; publicVariable "obj1done"). I would rather say that in some cases it's a waste of resources to make a trigger for a condition that only one client or the server needs to check.

Triggers only check their condition every 0.5 seconds. You can verify this with a condition like: call{player globalchat format["%1",time];false}

It's still not really Full HD though. It would be 960x1080 stereoscopic (with the screen split in the middle for two eyes). A Full HD 3D monitor would basically have twice the horizontal detail, which can be quite important in a game like Arma.

It would be a good publicity stunt to be one of the very few games to actually officially support Oculus Rift, but not much more. You would be at a huge disadvantage at 640x800 resolution compared to proper monitors, and the consumer model is at least a year or two off.

I would start by googling articles (or even buying a book) about turn-based and realtime strategy game AI, written by some professional game programmers. It's a very complicated task, but you can probably also find some simple yet effective methods that would be suited for OFP's scripting limitations.

I haven't tried yours, so no reason to get offended. I made a similar script for Arma1 and OFP back in the day, just to test how it would affect gameplay, which I thought was negative overall for reasons already discussed.

Classic Metalcraze. Ignore all actual arguments and substitute with a straw-man that is completely offtopic. *golf clap* :p For the record, I find revive scripts and the magic heal mechanics rather ridiculous and would rather not have them in the game at all. Medics should stabilize wounds, not heal them with magic.

Well to simplify everything is of course more practical than to make wind behave as you would intuitively expect it to. But again, if you're happy with physics from Bizarro world, I suggest you download it as a simple mod instead of forcing it as a standard feature.

It's more about the type and shape of the land, rather than mere altitude. Au contraire. It would require even more MP syncing because the people in the same general area should witness same effects. This would probably require some kind of repetetive pseudo-random patterns that would lessen the amount of syncing needed. I'd say it would be visually very inconsistent to see (thus the more difficult for me to judge wind based on) AI next to me have its tracer rounds fly straight and true while mine would curve of a meter to the side in the same exact conditions. Having no real world data, I can't tell for a fact wether it would be worthwhile either. However, due to the huge relative size, weight and speed differences of ammunition, I would think the effects of wind are also significantly different on them IRL.

For instance: -MP syncing issues that Dwarden already mentioned -Wind should generally be stronger in the open, mountains or shores than say woods and densely-built areas, valleys or indoors -Wind shouldn't be a single, global vector all across the land, not in force and not in direction. it should also be unpredictable and have fast microvariation. -AI should also have to compensate for wind -Wind should probably affect a .50cal sniper rifle bullet quite differently compared to 9mm subsonic pistol round or a cannon shell or rocket, m203 grenade etc. There might be not enough real world data available to base all this on. Those who are happy with the simplest imaginable wind "simulation" can very easily add it as a script or mod to their game.

A simplistic, unrealistic and inconsistant scripting workaround is not up to the quality required for a standard game feature IMO. Better leave it for mods. It should be far more complicated than simply adding a bit of wind to bullets over time as the mods and scripts do it.

Yes to both. However, commands for string manipulation are very limited. Dialog tutorial: http://www.ofpec.com/editors-depot/index.php?action=details&id=37&game=OFP

It's trivial to make "wind simulation" wrong but extremely difficult to do right. So keep it to mods.

That would work for missions that do not have anything else than mission.sqm. Scripts, sounds, briefing etc would not be copy pasted.

Hello. You can move an user mission to a different island simply by renaming the folder ..ofp/users/name/missions/my_mission_name.islandname/. For example renaming test.Intro/ to test.Eden/ would port the mission named "test" from Desert Island to Everon. To find out what the correct island name is for the one you wish to use, load it in the editor, place one unit on map and save as "whatislandname". Now you will find the island name by searching for the folder "whatislandname".

I guess you are talking about mouse smoothing? I keep that off too. I got the idea that when people talk about negative acceleration is that they really meant the turn rate cap, which I have no issue with because it's silly that you should be able to do an instant 360 with a flick of the mouse.