Gunrunner

Well, actually, Star Trek is more fantasy than Star Wars... In Star Trek the techno-babble is mostly used as a stand-in for magic, they regularly find strange aliens and devices with weird powers (fighting evil wizards, meeting with gods), so many in some seasons that it seems the universe is full of god-like beings but only the wits of the Entreprise's crew can beat them. Classic Star Trek (like Space 1999) always had that homeric tone to me, except that seeing Kirk as Odysseus is kind of disturbing... Classic Star Wars on the other hand is more a cross between a western and war movie.

Original Star Wars, a little too easy at times, yet a classic. New Star Wars, utter bird droppings... Star Trek, all of it, boring, repetitive, idiotic, ludicrous. Space 1999, just like Star Trek, only shorter and actually managing to draw a smile from time to time and being a tad more clever (but just as ludicrous). Original BSG, boring as hell... New BSG, a telenovella in space. B5, actually quite good, if somewhat a little strange. Space Above and Beyond, you just can't miss that one. Firefly, Joss Whedon's redemption. Farscape... somewhat too campy at times, yet lovely. Red Dwarf, just brilliant. Hyperdrive, an enjoyable Star Trek.

- Maps, as said, can be done. - External views can be done too, there are quite a few view mods out there, but maybe it's not as powerful as you'd like. - Asymetric loadouts exist on some 3rd party planes, are quite easy to do on any planes, there just is a limit on how much entries you can manage, meaning on some planes with many hardpoint, you'd lose hardpoints or ordnance diversity. - F-16C, not a single European air force used them until the mid 90's, they all were A models (Block 1, 5, 10, 15, 15OCU and starting mid-90's MLU); Also, for use by the USAFE or the various nations provided with F-16C later on, the variety of blocks is so large it's harder to decide which F-16C to model. If you were so inclined you can still use the "old" F-16Cs (the F-16C-30 has been updated for inclusion into the ODS mod) from the Team Viper as "stand-in" until TMF or another team releases them up to the new standard of quality. You could also use TMF's F-16A-15OCU as a basis for a F-16C as the airframe is more or less the same as the first F-16C-32. See, with some digging parts of your wishlist just vanish :)

Damn, and I thought Christmas was over...

All I can say (once I got it working, more on that after) is WOW ! Amazing job guys... Just started a F-15E campaign for old times' sake (F-15E Strike Eagle III), and I must say it simply rocks... The new and updated planes are a must have, but the whole package is simply wonderful. It was well worth the wait, the weeks poured into this mod show. Yet, a few minor bugs and details (sorry, they're not deal breakers, just thought I'd mention them, I know the amount of work and how easily little things of such low priority slip by)... 1) You didn't think of us with international versions, the whole thing is a mess until you manually switch to TextUSEnglish.dll and other english texts (including a startup.ini would solve this). Just in case someone else got the problem and doesn't know what to do, here's the solution : Open startup.ini, replace Text[French|German|Italian|Spanish|UKEnglish].dll by TextUSEnglish.dll and remove [French|German|Italian|Spanish|UKEnglish] in front of everything else. 2) There is at least an iraqi airport with some take-off position problems, I had 4 MiG-23 in the middle of the runway in the same exact spot doing a nice impression of a starfish (didn't think of taking a picture and coordinates at the time). 3) A few airplanes still have their Peter Pan syndrome (Mirage F-1, and F-15E when going reversed at least). 4) The MiG-25 and MiG-29 have their shadows deactivated, on the -29 the pilot, ejection seat and weapons cast shadows though, on the -25 at least the weapons do. 5) The RF-4C's right engine has no afterburner effect (it still has KfirAfterburnerEmitter instead of AfterburnerEmitter). Well, enough minor bug reporting, now it's back to moving sand

Glad to have been of assistance.

Could you please copy and paste the content of decals.ini for the skin, I'd wager you're not using the right decal type here (probably using a per-plane (DecalLevel=2) decal when you should either be using a static or per-nation (DecalLevel=0) one).

Aye ! I don't want competition on the douche bag segment, especially when he seems so much better at it...

As if the Mirage Factory wasn't sitting on dozens of planes because they don't reach release standard or the engine doesn't allow for some functions yet... As if the aerodynamics were not the only one out there (for a combat sim) with zero scripting and only minimal cheats for AI planes... As if there weren't dozens of pits, carefully researched, including for soviet fighters... You, sir, are talking out of your ass... Usually you research first, then open your mouth... by forgetting the first step you only expose yourself to ridicule.

"und mein Führer ist Dave" just wouldn't sound right...

Keep in mind that the bobbing you see from footage taken from another plane is amplified by the fact that both planes (the one filming, and the one filmed) are not perfectly stable. For small up/down movements... If plane A is stable relative to the ground, but plane B isn't, if you are inside plane B you'll feel stable and interpret movement as being due to A movement (if you go down 30cm, you won't feel it and think A went 30cm up). But in most cases, both planes move up and down, when they are mostly synchronized the movement seems smaller than it is (both from inside the planes, and outside, as you use one plane as a reference for the other), but when their movements are diverging or worse, close to opposite, the effect seems amplified (If A goes up 30cm and you go up 29cm, you'll feel like you're both stable, but if A goes down 15cm while you go up 15cm, you'll feel like A went down 30cm). Since in WoX, when in manual and stick left in neutral, the planes are often more stable than they should be (in part because it's easier to have no input, by design and also because wind and turbulences are not much of a factor), I wonder if the excessive bobbing is not partly by design. Also, I don't see why airshow formations would be more stable than combat ones, especially when it means that planes would have to deal with each other's turbulences, the often closer proximity of the ground and lower mass (even though I doubt it factors much).

- Stop ! Who goes there ? - We are sycophants, and Dave's our leader ! sounds nice...

nicely put, but the numbers argument won't fly; With such pseudo-elitists popularity is a sure sign that you're doing it wrong... only niche items are doing things right, that's why they're not popular, very few people have the mind to understand it, only they can...

Tailspin, you poor soul, you wouldn't understand, it is because Targetware's devs and community have something that TK apparently lacks, integrity, and they are such perfectionnists that they wouldn't release something that doesn't reach perfection... Alas, us poor plebeians can't begin to understand the noble soul of such elite men... You are only Tailspin, a gamer, while He is Stiglr the Simulator !

Nah, I'd reserve that for people saying that "Apparently the code is an issue" when they apparently don't have a clue about computers beyond the apparent opinion that their purpose is to display pretty pictures as fast as possible and couldn't write ten lines of code to save their lives...

As if we didn't knew already. ^^ BTW his economics are reversed, what he doesn't get is that we're happy with TK's choice because it's what keeps gaining new players, keeping the community alive and getting funds for slowly but surely adding lacking features... TK could have gone the perfectionnist and hardcore way, but that would have meant a) longer dev time and cost thus, costlier product b) less appeal to casual simers and newcomers c) more work on each plane and thus less flyable planes limiting appeal once more d) more complex system making modding (either internally for new games and add ons, or externally for the community) more difficult, thus limiting the activity of the community. Finally, what removes all credibility to Stiglr demonstration is his encouragement not to give any more money to TK until he gives whatever it is that he deems acceptable (and knowing the kind of troll he is, nothing will ever be satisfying), completely missing the fact that with his attitude, we wouldn't get a better sim, we would get no sim at all... and in this economy TK would probably have to flip burgers to pay the rent... The state of flight simulation is dire enough to support every damn effort, especially when it comes from independant, dedicated efforts we can trust (TK has always updated everything to the latest standard for no cost, and every paying release brought something new, improved and interesting to the table). What's strange is that he knows what makes SF different from say... Targetware... the later tries to pretend it is a simulation, while the former makes very few attempts at being more than a game (numerous design decisions, and TK's own words, point to that). And there is a larger appeal for a flight sim game than for something striving for "serious simulation" status but lacking any form of fun and involvement. If I were to take a bet, I'd say Stiglr is an active member of the Targetware community...

Russo, would be even better if you could bring the Nimitz back in time with you

Quick (and mostly wrong) answers to give you ideas on how to solve (or not) the problems : a) The new WoX patches change the shadow system for an upgrade of the one used in WoI, you should disable lines refering to .SHD files in the planes .INI, and delete the .SHD themselves as they now serve no purpose. (note: with the new system this step might not be required, I just haven't played with it yet, it just worked that way with pre-patch WoI) b) Some models have tiny faults (open faces, holes etc...), which create problems for the shadow engine when it calculates how to project shadows. If I were to take an uneducated guess, I'd say the first picture is case b) while the second is more along case a) Problems due to a) can be solved by INI editing. Problems due to b) can't be solved easily (unless someone "corrects"* the model). DISCLAIMER : I probably am wrong... Slightly off-topic, but has the "patching" (placing a piece using the pilot method inside the model to "patch" the hole without having to have the source) approach of solving these issues been tested succesfully ?

