vektorboson

Thanks! I hope you didn't forget the CH-47! Â

Hi guys, sorry for lack of progress support, therefore this post. This project is really huge, and by huge, I mean it has already 430MB raw unoptimized data. I need to make some statistics about number of models, textures and config classes to give you an idea what this is all about. As I have to handle this all in some way, I've written and I'm still writing tools that help me in handling this. This is an excerpt from the various tools that will help me; I'll just give you the output of it: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> Trying to read C:\ofp\oxygen\scf_weap_3d\scf_beretta92_sd_empty.p3d ------------------ path: scf_weap\m9\silencer.paa (C:\ofp\oxygen\scf_weap\m9\silencer.paa)     max U- and V-distance: 0.651059, 0.549658     min/max U: 0.018201, 0.982710     min/max V: 0.073962, 0.925253     alpha flag: False     width/height: 512, 64     pixel data format: DXT1     physical area: 0.085680     texture area usage: 82.11% Tags: excessive width/height ratio, mergeable ------------------ path: data\blck_sum.pac (C:\ofp\oxygen\data\blck_sum.pac)     max U- and V-distance: 0.000000, 0.000000     min/max U: 0.000000, 0.000000     min/max V: 0.000000, 0.000000     alpha flag: False     width/height: 32, 32     pixel data format: DXT1     physical area: 0.003660     texture area usage: 0.00% Tags: mergeable ------------------ path: scf_weap\m9\m9_3.paa (C:\ofp\oxygen\scf_weap\m9\m9_3.paa)     max U- and V-distance: 0.531232, 0.986764     min/max U: 0.467959, 0.999191     min/max V: 0.003236, 0.990000     alpha flag: True     width/height: 256, 128     pixel data format: RGBA4444     physical area: 0.243319     texture area usage: 52.42% Tags: mergeable ------------------ path: scf_weap\m9\slide.pac (C:\ofp\oxygen\scf_weap\m9\slide.pac)     max U- and V-distance: 0.871094, 0.103516     min/max U: 0.009766, 0.993704     min/max V: 0.404207, 1.669922     alpha flag: False     width/height: 512, 512     pixel data format: DXT1     physical area: 0.095451     texture area usage: 124.54% Tags: vertical repeat, mergeable, height-duplication ------------------ path: scf_weap\m9\frame.pac (C:\ofp\oxygen\scf_weap\m9\frame.pac)     max U- and V-distance: 0.568359, 0.541016     min/max U: 0.009766, 0.992188     min/max V: 1.011719, 1.994141     alpha flag: False     width/height: 512, 512     pixel data format: DXT1     physical area: 0.109174     texture area usage: 96.52% Tags: vertical repeat, mergeable, height-duplication ------------------ path: scf_weap\m9\parts.pac (C:\ofp\oxygen\scf_weap\m9\parts.pac)     max U- and V-distance: 0.339844, 0.833984     min/max U: 0.005859, 0.990234     min/max V: 1.005859, 1.996094     alpha flag: False     width/height: 512, 512     pixel data format: DXT1     physical area: 0.047466     texture area usage: 97.48% Tags: vertical repeat, mergeable, height-duplication ------------------ This tool hopefully becomes an automatic texture optimizer, that crops/resizes/merges textures. The data you see is collected from SJB's M9 Beretta which I may use for my Mod. Most of the data is self-explaining. The tags are used for 'tagging' a texture; so when it says 'mergeable, height-duplication', this means that a texture is mergeable if I tile the texture vertically once. (In the example output the last texture doesn't need duplication if I translate the V-coordinate by -1). But not enough, the auto-merger will be able to work on several models (this will be called an 'ensemble' ). This makes sense for weapons with a few variants, or for models that are supposed to occur on screen at the same time.

afaik the HK69 was in use with the West German army in the 80s. Was it not called the G3TGS? Â HK69 is a standalone grenade pistol (which was/is used by the BW). The G3TGS (G3+HK79) wasn't issued in the BW.

In my time at the BW (2000-2001) I didn't see any G3 with that foregrip without 'holes', so I assume there weren't many if at all. So I'd say give the BW-soldiers the 'stock' G3s and you're safe. I'd also give the German snipers the G3 ZF (in case you planned to give them the G3 SG1). One more thing: I thing you need to change the color a bit; the hue doesn't match what the majority of G3s looked like (at least for me). It needs to be more olive/yellowish, not 'leafish' green. (The initial BWMOD for OFP had the color right). The G3A3 on this site pretty much has the 'right' green: http://home.planet.nl/~rouw0062/dcdbase/fa_ar_g3.htm

I'd say rather: ODOLEx does not recreate this info. But yes, the ODOL-files hold different information than MLODs. For example ODOL lacks the selected/hidden vertices/faces, which really is only important for editing. But more, ODOL doesn't have explicit information about 'sharp edges', which leads to the lighting problems. But it has for sure implicit information about the sharp edges, and I suggest that it is indeed possible to recreate information about sharp edges, probably not 100%, but with acceptable results (of course assuming that the original author applied sharp edges at all). First possibility is to find out how O2 calculates the normals; then you find out how those normals differ when they're on a sharp edge or not. Now you check for every face what the most probable configuration for their normals is: sharp edges or not.

Ok, I'll try my take at it; as for information: I implemented a helicopter simulation in C++ as an university project, so I had two problems to master: Drawing a wide landscape with > 20km view distance (accomplished, though with a few visual artifacts) and creating believable aerodynamics for a helicopter (err, somewhat accomplished). The aerodynamics were a very hard task and I can't say that I am pleased with the result I delivered. I used the simple Euler-Integration scheme, and I used quaternions to store the orientation of the chopper (it's cheap easy to turn quaternions back into rotation quaternions, as opposed to matrices). I can't say I had problems with numerical stability aside from sloppy/wrong equations and programming. The real hard problem was creating the coefficients (drag, inertia, a.s.o.). They also need to be different for every direction/axis. Because of lack of time, I didn't create physically 'correct' turning, and I started to cheat by creating some weird type of 'centripetal force' I applied in some very weird way. It wasn't nice, but it was acceptable. I compared my result to the Bo-105 handling from open source simulator FlightGear, and was quite pleased what I accomplished in less than one week of coding. But you shouldn't forget: I had full control over the engine. I could control velocity, position, orientation, rotation of the helicopter, and I decided when and how they were changed. Now, as I read, you try to make your flight dynamics in OFP. Where you can only set/get the velocity and azimut. So to control orientation you try this very crazy hack through impact spheres by transferring momentum. Well, as you probably know, OFP does violate momemtum preservation. Throwing for example grenades on the ground could sky-rocket them into heavens; so you absolutely cannot rely on OFP simulating elastic collision, and thus your hack of impact spheres won't work. It will create system explosions. Beside this: You need the orientation of the jet to apply torque at the correct position. Ok, there are hacks by using the drop-command (which transforms the relative position of the particles with the object's matrix); but this won't be satisfaction. Ok, you want it to do in ArmA rather than in OFP since you can control the orientation in ArmA. You still got the problem to fight against the built-in dynamics engine, let's put this aside for now. But forget about the clever trick of impact spheres. You said you want to make a more realistic mass distribution; the mass distribution will be abstracted into the inertia tensor anyway. So either you calculate it from the mass distribution (parse the P3D, read in the vertices along with their mass value, calculate the inertia tensor and COG), or you set the tensor directly. No need for impact spheres: You have the information you need to apply force/torque correctly. No need for a man-in-the-middle. The other thing you want to do: Calculating lift/drag from the model; AFAIK commercial simulator X-Plane calculates those coefficients from the models. Don't know about the others, but presumably it is a non-trivial thing. I'd say: Find the coefficients by trial-error instead; if you really want to find them from the model, it must satisfy many constraints, so you can apply an algorithm that is supposed to provide reasonable values and to finish calculating sometime. Good luck!

You are using the most recent Oxygen, the version that was released for ArmA-modding. The new Oxygen has a different file format compared to the OFP Oxygen. You need to export to the 'P3D old version'; as I remember BIS removed this possibility in the newer versions. So if you don't have the menu-entry (File->export->P3D old version), you need to download the first Oxygen release for ArmA. Crap... Where do I get it? I can't find it =S http://www.flashpoint1985.com/cgi-bin....t=67066

You are using the most recent Oxygen, the version that was released for ArmA-modding. The new Oxygen has a different file format compared to the OFP Oxygen. You need to export to the 'P3D old version'; as I remember BIS removed this possibility in the newer versions. So if you don't have the menu-entry (File->export->P3D old version), you need to download the first Oxygen release for ArmA.

Select a 'face' (triangle or quad) from the hand and hit 'e'-key. You've got now a list showing the path to the texture for every selected poly.

It's not binarized! Binarized configs begin with the byte 0; this file begins with byte 0xff (= 255), which shows clearly that this is compressed data (another hint are binary values inbetween strings). As Synide said, get Eliteness, it's IMHO the best tool for PBOs.

Here you are: http://ofp.gamepark.cz/_hosted/inquisitor/

I'd love to see them, too. But as long as I'm the only one working on this mod, and I don't see anyone in the community working on or releasing British fitting the 80s, I see no chance. So, who volunteers to do the Brits?

Well, they didn't have flecktarn back in the 80s (some units may have experimented with early flecktarn pattern). But it was all olive drab back then (uniforms and vehicles); of course with steel pots, they were still used in 2000 (I was issued a steel pot)! I don't know whether I'll do the Bundeswehr at all; first come the US and GDR/SU.

Hehe, thanks for that offer; I think it's enough if you make some good photos from many angles of the equipment. Just send them to vektorboson@gmx.de if you don't want to post them here. (I guess the Project '85 for ArmA would be glad if they could use those pictures, too?) That's what I imagined; the propaganda videos are pretty hardcore if I think about my basic training I've got permission from RHS, so I'll look into it, didn't think about using the tankers as a base for the paras, though. As I remember they have moved to ArmA, though I can't check as I've lost the link. It was also the only german army that never fought a war! EDIT: Never mind

Yep, it's still alive. I'm a little bit unmotivated, but I'm still working on it. Though, if I do the Fallschirmjäger, the only difference between them and regular infantry will be the helmet. As I've read into the history of the NVA, it indeed seems, that they could've taken over West Germany easily by pure firepower and determinance. But the other thing is tactical/creative thinking, where the NVA pretty much lacked. This was a big problem with integrating (few) NVA officers into the Bundeswehr, as they thought lower ranks were not allowed to think for themselves (and make suggestions to higher ranks).

Problem is, that most reference sheets didn't say from where to where the height applies. Depending on how I measure the height, my M113 is either too low, or too high. And that's without the gunner's open hatch. Of course, the hull is much lower compared to BIS' M113, since I rebuild the floor (the floor is at a higher position). So the tracks+wheels moved down in regards to the floor; but in the game they (tracks/wheels) move up slightly again. And then there is the problem of "ingame realism" vs "reallife realism". In OFP all soldiers are of the same height, which does not fit the APCs reallife interior. The extreme example is the BMP, which is scaled in such a way, that OFP soldiers fit into its interior. A bigger issue for my mod are the FDF BMDs I'm using; the relation of the interior and exterior is simply impossible. I cannot make the units 100% "realistic" and perfect to every inch/mm. Â

Exactly

That's because the mission.sqm is in a binarized form; you can debinarize it with a tool like Eliteness: http://andrew.nf/ofp/tools/ You need to 'UnRap' (or was it 'DeRap' the mission.sqm. For further reading: http://community.bistudio.com/wiki/raP_File_Format_-_OFP

Hopefully I can continue to work on this mod in a week again. But beside this, there are no show-worthy news.

No, it's not possible; it's hardcoded in the EXE.

I already asked Zerg for the M48 (and the M35 truck as well), but I didn't get any response yet. The M48 (=> M48A3G, with a 105mm gun) was indeed used by the West Germans, and I consider to make it for the West Germans (but not for the US). I'm updating the list of units in the first post, so you can look in there, what's planned and considered. Of course I'm happy for any information relating the 1980s, no matter how unimportant it is. @cjuraman That link is known, but don't let that discourage you from posting further links. I'm thankful for anyone who does research for me! Â

Sorry, but I don't understand what you exactly want? You can provide me with a download link, and I'll take a look on those models; don't forget to mention whom I have to give credit. If they're fine, I'll finish them and include them into my mod. If not, then I'm going on with what I am already doing: Doing them myself, if I don't get permission, or they simply don't exist for OFP. I'm definitely not going to postpone work on models because someone tells me having models I need for my mod, and in the end I'm waiting for a indefinite time for them. EDIT: I hope this didn't sound to harsh; I'm in a bad mood right now, having to finish a university project! Â As a sidenote: M113A2, M113A2 ambulance and M163A2 Vulcan are finished. IPM1 needs better LODs yet...

It's better if you release those (unfinished) models instead of just telling about them. Release them as Open Source; document who has to be credited. There's no benefit for anybody by telling what huge stack of unreleased addons you have on your HD.

So, rather something like this? No; more probable is a M88A1 recovery vehicle. If there already exists a released M88A1, I'll include it. Otherwise it'll be on the 'for-later-list'. This was already written in the first post; the West German stuff comes later. I want to finish the East German, Soviet and US first.

There is a CH-46 in the Jungle Fever-Mod. Problem is, it needs to be retextured, so it fits your timeframe.