vektorboson

Of course people can have it the plug'n'play way: Include the FED-dialog into their resource.cpp; that way it is always loaded, and does not require to create a description.ext and mission directory. But it requires some basic config-editing. (in the meanwhile everyone in this community is some kind of modder, right?) How could I do this the right and easy way. Because not having to place the description.ext file would be great! 1. get the resource.cpp of the Mod you're using; or debinarize the resource.bin with CoC-BinView 2a: in the resource.cpp either put the include-line (untested) 2b: or put the contents of the file coc_fed.pbo\fed.hpp at the end of your resource.cpp Don't forget to backup your unchanged resource.cpp, and use a Mod-directory (the resource.cpp resides in the Bin-directory of the Mod).

Of course people can have it the plug'n'play way: Include the FED-dialog into their resource.cpp; that way it is always loaded, and does not require to create a description.ext and mission directory. But it requires some basic config-editing. (in the meanwhile everyone in this community is some kind of modder, right?)

Hi, please look here: http://www.flashpoint1985.com/cgi-bin....l=tides EDIT: @Gnat You're right: The tides amplitude is exactly 5 meters, as you'll see in the code I linked.

Well, depending on how BIS implemented the PBO access, there wouldn't be a difference. If OFP rereads the PBO-header everytime a file is desired, then it will probably take longer. If OFP caches the offsets to every file, then there should be no difference between a 500MB an a 10MB file, because all irrelevant data is just skipped and only the desired file is read.

Hi, I've programmed my own PBO-loading routines, and I guess that BIS has done it in a similar manner: I'm getting a file descriptor to the PBO and I'm reading the header in. From the header you get the list and the length of the included files. From this you can calculate the offsets into the files, and map it to the filenames. Now every time you want to get a file from the PBO, you just check the filename and jump to the offset in the file and read on (or decompress). In my case, the PBO does not use any memory except the filename-offset-table. As BIS aren't amateurs they have it done in a similar or even better way.

