vektorboson

As always regarding the COC UA-problem in CWA, may I direct you to my semi-official update: http://forums.bistudio.com/showthread.php?48537-Chain-of-Command-Unified-Artillery-1-1&p=1973165&viewfull=1#post1973165

You all know the one problem we have with our hiddenSelections and custom textures which can be set through setObjectTexture: Blurry textures. One solution is: create small faces with all possible textures (with exception of user made) and have them all loaded with the model. Disadvantages: - Memory load (you have to load all textures even those not needed) - blurry custom user textures My solution is another: Dialogs!!! Yes, you read right, dialogs. Advantage: - No blurry custom user textures - only textures are loaded, that you need Disadvantage: - User has to setup a description.ext (possible solution: use one of the available dialogs that are defined in the resource.bin; then user doesn't have to do anything) The solution: You need a dialog with a Image control and a script that creates that dialog and sets the texture on your unit. The dialog: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class scfPreloadTextures {  idd = -1;  movingEnable = 0;  objects[] = {};  controls[] = {};  controlsBackground[] = { image };  class image  {   idc = 100;   x=0; y=0; w=0; h=0;   text = "";   type = 0; style = 48;   colorBackground[] = {0,0,0,0}; colorText[] = {0,0,0,0};   font = "courierNewB64";   sizeEx = 0.02;  }; }; The script <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _ok = createDialog "scfPreloadTextures" ctrlSetText [100, "path to texture"] ~0.5 my_unit setObjectTexture [id_of_hiddenselection, "path to texture"] closeDialog 0 I tested this with my F-117's map, and it worked very nice. I noticed that you have to preload the texture in the dialog and set the objectTexture after this. Also you need a small time gap between creation and destruction of the dialog, because the texture is then not loaded. I haven't made any further tests, but this should give some people some inspiration to research any further.

In case you are using Arma:CWA instead of the original OFP:Resistance, you need my hotfix for COC UA: http://forums.bistudio.com/showpost.php?p=1973165&postcount=215

You could make weapon boxes additionally to the ammo boxes; you could make for example a "rifle box", a "MG box" and perhaps an "AT-Launcher box".

The devil is in the detail: You mention a metal golf ball which doesn't have the same RCS as a "normal" golf ball. Since the planes also use radar absorbing coating the RCS is also frequency dependent; I've read (I think on SimHQ in the SAM-simulator-thread) about the shooting down of the F-117 in Serbia where they used a longer-wave radar band, assuming those wavelengths would reflect from the Nighthawk's interior, to track its path. So it could be indeed that the current Stealth fighters have a lower RCS for some radar frequencies, and the F-117 for some other. It all depends on the equipment the enemy is using.

Using a special tool for changing the texture path is Ok if you have the MLOD. But in case he has an ODOL-P3D and wants only to adjust the texture paths (not changing the model in any way) the best way is indeed to use a Hex Editor.

WrpTool (and OdolEx) have problems decoding named selections correctly. You can either try to remove some (unnecessary) selections until WrpTool reads the binarized P3d correctly; or you do the following: You copy your offending P3D and remove all selections within it and use this binarized version in WrpTool.

That's what radio "weapons" are for; if you have the BAS-delta/rangers you can use the BAS_Satcom or Laser's US Weapons pack the PRC-117. There are some more radio classes which can be used. Don't forget to use that COC-logic that enables the radio weapons. It is also possible to extend the usable radio weapons; it should be somewhere in the UA documentation.

The next one is getworld == "Noe" which sets the gridsize to a bogus number. There are many more, like checking for configfile, changing saveConfig, a.s.o. As I've said, I'd expect there was somewhere an obfuscated one, but unless you are using the very small subset of VBS1-commands that CWA implements, we could be lucky and I did get them all. Since you suggest 1.11 as the version number (though you probably know version numbers are not decimal numbers) I'll use it. EDIT: Found another one which creates a random nuke, though I need to backtrace it :) ---------- Post added at 18:32 ---------- Previous post was at 16:42 ---------- The hotfix is available here: https://docs.google.com/leaf?id=0BwnG8i15OvIpYzJhYTFhYzgtN2IyYi00NjcxLWJmNTUtODczNTM0MmFlMTg0&hl=en_US Please report any bugs you encounter.

I think I found them all, that is if you didn't put any obfuscated ones in. I've just grepped for every VBS1-scripting command in the coc_arty.pbo and removed the offending lines if they were doing something malicious or were simply useless. So, I'd be happy if I'd get permission to release a hotfix (updated coc_arty.pbo), until you workout a 'clean' version. Hopefully my hotfix is not BIS-style :D Right now UA 1.1 is useless anyway, so people need to either use UA 1.0 (which is working) or they apply the fixes I suggested earlier in this thread.

The following lines need to be removed from their respective files: coc_arty\scripts\initclient.sqs line 8: player addeventhandler ["AnimChanged", {player setpos [(getpos player select 0)+ (random 10) - 5), (getpos player select 1)+ (random 10) - 5), random 3]}] line 163: if (getworld == "Noe") then {CoCGridSize = -512} else {CoCGridSize = -528}; coc_arty\scripts\initserver.sqs line 15: ?IsServer or (!IsServer):exit There may be more checks for VBS1 scripting commands, I found for example "configfile". This doesn't affect CWA though since this scripting command does not exist. Nevertheless, people may by accident use variables which have the same name as some VBS1-command or -variable for which UA checks, thus breaking UA with people not knowing why. Especially the isServer check, which i can imagine people have used as a variable name. Of course, as already mentioned, there may be more checks whether UA is running under VBS1; and they may be even obfuscated by using "format" or string concatenation to mask the check so it isn't found by using a simple utility like grep.

