beedee

Hello, in the last year I reworked the model a lot. I also created many gizmo mapped textures for it; unfortunately, each time when I got new insights from reference drawings and photos I made the according changes to the model mesh, which means I had to redo the textures again. The MF1 has 3070 vertices at the moment but a lot of eyecandy, like auxiliary intake doors and intake cones, first stage vane, some engine nozzle and flame animation steps from idle to full afterburner, full set of flaps, slats and spoilers, airbrakes and so on. However, RL will keep me from doing any big steps this year. Here's a couple of WIP pics: MF1 with one of my latest texture mappings And here the "mapping" textures from above, with some cheap camo colour over it (With OFrP pilot and roundels borrowed from Footmunch's F-16): F.1CT bomb truck with driver (first stage compressor vane visible) I forgot to colour the tailplane... Hard turn after a touch-and-go manoeuvre, disengaging afterburner, airbrakes full, flaps set to 60%

Hey Ironsight, better via PM.

I've had exactly the same symptoms with an addon of mine. My addon worked fine before, but after some modifications in O2, OFP crashed to desktop whenever I switched views from the initial inside view to the outside view. I found out that I had deleted parts of the model mesh in LOD 0, (and what I think is important) >>which were part of natively game engine treated "Named Selections"<< (in my case levy/pravy predni); these parts of the mesh would work ingame just by their sheer presence. This deletion resulted in orphaned named selection entries in LOD 0 (containing no vertices) which might have led to the CTDs. In order to not have to go through the entire list of named selections and check whether it contains vertices or not, I created an empty view LOD ("999" for example), Strg+A-copied the entire mesh from the crappy LOD 0 and pasted it into LOD 999. This step eliminates the orphaned named selections effectively, as copying is performed on vertex basis and named selections are only properties of the respective (existing! ) vertices. I then deleted the old crappy LOD 0 and renamed LOD 999, which contained the cleaned model, to LOD 0 again. Hope this will work with your models too! If not, you might repeat this procedure for every LOD in the p3d file, including geometry and memory LODs too. (edit: linguistic cosmetics)

make sure that your source image dimensions are multiples of 2; for example 128x128 or 256x256. *.tga-images should have 32bit color depth (in photoshop terminology) or 24bit + alpha channel (paintshop pro), which is the same. To create a simple alpha channel in paintshop pro press [strg]-[a] and select "save to alpha channel" in the menu "selections" and confirm [OK], [OK]. (technically, the alpha channel is just an 8bit greyscale layer used as a mask for opacity, which paintshop's "select" function sets to "pure white 255" - which means fully opaque). For transparent textures select only the visible parts in the image and save them to alpha. then save the image and convert it with TexView as described. edit: llauma, you beat me a couple of minutes!

I made my >car-class< BTR-80 APC swim via canFloat=1;, but AI car-drivers seem to be exceptionally hydrophobic. At first they enter the water without problems, but somewhen refuse to go either back or forth (sometimes just 30 meters off the shore). This behaviour might be optimized to some degree by different config settings, but that does not hit the core problem: Â As changing seats is not implemented for car-class vehicles by default, I had to take care that the player as a gunner or cargo can never get stuck in the open sea as a sitting duck. Imagine: you can't switch to the driver position, you can't get out as you can't swim (and most frustrating of all, you can't even make that denier feel really, really sorry except by [F2]-[4]-[1] )... My solution was to script and code the missing seat-switching actions for car-class vehicles. It works, but it is not 100% "waterproof" (nice wordplay!? ). I defined these UserActions in the cfgVehicles-section: and BDE_btr80_action-switchposition.sqs: And here's my problem: These actions should only be accessible by the player himself. But under some circumstances you can even order AI soldiers in other BTRs from your group to perform these UserActions via 6-x-x . But the results are unpredictable then; seems as if "my" BTR and the second one get mixed up anywhere in the script or the config-conditions. Second question, how could I modify the config-conditions so that a player with lower ranks can not switch to a seat occupied by a >human< player with higher ranks in a MP game? Perhaps someone could find and fix the bugs here? (Be assured I've tried alot, but unsuccessful). Thank you!

I did it this way: init-eventhandler script: BDE_btr80_swimming.sqs-script: btw, for my BTR I've set animation time to 1.2 seconds in the config. Too short animation times make the vehicle jump up when entering the shore, and with too long times it looks like the vehicle is partly dug in the sand for a moment. Adjust if necessery.

FM, from my lousy memory I think you're right; I believe I've tested my BTR with a >tracked< APC-vehicle class once, and I think it didn't show the mysterious (-1)m barrier if my memory is right. For my wheeled APC I didn't follow this approach any further though, because IMO it looked and behaved too strange for a wheeled vehicle. Just from the >wheeled< vehicle in GalComT's avatar and his banner I assumed his problem was with a >wheeled<, car-class APC?!