Sorry I gave the impression that I advocated an absence of shortcomings in the WoX series, the whole idea was to demonstrate that those shortcomings were not "coding faults" but design, resource, focus, historical and context constraints. The bit that really set me off and to which I reacted so violently (and with apparently so unclear arguments and motivation) is "And to that end, the coding apparently is an issue." Ok, first quote, LOMAC for me is even slower that updated WoI (faster to load, better max FPS, but lower min FPS and lower average and median FPS), but that is because in LOMAC's case I'm probably GPU-limited rather than CPU-limited. Il2 I admit I went out on a limb and assumed the situation was not any better than at 1946's release... FSX... well, I don't find FSX playable on the setup I used... Also, it depends on what you call incomparably better... I was not saying that these sims are not faster or smoother than WoX, just that none of them reaches the kind of FPS you expect from well, a FPS (if you exclude those last-gen which are more tech demo than games), which, in my ire, seemed to be the point of StarBucker, I may have been wrong, making my whole demonstration utterly useless. Uh... Brain, the second quote was sarcastic... -_- Most if not all coders who actually release a flight simulator know what they are doing, they just sometimes don't have the resources to make things as good as they could and/or they also might put more efforts and optimizations into certain parts of the engine rather than others, making the final result more or less CPU-limited. From what I gathered in TK's case, I think he is not that interested in absolute performances in max settings (and optimising the code (CPU or GPU-side) for such corner cases is a long and costly process with usually diminishing returns), but has a strong interest in aerodynamics (a CPU cycle eater), a growing interest in AI (another CPU cycle eater), loves to cheat as little as possible unless for gameplay purpose and that those design decisions affect performances... These are also the reason why TW sims don't "cheat" the same way (or to the same extent) than Il-2 or LOMAC. The CPU-bound comment concerned flight simulators in general, in contrast to other types of games, not WoX in particular, and why, unlike RTS, FPS and other more popular genres, they can't easily benefit from multiple cores and thus are more easily CPU-bound than GPU-bound. Now, on the number of FPS making a game enjoyable, it also depends on the smoothness of operation and your gaming background. A solid 20 FPS is still playable and enjoyable, but when the 20 FPS is an average of succeding lapses of 5 FPS and 30 FPS, it becomes hardly playable and enjoyable. And 20 FPS seems great when you started simming with DOS programs written in BASIC. Also, take into account that it was an epidermic reaction at the implication that code was the problem, rather than design constraints. Being a coder myself and having my fair share of such crap arguments from non-coders who can't begin to understand the various factors at work, it struck a nerve, making me comment on a domain (coding flight simulators) of which I have ZERO experience. My purpose was mostly to explain that reality is often more complex than what appears to us simple users, and that we are not qualified to judge the quality of the code, only of the design decisions if/once we know enough about the constraints under which the code was produced, or of the end result (I would have no problem with someone saying that the WoX is crap (with proper argumentation that is, even though I might not agree with the arguments or the conclusion, at least it would be based on a well thought context)). Bleh, I don't know if that makes sense for anyone but myself... Hope I didn't offend StarBucker while venting my frustration...