My apologies, I just tried it (I thought I already tried it...). Anyway, it seems that the CoC-guys have rigged UA 1.1 to not work with CWA 1.99 (I guess that they built in errors, so UA 1.1 does not work in VBS1). Anyway, they didn't expect that there might be some day a patch/update to our OFP which includes new scripting commands (like isServer) or event handlers (like "animchanged"). So, it's time to look through all scripts and check for those deliberate changes to make UA unusable.

As I said, you need to take the Obelisk from the Logic-side; in your test mission you're using the CoC_ObeliskW from the west-side.

Are you sure you're placing the correct Obelisk? Perhaps you are placing an empty Obelisk (or West/East). You need to place an Obelisk from the "Logic"-side. In case this doesn't solve your problem, could you copy&paste your example mission.sqm?

A few things worth trying: Keep the Uppercase filename "Novajev.pbo" since in the config "\Novajev\novajev.wrp" is referenced. Or alternatively edit the config to use lowercase filepath "\novajev\novajev.wrp". OFP/CWA don't list an island if the engine can't find the WRP belonging to the island class; in the case of linux, which has case sensitive paths, the check probably fails for different cases.

Since no one has asked yet: What is that "D3D8 34.90 Mono" in the upper left corner? Do you still have those problems when disabling it?

Has anyone the ECL Safe-addon that contains the ECL_documents.pbo?

I have compared the 1.96 and the 1.99 config; they are virtually identical. The only differences are in lower/uppercase for the enums and some numbers are integers instead of floating point (like 1 instead of 1.0). You should be fine with any 1.96-based config.

I guess this is a documentation mistake: There is no createMarker-function at all (and I guess there won't be, would be nice anyway). I guess the enum-values in the config.bin and resource.bin are wrong and we therefore have those command menu-bugs (and pistol-bug). Other than this: The loading performance seems to have improved, it starts almost instantly (even vanilla OFP:R doesn't start that fast) :) EDIT: Further testing: "getMove" does not exist, but "AnimChanged"-event handler does work.

First of all: Thanks BIS. Now back to business: I've downloaded from this link: http://forums.bistudio.com/showthread.php?p=1962672#post1962672 There's a bug in the radio menu, please see here: http://forums.bistudio.com/showthread.php?p=1962727#post1962727

Try this, the error message tells you the maximum number of elements: A=[]; A set[0, A]

Hello, I've got a bug report (at least for my user account), I've already posted in the "Ask a moderator"-thread:

Well, I now know that the board uses 16bit unsigned integers... Perhaps I'll have 0 notifications if you send me a PM :D

I've got an error for my user account; in my upper right corner it shows me: Your Notifications: 65,535 Well, apparently I don't have that many notifications pending :)

Check the Geometry-LOD; in case you used an older version of OdolEx, the Geometry-LOD does not have mass (or even worse: the components are not closed!).