It seems to me that >floating-enabled< wheeled land vehicles (edit: =car-class) can only sink (with their landcontact vertices) to a layer which is located 1.0 meter below the water surface. These vehicles stand on the vertices "levy/pravy xxxi tlumic" in the "LandContact"-LOD. If you put an animation to these vertices, which raises them in order to let the vehicle sink deeper when in the water (define the animations in config.cpp and write a script which determines when the vehicle is going into the water), you unfortunately partly cut the hard coded animations (for better terrain following capabilities) off from the wheels. The smooth contact and collision detection with the ground is then no longer determined by these "tlumic"-points, but directly from the wheel geometry (levy/pravy predni/dalsi/prostredni/zadni) in the visible LODs (0.00 etc.) which makes them a little bumpy. Most visible annoyance is that they sometimes lift themselves a little above the ground, as if there is an invisible bump on the ground which they are rolling over. This can be overcome partly by very intense fine tuning of the config (damperSize [spring travel, in meters] and damperForce [higher=softer]), and different distances of the wheel geometries and landcontact points from the chassis (see below). It does not help to reposition the entire model relative to the origin in O2. Begin with creating the wheels in >maximum< elongated suspension position and place the (animated) LandContact points in LC-LOD a little below the expected position under load from the chassis, as you have to consider that the gear additionally sinks down in the springs. Apparently, the vehicle still stands and springs on the land-contact points, while the wheels (which are maximum elongated in the pbo) seem to be weightless or at least do not obey DamperForce anymore. You have to reposition them separately. Adjust the behavior of chassis, landcontact and wheels via damperForce in the config and their relative positions in the pbo until you are satisfied. For the relative positions of chassis, wheels and LC-points you might refer to this image: http://www.tacticalblunder.com/~beedee/BTR/BTRlandcontact.jpg This one has 13600 mass (in pbo) and config settings of damperSize = 0.18; and damperForce = 24; Edit: Oh, and it works: http://www.tacticalblunder.com/~beedee/BTR/BTRwater.jpg

At the moment my job keeps me rather busy. In my little spare time I tried to improve the flight model and AI behaviour (results to be added to ACES), so not much 'visible' progress yet, sorry.

