vektorboson

@Synide What you are talking about is the context.bin; the convert.bin is a 0-byte file that was used to signal to DePBO 1.5 that the contents of the PBO should not be extracted. This was meant as some kind of 'content protection', which was very easy to hack away with a hex editor. @arkengel Look in the main config.bin as Macser suggested (should be CSLA\bin\config.bin).

Well, I don't believe that your program does not support alpha channel. I don't know about the terminology in your image-editor, but try this: Create from your layer (or object) containing the marker a 'mask' (or selection) and save a TGA (perhaps you are asked for 24 or 32 bits, go for 32, or RGBA). Then try to convert it and look whether it has an alpha channel. (if you didn't use layers, then you must create the mask manually, perhaps with the magic wand tool)

Try to d/l again. OFP.info had a corrupt file which they have replaced...and no PW required. I can't even access www.ofp.info as I just get a page saying the name expired Dec. 31. Has it moved to a new address? Use this: http://ofp.gamepark.cz/

For HVTs, they are marked correctly when 'found' by intel. But it seems that HVTs that are found by soldiers ('tactical intel' aren't marked sometimes (I think only the first one). Also, sometimes an enemy group is marked by that NATO marker, sometimes not (most of the time not). Some suggestions: - use the NATO marker for enemy infantry (diamond shape instead of rectangle), like CE does it - groups should report enemy groups (position and strength) example: "Contact at AA00, counting 4 Infantry, 1 APC. Out." - Clickable group markers: clicking on a unit's marker automatically selects the unit

I'm using the low-addon-template (PBO-version): Errors: - Missing addon hunter - I get no intel points at all (stays at 0) - first found HVT is marked on map (through tactical intel), any further HVTs are not marked Also, enemy groups are sometimes marked on map, sometimes not (With that big enemy infantry group marker). Also I think, that gathering lots of logistics officers should not scale in a linear manner. Right now it seems, you just 'build' many logistic officers and then it's hard to run out of logistic points. Perhaps every group (based on type) should take away logistic points. A tank group requires more logistic points to run than an infantry group. But then, it's always nice to keep it simple. EDIT: Looking into the scripts, Intel does not accumulate for every version.

Awesome!

I like Llauma's head, but I strongly dislike facetex2... Why don't you take HYK's face textures, which are based on BIS' faces?

Look under East German Soldier http://ofp.gamepark.cz/index.p....page=21 Those were made by UCE and are Pre-Resistance, so Handguns don't show on this units. I think it included a retextured AK74 AK74N).

I have made a German M109A3: http://www.flashpoint1985.com/cgi-bin....t=58700 The major differences between the M109A3 G A2 and the US A2-A5 are the front- and backlights, the MG3 vs M2, the baskets/smoke throwers. Also the back side of the model is not finished, and of course the textures need to be changed. @[ASA]ODEN There is a very big difference between DKMs M109A6 Paladin and the M109A2-A5; the turret is completely different in comparison to the older M109s.

That's completely wrong! The Chaparral is a modified AIM-9 Sidewinder mounted on a modified M548-chassis! But let's see, perhaps there is something in the works... Â

I'd like to see the "Russian"-"Europe"-conflict, but not '08. I'd like to see the conflict in '85. Basically, almost everything is there for a "Germany 85"-scenario for OFP. But since there wasn't this option, I voted US-Soviet '85.

PzGrenadier probably meant this one: http://ofp.gamepark.cz/index.php?showthis=8101

If you like a Chaparral, you can take my M548, remove the mine thrower and MG3, put a launcher on it, et voila, you have a chaparral. For the M548 look here, it's part of the German artillery pack: http://www.flashpoint1985.com/cgi-bin....t=58700 MLODs are available there, too. Looking forward to the Chaparral

Well, that's exactly what I was testing; and simply spoken, Kubuntu is nothing more than the KDE-packages for Ubuntu, which is GNOME-centric (no pun intended).

Indeed? When has that been? I found Ubuntu to be quite convenient since version 6.10, at least since the last 7.04. I guess you should try the new version once again when you get to it. Well, I wanted to try Ubuntu because of their nice Online-update capabilities (apt-get, synaptic). It was definitely less than 2 years ago, when I tried it the first time. The X-Server didn't start; then I tried it the second time when a new version came out. The X-server started, but KDE did not. After I installed ATI-drivers, the X-Server didn't start. Well, then I installed openSUSE, where everything worked out of the box. After I installed ATI-drivers, I had also HW-accelerated OpenGL, which I need for University. Also, I've seen many distributions in use at my University. The only distribution where KDE worked without problems was, surprise surprise, SUSE. Now, I won't try Ubuntu, because it has really no benefit over SUSE for me. Especially since Ubuntu is GNOME-centric, and I really really dislike GNOME.

I don't get, what that Ubuntu-fuss is all about; the times I tried Ubuntu it didn't work for me: It even didn't start the X-Server at all (the other time it crashed at login). Despite all the SuSE-flaming, I'm an openSUSE/KDE-user.

1. Solution: Take all double sided faces and remove one side. Then copy and paste those and reverse normals. DO NOT MERGE VERTICES! 2. Solution: I don't know if this works 100%: Select all Vertices that make up the double sided faces. Press 'U' for sharp edges, then F5 for recalculate normals. Of course the 2. solution is easier, and you may test this, before you try the first. Well thats the basic problem. No we do not. A normal for a triangle is calculated that way: Take one of the vertices as the base. From this base calculate the two vectors to the other two vertices. Now calculate the cross product of those two vectors and you have the 'sharp' normal (of course you have to normalize that vector). If the base vertex is shared between more faces, and you have smooth edges around that vertex, then you calculate the average of all those 'sharp' normals. And in case of two exactly opposing normals, you get a (0/0/0) normal for smooth edges.

I hope you understand how normals are calculated. There are two edge types: Smooth edges and sharp edges. The normals are calculated, depending on what edges a Quad/Triangle has. Basically: The normals for the vertices that are on a smooth edge are the average of the normals in case of sharp edges. Let's assume you have a _double sided_ quad, that has smooth edges. Now a double sided Quad has the normal (1,0,0) on one side, and the normal (-1,0,0) on the other side. Now the average of (1,0,0) and (-1,0,0) is? Right, it's (0,0,0). So the solution is either: Detach all vertices for double sided faces, so that both sides are independent of each other; or make sharp edges for double sided faces.

There you have it! ArmA is looking for the proxy-models in data3d, which would data3d/SAXHORN.p3d In OFP you would have to define a "class Proxysaxhorn" in the CfgNonAIVehicles, pointing to your saxhorn model. I hope someone can confirm, that this is the same for ArmA.

There you have it! ArmA is looking for the proxy-models in data3d, which would data3d/SAXHORN.p3d In OFP you would have to define a "class Proxysaxhorn" in the CfgNonAIVehicles, pointing to your saxhorn model. I hope someone can confirm, that this is the same for ArmA.

Could you show the whole config? Do you use any proxies in your model that have the selection name proxy:saxhorn.01 ?

Could you show the whole config? Do you use any proxies in your model that have the selection name proxy:saxhorn.01 ?

Well, seems that few people seen this: http://community.bistudio.com/wiki/GateBuilder It seems promising though it's Alpha status.

That's when the map is bigger as the Zoom levels in the island's config. FLK-team has to add or adjust a zoom-level in the config (see WrpTool-Example-Configs). I fixed the problem with my island without changing my config. I believe it is caused by some kind of progressive corruption of the heightfield at/beyond the edges of the map and the OFP map's ability to draw contour lines. Can anybody confirm the problem? I don't need to go to the lower left to have OFP CTD; just zoom out enough.

That's when the map is bigger as the Zoom levels in the island's config. FLK-team has to add or adjust a zoom-level in the config (see WrpTool-Example-Configs).