StarBucker> After expurging my initial irate answer of some nasty epithets and questionning of your intelligence (sorry, I can't abide people blaming others (here ThirdWire) for their own shortcomings (in that case you ignorance when it comes to certain areas of computing and flight simulators)), I'll let you read what might open your eyes, just a little... As the Great Old Ones already informed you, such FPS are perfectly normal for a flight simulator (and even though until now we were used to better FPS in TW sims, the patch brings a more robust AI (meaning eating more CPU cycles), enhanced physics (once again eating CPU cycles) and a few other goodies lowering FPS but keeping the sim up to date and taking advantage of the better hardware some of us have). Just try to play LOMAC, FSX, or even IL2, and tell us whether or not you manage to reach 100 FPS with any of them patched and at max settings... Or maybe is it than none of the studios having developped flight simulator engines for decades have a clue how to code one properly. Let me try to put things simply so maybe you start to understand the depth of... the problem. Not all games are about putting up as much pretty graphics as fast as possible, some even have physics which are simulation of real physical rules not just about getting a swarm of small objects elegantly floating and bouncing around. Some games also attempt to implement simulation of electronic system, IA which are not just about pathfinding in a 2D environment and managing line of sight... Such games are CPU bound, not because the coder is a moron as you seem to suggest, but because even now with CUDA, OpenCL etc... most of these calculations still can't be done GPU-side. If you were to find a fault in the TW flight sims engine coding it would be in its lack of support for multiple cores, meaning its performances won't scale with the number of cores. We could imagine an engine using core 0 for all graphic calculations, core 1 for for all physics, core 2 for IA and core 3 for systems. But, things are not that easy... Such a multithreaded/multiprocess engine has numerous limitations in a flight simulation (namely, all processes are dependant on each other, meaning the whole thing is as slow as the slowest of the processes), as you seem more knowledgeable when it comes to graphics, lets use this paradigm (which sucks in this case as nothing with this kind of engine would work as sequentially as I'm about to describe, in fact, what I'll describe won't work at all), whenever the engine would draw a frame, it needs 1) Data from where things were in the previous frame to pass, in paralell to 2a) the physics engine, so it determines where things should be now (uh oh, bogey #13 is climbing, but out of energy, it should start decelerating, or stalling), 2b) the IA engine (oh oh, bogey #7 decided to put its nose down to regain energy, and bank right to try to intercept friendly #10, and friendly #5 just got in range of SAM #9 etc...) and 2c) the systems engine (ah ah ! bogey #5 is out of range of the player's radar, I'll signal not to draw it anymore, and SAM #4 is tracking player, I'll tell the graphics to draw it, and when each finishes its task, it send the whole thing to 3) the graphics, which calculate what to draw, where etc... and send the whole deal to the GPU... The problem with this approach is that coding such an engine (properly) is extremely difficult, time-consuming and requires extensive testing, it also means that while it scales up pretty well (meaning it easily takes advantage of faster and better hardware) it scales down pretty poorly (meaning that if the engine's designed for 4 threads, you will take quite a hit on a dual or single core). Also, some type of computing just don't parallelize well (on classical desktop architectures, while keeping compatibility and realistic hardware requirements in mind) and flight simulators are among those tasks that won't benefit much from multiple cores. FSX was upgraded to better use multiple cores, but still remains a single thread beast, delegating only simple and mostly independant tasks to other cores, resulting in marginal FPS gains... and that's from a company with massive resources which actually wrote the OS (and thus the scheduler) on which the game's running. It is easy to parallelize graphics, having each unit only computing one part of the larger picture, but to get to that point the GPU must receive from the CPU what to draw... some games have very little to compute before sending data to the GPU (mostly because while visually impressive, they actually perform simple tasks, with scripted IAs, in a simple environment) and are largely GPU-dependent, other games, like flight simulators, have a lot of computing to do before sending anything to the GPU (mostly because, even if some are visually not that impressive, they perform numerous complex tasks, with complex, non-scripted IAs, in a complex and always evolving environment) and end up being largely CPU-dependent... Finally, you also have to consider that TW is a mostly one-man operation, and has neither the time, staff or resources to rebuild an engine aimed at using multiple cores when 1) The original engine was written when dual-cores where still on paper 2) Adapting the original engine would cost as much (and maybe more) than writing a new engine 3) There is more interest and urgency to be "natively" compatible with Vista and DX10, as well as revising the engine for easier moddability (which gave us the SF2 engine) 4) The gains would not necessarily be worth the resources spent 5) The actual engine is still quite satisfactory for people who know and understand its principles and limitations (those who solve FPS issues on single-threaded CPU-dependent games by throwing a faster CPU (or CPU with faster cores) at it, not by adding a GPU or many slow cores) and 6) The "budget" orientation of the game would suffer if it can't be played properly on a low-end single-core system (you don't sell as much $20 games if they only play well on $1000 computers instead of $500 ones).

A refresher just in case you lost the plot of the last 30 years in fighter planes technology... Quite a few major air superiority/interception planes designed these last 30 years have been naturally unstable on purpose (F-16, F-18, F-22, Mirage 2000, Rafale, Gripen, Typhoon, MiG-29, Su-27) as a way to increase manoeuvrability. Fly-by-wire being most of the time what stands between a plane actually doing what the pilot wants and actually doing exactly the opposite, or just crashing to the ground in interesting ways.

For this generation of CPU, unless interested in the best perf/price ratio for web browsing, office duties, or you are interested in 4/8-ways systems, avoid AMD. Now, taking a look at newegg with gaming on a tight budget on mind, what can we do for you... Motherboard : Intel DP35DP - $110 (generation n-1,5, still pretty fast, stable, no nonsense BIOS, lacks in OC features) Gigabyte GA-EP45-DS3R - $110 (generation n-1, fast, stable, durable, more BIOS options) Intel DG33TL - $80 (generation n-1,5, stable, still fast enough, no nonsense BIOS, lacks in OC features, lacks in upgradability as it is a µATX board, still good enough for a 2 slot GPU and a PCI card, I use this on my legacy system). I'd avoid MSI like the plague (some boards work like a charm for years, other die on you in a matter of weeks), avoid Asus actual offering (basic MBs are lacking in stability and features and higher offerings are packed with useless gimmicks jacking up the price and increasing stability issues). CPU : Intel Core 2 Duo E8400 - $165 (best price/perf ratio for gaming at the moment) Intel Core 2 Duo E7300 - $120 (if you really are on a budget) GPU : XFX 9800GT @670/1950 512MB - $160 ($20 mail in rebate) (IMHO best price/perf ratio for single GPU, unless you find a ASUS EN9800GT ULTIMATE @725/2000) You may find better deals in one-slot design but they're usually noisier and tend to generate more heat in your system. RAM : G.Skill 2x 2GB DDR PC6400PK - $60 (not the best overclockers, but fast enough, stable, and not requiring stupid voltages, leaves you room to add 4 more GB should you migrate to 64bit and need them (mostly useless for gaming at the moment though)) With your Power Supply and Monitor, that gives us between $850 and $925 (after rebate), compared to your $838... Close enough budget, more stable configuration, better CPU, better GPU, more RAM (and if/when you'll move on to Vista/7 64bit, you'll be able to use the whole 4GB). The downside of this Intel proposal is that Intel is introducing a new system platform, meaning that in 2 years time, you probably won't be able to upgrade the CPU by anything else (except second hand or stocks). Bear in mind that gaming on a budget is hard and the tighter your budget is, the faster your computer will reach its limits. For legacy gaming, or if you intend not to use any game out in 2 years really seriously, a tight budget is fine, otherwise it is worth putting a little more into your system (especially with a 24" display). Last advice... If you really are on a budget, favor the core of the system and settle on a smaller display, a 22" isn't that much smaller than a 24", but uses a 1680*1050 resolution, meaning you'll get better framerates or will be able to push AA and options. It will be easier and less costly in 2 years time to upgrade your monitor than your system.

Since with WoI we have a nearly perfect Mirage 5F airframe (and since I ported my WoE to WoI), I thought it would be nice to make a placeholder until the TMF releases his own version. What do we need ? 1) An airframe (a LOD) In this case, the Lybian Mirage 5D as it already has the right specular/gloss values all over (which isn't the case of the Nesher). 2) A cockpit In absence of something better and references on hand, the nesher cockpit is the best stand-in we have (the Mirage 5BA having substantially different equipment and avionics, and the Nesher and 5F being basically identically out of factory). 3) A flight model The Nesher will do nicely. 4) Avionics Same as above, the Nesher is as good as if TW made a 5F themselves. 5) Skins and decals We have a template, albeit of little help, and we can use some existing decals at first to speed up things as the TMF released aircrafts from the same units and time scale already. 6) Weapons By using the TMF weapons pack we inherit a lot of weapons used by the 5F, or the means to create them, we'll see that later. so, let's begin... 1) The airframe - Create a Objects/Aircraft/Mirage5F directory - Copy or extract from objectdata.cat the following files and directories : Nesher.ini Nesher_DATA.ini Nesher_LOADOUT.ini IDFCamo1/ and rename then by replacing Nesher by Mirage5F, except in the IDFCamo1 (which you can rename as ADACamoEC3-3 as we'll be working on this squadron first) directory where you must replace the Nesher_x.bmp names by Mirage5D_x.bmp (remember, we'll be using the Mirage 5D LOD and don't want to edit it). - Open Mirage5F.ini and replace the existing content by : [AircraftData] AircraftFullName=Mirage 5F AircraftShortName=Mirage 5F AircraftDataFile=Mirage5F_data.ini CockpitDataFile=Nesher_cockpit.ini HangarScreen=Nesher_hangar.bmp LoadingScreen=Nesher_Loading.bmp LoadoutImage=Nesher_loadout.bmp LoadoutFile=Mirage5F_Loadout.ini AvionicsDLL=Avionics60.dll AvionicsDataFilename=Nesher_avionics.ini [LOD001] Filename=Mirage5D.LOD Distance=100 [LOD002] Filename=Mirage5D_lod2.LOD Distance=250 [LOD003] Filename=Mirage5D_lod3.LOD Distance=500 [LOD004] Filename=Mirage5D_lod4.LOD Distance=1000 [LOD005] Filename=Mirage5D_lod5.LOD Distance=10000 [DamageTexture] DamagedPostFix=_holes.tga [Shadow] CastShadow=TRUE ShadowCastDist=10000 MaxVisibleDistance=800 [TextureSet001] Directory=ADACamoEC3-3 Name=ADA EC 3/3 Ardennes Nation=FRANCE Specular=0.400000 Glossiness=0.400000 Reflection=0.000000 Squadron=ADAEC3-3 Take note that we changed the LOD called by the file, as seen above. - Open the TextureSet.ini file within ADACamoEC3-3 and change its content by : [TextureSet] Name=ADA EC 3/3 Ardennes Nation=FRANCE Squadron=ADAEC3-3 Specular=0.400000 Glossiness=0.400000 Reflection=0.000000 - Open the Mirage5D_DATA.INI file and change the whole MissionData code block by the following values : [MissionData] NationName=FRANCE ServiceStartYear=1972 ServiceEndYear=1994 AircraftRole=FIGHTER AircraftCapability=DAY_ONLY Availability=RARE Exported=FALSE PrimaryRoles=STRIKE,CAS,SWEEP,ARMED_RECON,SEAD SecondaryRoles=ANTI_SHIP,RECON NormalMissionRadius=436 MaxMissionRadius=872 Ceiling=16093.4 MinBaseSize=MEDIUM There, you have a Mirage 5F ready to fly with the right dates, name and roles... Yet... we are still missing something for our airframe, Mirage 5F, once embargoed, were quickly introduced into French service but quickly added VOR navigation antennas on the vertical tail. 76.IAP-Blackbird is kind enough to be interested by this project, so I'll let him take care of the explanation ;). Now we skip all the parts we don't have to touch, and end up to skinning and decals... 5) Skins and decals Ideally we will end up making our own skin and decals, but as an interim solution, to quickly jump into the cockpit, we have another solution. In the end we strike to have 4 skins, covering all the units operating the Mirage 5F in Europe, namely : - EC 3/13 Auvergne Silver (From 1972 to 1973?) - EC 3/13 Auvergne Camo (From 1973? to 1994) - EC 3/3 Ardennes Camo (From 1972 to 1977) - EC 2/13 Alpes Camo (From 1977 to 1994) One of the units using the Mirage 5F was the EC 3/3 Ardennes, a unit specialised in SEAD, fortunately the TMF released the Mirage IIIE with skins and decals for the EC 3/3, so all you have to do to get placeholder decals is to get the excellent Mirage IIIE (here or here). So, until we get a template, what can we do ? We can recolor existing skins, here's a quick and dirty way : a) Open a BMP in Photoshop, let's say Mirage5F_1.bmp b) In the menu, search for Image > Adjustments > Replace Color... c) Select the color to replace, here we'll start with the sand color (click on any sand colored part that's not a rivet, panel line or dirt stain). d) Change the fuzziness to 100, as we want to change colors without changing too much of them and ending with strange colors in other places. e) Select a result color close to what you want it to be, here a grey/blue (my choice was 7a7c91). d) Click OK. Repeat, using the Green as a color to replace and 5C5E53 (a darker green) as a target, you'll notice that the earth color change too, and that is why this time, while repeating the process for the Earth color, you'll set Fuzziness to 50, so we don't end up modifying too many colors (the target is, to be quick, 5C5E53). You'll end up with something that could pass for a Mirage 5F camouflage for the time being, you then can add details, modify areas, such as the nose, to fit the real thing, but since it would take longer to explain the process than to do it, we'll see that later on and I'll let you play with Photoshop by yourself... In the meantime, you can download my interim skin... ADACamoEC3_3.zip