Ejecting from the EF is done by pressing special keys (I don't know right now). The action-menu is anyway the worst choice for ejecting, BIS could have made...

It's already in ACES available (though its effect has yet to be scripted). (if one is not sure if a weapon is already available, one may browse through the ammo.hpp, or the P3D-directory in ACES.pbo (all models are in MLOD-format))

@gnat I found the reason why the bombs don't react at all. Here is a quick fix for the Bombs and Laser Guided Bombs: In the ammo.hpp, go into the class ACES_Mk84 and add <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> simulation=shotMissile; The LGBs behave right now like missiles and every LGB has the same damage values. Luckily I have preserved the original config, which modelled the warheads to GBU-version correctly. Please replace the following classes in the ammo.hpp <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class ACES_GBU10: ACES_MK84 { model="\aces\p3d\aces_gbu10rel.p3d"; proxyShape="\aces\p3d\aces_gbu10.p3d"; //(RKT) Paveway parameters - laser lock is on, and the bombs 'fly' irLock=0; laserLock=1; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; cost=4500; }; class ACES_GBU10I: ACES_BLU109 { model="\aces\p3d\aces_gbu10irel.p3d"; proxyShape="\aces\p3d\aces_gbu10i.p3d"; irLock=0; laserLock=1; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; class ACES_GBU12: ACES_MK82 { model="\aces\p3d\aces_gbu12rel.p3d"; proxyShape="\aces\p3d\aces_gbu12.p3d"; irLock=0; laserLock=1; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; class ACES_GBU15: ACES_GBU10 { model="\aces\p3d\aces_gbu15.p3d"; proxyShape="\aces\p3d\aces_gbu15.p3d"; }; class ACES_GBU16: ACES_MK83 { model="\aces\p3d\aces_gbu16rel.p3d"; proxyShape="\aces\p3d\aces_gbu16.p3d"; irLock=0; laserLock=1; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; class ACES_GBU27: ACES_GBU10I { //(RKT) Longer range GBU minRange=300; midRange=3000; maxRange=8000; model="\aces\p3d\aces_gbu24rel.p3d"; proxyShape="\aces\p3d\aces_gbu24.p3d"; maneuvrability=50; }; class ACES_GBU24: ACES_GBU27 { maneuvrability=40; }; class ACES_GBU38: ACES_MK82 { model="\aces\p3d\aces_gbu38.p3d"; proxyShape="\aces\p3d\aces_gbu38.p3d"; cost=600; //(RKT) JDAM parameters - iR lock is on, and the bombs 'fly' irLock=1; laserLock=0; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; class ACES_GBU32: ACES_MK83 { model="\aces\p3d\aces_gbu32.p3d"; proxyShape="\aces\p3d\aces_gbu32.p3d"; cost=1200; irLock=1; laserLock=0; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; class ACES_GBU31: ACES_MK84 { model="\aces\p3d\aces_gbu31mk84.p3d"; proxyShape="\aces\p3d\aces_gbu31mk84.p3d"; cost=2400; irLock=1; laserLock=0; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; class ACES_GBU31BLU109: ACES_BLU109 { model="\aces\p3d\aces_gbu31blu109.p3d"; proxyShape="\aces\p3d\aces_gbu31blu109.p3d"; cost=2800; irLock=1; laserLock=0; maneuvrability=35.0; sideAirFriction=0.1; maxControlRange=100000; }; The other possibility is to wait until Kikill uploads a new version. Cheers, Vektorboson

Shouldn't be a problem

Erm, Paveway II (GBU10,12,16) and Paveway III (GBU24,27) are already in ACES. I'll look into the Storm Shadow (I already made the Taurus, which is quite "similar"). Though both need a concept and some scripts that guide them to the target

Ah! Good to see! I thought there was still my unfinished model floating around... Â

Ah, Ok, thanks. Btw. it would be nice if people wrote down what missiles/rockets/MGs/bombs a.s.o. are missing or should be included into ACES. (For example: A GBU-15 is missing...)

Because it's the right thing to ask permission first. Â For making tutorials you don't need any permission at all. (and anyway, as for me, I am a little bit easier on that permission stuff (I think that hardrock thinks not much different)) Btw, what are MERs???

you don't need the "detected by" trigger if you can use the "knowsabout" command :-) It works pretty well most of the time. His point is that one needs either a trigger or a list of enemy units to use knowsabout at all. How should you be able to use knowsabout, if you don't have a list of units or at least one enemy unit? Meanwhile I too think there should be one "detected by"-Trigger per side.

Errr... It's all about disallowing stuff like "_x addScore -100000" foreach units _enemy Or short: eliminate every way of "cheating". What I imagine from such a thing is, that we have units that advance in an intelligent manner on the enemy's position, using suppressive fire, firing grenades on suspicious positions a.s.o. But you can't hold such a "contest" without a strict and exact ruleset.

If you only want to retexture them, but don't want to change the model, you can take a Hex-Editor (or any editor that supports binary files) and make a simple search&replace on the textures you want to replace. (for ODOL-files, that is!

My opinion is, that one should not use commands on enemy units that have an impact on their state/behaviour. So basically forbid any 'set'- and 'add'-commands on enemy units (including addScore   ) Regarding triggers: I'm against triggers, I think the units should act as autonomously as possible. You could overcome this limitation by using Hit- or Killed-EHs on your own units, and retrieve the enemy group units (but not using reveal on them!.

I like the idea of some sort of "RoboCup" with OFP-AI units Regarding rules, I would completely disallow using commands like setdammage, createVehicle/camCreate, addWeapon/addMagazine/*Cargo You have to create a very solid ruleset, as it is pretty easy to very experienced scripters overcome limitations or hide functionality... It even is not enough to look for forbidden commands, as you can obfuscate your code (OFP treats strings as code and code as strings). <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _snafu = ["t","e","v","c","l","a","r","h","i"] _foo = (_snafu select 3) + (_snafu select 6) + ... Thus you can create the string "createvehicle" just trough selecting and adding the elements from _snafu. Don't forget creative usage of the OFP-Preprocessor, where mostly only the modder-freaks know about all its commands and usage possibilities... So one rule should be like: Enemy units may only be killed by bullets/grenades that are fired from the rifles/launchers from AI driven units. Another thing you have to take into account is CPU-time; scripts can be quite expensive and you have to put some limitations, especially for functions, as they are blocking (take a while-loop for example). Anyway good luck; and if I find time, I'm going to participate Â

@cornhelium Well, I can tell you, why your script doesn't work... that's quite simple. The solution to your problem... is not very simple. Why it doesn't work: You can't pass local variables of a script to an eventhandler, check the following code: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _somevar = 0 _unit addEventHandler["FIRED",{ hint format["%1",_somevar] }] When _unit fires, you'll get good old "scalar bool...". Good luck with this information!

Well, that's what it is for, right? Just go ahead and use it Â

Yeah, happy birthday! Â

Though I have a homepage, there is no official site for my Mod, which is called CTW. The only "official" thing is the mapfact presentation (in German language), which you may get at my homepage and a thread at the mapfact forums (it's German, but feel free to ask in English). In short: CTW means "Conquer The World", and is a collection of tools to generate islands and missions; the whole point is strategy: Destroy power plants, and the enemy won't have current to use for his tank factories. Or destroy the tank factories itself... The effect won't be immediate; it will take some time until the enemy will run short of tanks/spare parts. Hopefully I'll find some time to put documentation on my page.

That M113 is carrying Hellfire-Missiles which are ATGMs, not SAMs.

There is no automatic way in OFP (in ArmA you'll be able to define dialogs/resources in addons). The only way in OFP is, as you see in Addons like Hudson's/Pennywise or BWMod-Fennek. They provide a file in their PBOs that is included into the description.ext. The end user has to create a mission and a description.ext with an include-directive: #include <ADDON\resource.h>

IIRC the problem is that you are using Win98/ME with nomap; fwatch assumes by using nomap, that you have win2000/xp and uses so called pipes (that were not available in 98/ME) for communicating with OFP.