Hm, not exactly. "V" (or "5") was just a marketing designation by Dassault. Technically a "5" is just another version of the Mirage IIIE airframe. Originally, Mirage 5s were stripped down versions of the IIIE after Israeli specifications for use under middle-east weather conditions. There was no need for those sophisticated and expensive all-weather avionics of the "european" IIIE versions. First versions of the "5" even had no radar and only simplified avionics, which cut down maintenance time from 35 to just 15 hours per flying hour (F-4 Phantom 50 hours, F-104 Starfighter 40 hours!). The avionics compartment behind the cockpit in the long IIIE-fuselage (apart from engine and radar biggest structural change from IIIC to IIIE) was used for another fuel tank to increase range. Also two additional hardpoints were added under the aft fuselage to utilize more of the high lift potential of the delta wings. After the French weapons embargo, Israel managed to get the blueprints, so they were able to manufacture copies of the M5s themselves. These copies got the designation Nesher (and Dagger for export) and in the course of time were upgraded by israeli/american avionics. Due to the french embargo Israel almost completely shifted to american technology. In the early 70ies IAI designed a successor for the aging Mirage IIICJ-5-Nesher fleet -the Kfir- as a total conversion. In general it was a Mirage IIIE/5/Nesher airframe (which are identical indeed) equipped with a stronger american General Electric J79-GE-17 engine, saw-toothed leading edge wings, canards and strakes, a flattened, tub-shaped nose section and state-of-the art israeli-american avionics and weapons. To incorporate the bigger engine, the fuselage aft section had to be redesigned. It was shortened and has a bigger diameter. Another characteristic of the Kfir is the auxiliary air intake in the tail root for the oil pump of the J-79 engine. Furthermore 2 more hardpoints (for a total of 9) were added below the intakes (but this might be only from C2 and later on, I'm unsure). The main gear got bigger wheels requiring a new gear bay doors layout. (If you might want to compare again, all these details are already featured in my Kfir model) So far a Kfir is a straight Mirage III derivative, you agree? Other famous derivatives of the Mirage III are the South African Atlas (Denel) Cheetah or the Chilean ENAER Pantera. In comparison, the Mirage F.1 airframe is totally different from the Mirage III airframe in almost every aspect, though it shares a familiar look - mainly due to the shape of the intakes. Even the Atar 9K-50 engine of the MF.1, shared with the Mirage 50, Â has a different afterburner design which is slightly angled upwards (the engine had to be de-centered below the main spar of the wings)

Some progress : fuselage geometry refined (windscreen frame shape, size and shape of main gear bay and doors, speed brakes, minor corrections to fuselage cross sections, cannon ports), now poly count is down to 2600 without sacrificing visual appearance (aimed at 2500 including all hidden selections), flight model optimised for AI and joystick users, introduced (new?) de-lagged scripting techniques by randomly desynchronized loop runtimes per ingame object (although no lag observed before, despite many continuously animated parts). Finally I started texturing on universal parts such as engine nozzle, gears and gear bays. Camouflaged parts will come later; texture switching works for different camo patterns. loadouts: I worked on a separate joint weapon pack for my various airplane packs; an AM.39 Exocet ASM is already included in the pack, as well as AS.30L, SAMP 250 & 400, Matra 155, BAP100, Matra R.550 Magic, R.530F, Super 530F, Super 530D and many others. My weapons will be merged with Hardrock's forthcoming ACES (AirCraft Equipment Standard) project. ACES uses a different approach for weapon loadouts than the common pseudo-proxy solution, which offers true flexibility - you can individually chose a weapon for each of the planes' hardpoints. My new textures on front gear: Some more screenies: (due to some irritations once again: please ignore the main textures; the spanish camo textures are borrowed from a FS2000 model (256x256 8bit if I remember correctly) just for testing, will be replaced by entirely new ones in the final model - crisp and without those strong shadows below wings and elevators) P.S. does anyone know how I can make the single vertex at the radome tip non-shining? Sharpening ("U") and "Vertex properties - Always in shadow" have no effect

hi Ex-RoNin, yes of course. hi RuN, yes, I'm already doing a Mirage III-and-derivates pack parallely to the F.1 pack. But had no time to compile some stuff for another MIII-thread yet; also would like to stick with the F.1 first as it's difficult for me to maintain more than one thread at a time. If you'd like to have a little preview, some early pics from the MIII-pack that I posted before in "Combat Photography" long time ago: Double Seater Mirage IIIBE IAI Kfir C2

Hi Adrenaline Red, many thanks for your suggestion, but there are some reasons I don't want to re-use textures from other games. Even if I could get green light from the original copyright owners, then I'd have to stick to their original texture segmentations and mappings, which in most cases (you see I have experimented with it already ) do not fit to my model's mesh, generate odd texture seams in actual seamless paintwork and, if no template is given, prevent a simple generation of different camoflage patterns. Then there's much work left for removing insignias, numbers and roundels, which (partly) should become scriptable in my model. My problem is just the decision on texture segmentation and mapping, and this persists with borrowed textures. Therefore I decided to do my own textures. hi Ex-RoNiN, following from what I said above about the scripting system, for the greek versions only the camoflage pattern "Aegean Blue" is needed (I think I'll provide it, as it is very popular and was also used by the French earlier), the greek blue-white-blue roundel and decals for the cockpit walls and tailfin. Just like the actual OFP roundel and number systems, these textures can be located outside of the addon file just as another addon. This means you can even chose which particular aircraft to fly (provided you have the artist skills to create the respective squadron's insignia! ) and hi Chris, you have PM (edited: the link - as I could not check the entire content of the site in order to post it here)

done already! Â I've put them under either WEST, EAST and RES right from the start. So a mission maker can mix French F.1C, Kuwaitian F.1CK and Qatar F.1EDA against Iraqi F.1EQs in a fictitious "Desert Storm" scenario for example, or equip the Tonalese or Nogovian air force.

Hi! Here's a little look into my work in progress. I'm working on a Dassault Mirage F.1 addon pack, which includes by now: - F.1C and variants, air-superiority fighter (C="Chasse") - F.1CR variants, tactical recon - F.1CT variants, (multi role) tactical fighter ("Chasse Tactique") - F.1A, simplified strike aircraft (eg. South African F.1AZ) - F.1E, export versions (eg. Spain, Iraq, Jordan, ...) features:  - just one .p3d for all versions, only 3000 vertices in first LOD  - many hidden selections for recreation of 90% of all RL versions (radomes, antennas, sensors...)  - offensive and defensive characteristics depending on avionics and weapon loadout  - detailed gear animation sequence, workaround for complex RL kinematics of main gear struts  - automatic intake cones, afterburner and airbrake control (under testing: AB might be operated manually)  - automatic speed dependent flaps and slats  - animated engine start up sequence  - RL cannon configs: single starboard cannon on CT - single port cannon on CR variants, rest with twin cannons (These WIP pics show preliminary fuselage textures, borrowed from Kirk Olsson's FS2000 Mirage F.1CE. A release version should come with my own ones)