Smells like hoax, especially for 1891 (the anti-masturbation mass hysteria would only start to die down in the early 20th century and would linger on for quite some time thanks to Anna Freud and her followers), only a few more years and the idea of using masturbation as a treatment for hysteria was starting to gain some real traction, getting some justification for such contraption. Fun fact, vibrators were actually invented for medical purposes, and fell out of favour when they started being used for non-medical purpose which, as you may imagine, happened quite quickly. Also, on the prototype seen, the screws (as well as other parts) are too new, belonging more to the 30's to 60's era than late 19th... IF passed for the "original" prototype, then it's highly probable we see a fake, if it is a reconstruction/restauration, then it's a very shoddy job indeed. Sounds more like a steam-punk/subgenius thing...

Dave, have I ever suggested it should be taken as a hoax and ignore it ? On the contrary... this is the minor hypothesis as a hoax would have tried to generate more publicity, unfortunately 2 (competence issues) of the 3 alternatives are worrisome (well, for the US, strangely enough this kind of things doesn't happen on our side of the Atlantic, even though we have our fair share of problems). What started my comment is not the threat, but the ridiculous feedback from PhotoBucket/FBI/DHS that reeks of incompetence/lack of interest. I then pointed out the inconsistence in the "case", examining the alternatives to incompetence, which would be worrisome (remember the Blue Thunder thread, I'd hate to think that relinquishing privacy and liberties would not offer more security at all, it's all a trade-off, with the response to the case discussed here, I'd say you are being ripped off).