Jump to content

teacup

Member
  • Content Count

    207
  • Joined

  • Last visited

  • Medals

Everything posted by teacup

  1. teacup

    Aircraft Speed

    ArmA does not account for aircraft load and weight. Whether empty or fully loaded, they all fly the same. The simulation is not that detailed. If you're not familiar with config files, pick up some generic modding tutorial and look at the configuration files provided with the sample models. It's a vast topic, cannot be covered here. For top speed of airplanes, check out this older forum discussion: http://forums.bistudio.com/showthread.php?94407-Aircraft-Max-Speed-Help-Please Also this: http://tactical.nekromantix.com/wiki/doku.php?id=arma:flight_model
  2. Instead of your "model.cfg", you quoted "Crewanimations.hpp" again. And model.cfg is the crucial file here. In it, you have to define or inherit a section/selection that will be responsible for displaying damage textures. If you look at the sample models and configs, it's generally the selection called "zbytek", that's being used for this purpose. But you can also define your own: in cfgVehicles >> All, there is a property called selectionDamage="zbytek", and all other vehicles inherit from there. Of course, you also need to have that selection in all the visual LODs of your model. Some extra reference: http://tactical.nekromantix.com/wiki/doku.php?id=arma:modeling:damage_model
  3. teacup

    help creating reference images?

    You can check out websites similar to The Blueprints, they might have what you're after. However, few of these plans/blueprints you find online are original factory drawings, their accuracy is questionable. Sometimes you're better off looking for official documentation like flight/repair/maintenance manuals. They often have drawings in them that are accurate. Alternatively, you can find high resolution photos and trace them using vector graphics software. Ideally, you should find the object you want to model, and photograph it yourself to remove as much perspective/lens deformation as you can from your reference image. What i did in the past was found the aircraft i wanted to model in an open air museum, "drew" a line parallel to it, and as far from it as possible, then walked along that line and after every meter, took a perpendicular photo of it. Then i got the images in Photoshop, used PTLens to remove lens distortion, and stitched them together to create a picture as close as possible to an ortographic image. Then traced it in Flash.
  4. Yup, my thoughts exactly. Except lights are not particles (they are actual lights, + optional sprite for the glow, + optional emitter surface/light cone geometry). And the exhaust effects are some kind of 3D-to-2D post processing wizzardry. I'm guessing the reason why these features don't animate as we expect, is optimization. The person writing the simulation code figured lights/wingtips/engines will always be fixed, why bother to refresh them all the time and waste CPU/GPU time. If anyone is willing to make a feature request out of it, i'd gladly support it.
  5. Probably. That would involve changing texture paths in the proxy, and path to proxy in the truck model - using a hex-editor. While taking care to keep path lengths the same as the originals.
  6. There is a switch in the "Face Properties" window (shortcut "E"), under the "Lighting and Shadows" section called "Both sides". But it apparently no longer works, at least it didn't for me. What i did was Ctrl+C/Ctrl+V all the faces i wanted double sided, then pressed "W" to reverse the normals.
  7. Animations work for some memory points, and don't for others. Or maybe they work fine, except the simulation (plane, planex) ignores them. Same is true for wingtip vortex memory points, etc.. It seems they haven't considered the possibility of variable sweep wings, and the simulation code reads light positions only once from the P3D, and not continuously.
  8. I'm glad you like it. Thank you for your appreciative comments, everyone. It makes the tough 6 months leading up to this release easier to forget.. :)
  9. Thanks for the tip, I will take a look.
  10. 1. I had a similar experience with TexView2 and vehicle textures. When i saved TGA files from Photoshop that had an Alpha channel, and converted them to PAA, it messed up the transparency: all the grey areas between black (0) and white (256) were rounded up or down to either black or white. There was no semi-transparency, only fully transparent or fully opaque. What worked in the end was appending the "_CO" suffix to texture names when saving a PAA. So if i opened "texture.tga" in TexView and saved it as "texture_co.paa", it worked, no longer messed up the Alpha. Give it a try, might work. 2. Looking at some code from UI_f.pbo, it seems to me the formulas for making consistent UIs across all aspect ratios and resolution are pretty complex x="0 * (((safezoneW / safezoneH) min 1.2) / 40) + (profilenamespace getvariable [""IGUI_GRID_RADAR_X"", (safezoneX + safezoneW / 2 - 2.8 * (((safezoneW / safezoneH) min 1.2) / 40))])"; y="0 * ((((safezoneW / safezoneH) min 1.2) / 1.2) / 25) + (profilenamespace getvariable [""IGUI_GRID_RADAR_Y"", (safezoneY + 0.5 * ((((safezoneW / safezoneH) min 1.2) / 1.2) / 25))])"; w="5.6 * (((safezoneW / safezoneH) min 1.2) / 40)"; h="5.6 * ((((safezoneW / safezoneH) min 1.2) / 1.2) / 25)";
  11. I plan to make 2 branches of the aircraft: one basic, without any scripted or complicated extras, and one more detailed/realistic. The latter will have a brake chute, ejection seat, afterburner, and perhaps a better damage/destruction simulation. And no radar. And would be more difficult to fly.
  12. It's true, your diffuse is off colour: it's all brownish instead of cold metallic grey with brownish rust spots, specular is dead, but normal maps work fine. Yes, those numbers are meaningful, they are multiplied with colour from your maps. To get your diffuse back on track, i would first set ambient and diffuse in the RVMAT to neutral grey (0.5, 0.5, 0.5) instead of white like you did. Specular is the tricky bit. I noticed you put the same image in both channels, which is not how it works in ArmA usually. Try this: leave the Green channel as it is, and in the Blue channel, put the inverted Green channel (like white-hot FLIR, black-hot FLIR). There's no rule saying it has to be the inverse of it, but it usually/largely is. Green is specular map (white is shiny, black is matte), Blue is specular power (black gives flat/dull "highlights" (more like no highlights), white is a blinding/sharp higlight). For metal shining through thinned and chipped paint i would raise specularPower in the RVMAT to 100. That will give you sexy highlights. On the downside, you will have a hard time getting matte surfaces, because the divide between matte and shiny is squeezed down to very low ranges: between 2 and 15 (i mean pixel values in the map) it goes from matte to shiny, and i can't see in that range, it all loks black to me. Instead of working in a 0-256 range, I fumble in the dark, reading pixel values at the tip of my pointer in Photoshop. So balancing the specular map is not easy, but you can get the hang of it. Look at some of the game textures and materials for cues, specially the older ArmA2 ones, ArmA3 vehicles are mostly new looking, all shiny.
  13. I don't intend to do a 2 seater trainer. Had trouble finding decent photografic reference for the one seater cockpit, the instructor pit will be even harder to document I imagine. Unless someone can get into one of them and photograph/measure the hell out of it.. Features like moving stick/hands and most other things present in the stock ArmA3 planes, will be there upon next release. Some however are problematic. Wingtip trails and position lights for instance, because of the variable-sweep wings connected to flaps action. If i just inherit them, tip lights and trails will stay in one place while the wings fold out, so I will have to resort to some (scripted?) hackery and see what works. What do you mean by flickering rocket pods?
  14. Not sure what you mean by "cloche", if it's the hands moving along with the flightstick and throttle, and the feet being connected to the pedals, then yes, these features will be in the next release - but that's going to land late summer-ish, or in the autumn.
  15. What you did there, was not much. You told the game you want to patch it, and the name of the patch would be "dubbing_new_epa". But you didn't actually add/replace any content. I'm not 100% sure, but i think in order to overwrite those audio files, you should unpack "missions_f_epa.pbo", since "dubbing_f_epa.pbo" contains no config of it's own, it's just a bunch of sound and lipsync files. Find missions_f_epa's config.bin and use cfgConvert to turn it into ASCII form. Then start your config like this: class CfgPatches { class YOURTAG_YOURPATCHNAME { units[]={}; weapons[]={}; requiredVersion=0.1; requiredAddons[]= { "A3_Missions_F_EPA" }; }; }; Then copy over the needed cfgSentences entries from the game config.cpp and change the file paths to point to your PBO, something like this: class CfgSentences { class A_hub { class 000_a_m01_intro { priority=0; file="\a3\missions_f_EPA\kb\A_hub\A_hub_000_a_m01_intro.bikb"; class Sentences { class a_hub_000_a_m01_intro_ALP_0 { text="$STR_A3_a_hub_000_a_m01_intro_ALP_0"; speech[]= { "dubbing_new_epa\a_hub\000_a_m01_intro\a_hub_000_a_m01_intro_ALP_0.ogg" }; actor="BIS_AlphaLead"; variant=""; variantText=""; class Arguments { }; }; class a_hub_000_a_m01_intro_ALP_1 { text="$STR_A3_a_hub_000_a_m01_intro_ALP_1"; speech[]= { "dubbing_new_epa\a_hub\000_a_m01_intro\a_hub_000_a_m01_intro_ALP_1.ogg" }; actor="BIS_AlphaLead"; variant=""; variantText=""; class Arguments { }; }; class a_hub_000_a_m01_intro_ALP_2 { text="$STR_A3_a_hub_000_a_m01_intro_ALP_2"; speech[]= { "dubbing_new_epa\a_hub\000_a_m01_intro\a_hub_000_a_m01_intro_ALP_2.ogg" }; actor="BIS_AlphaLead"; variant=""; variantText=""; class Arguments { }; }; }; class Arguments { }; class Special { }; startWithVocal[]= { "hour" }; startWithConsonant[]= { "europe", "university" }; }; Do this for all the files you want to swap out, then put your config.cpp in your PBO\s root directory.
  16. As far as i know, all character movement inside vehicles is controlled by A. proxy (it can be animated) and B. RTM animation files. Even the special cases of hands holding onto steering wheels, flight sticks, throttles, and feet connected to pedals - are done via RTM/IK handle/cfgMoves/cfgGestures setup. I don't think it's a matter of one particular config entry, or memory point. Bring up the animation viewer and take a look at those particular cargo anims: is the head of the character looking the wrong way?
  17. I wouldn't say never, specially since i also did an extensive photo-walkaround (with texturing in mind) of the Mi-24 as well, when i was at the Krumovo Air Museum in Plovdiv. And a bunch of Mig-23s: But short/medium term, probably not. First i will have to finish the Su-22 (might even port it to a flightsim), then i have 2 more addon/mod ideas that have nothing to do with aviation, and i also have to earn a living between these :)
  18. Dangit! Last minute config changes will do that to you. Oh well, it's a minor visual bug, unless a serious usability problem arises, i will not be patching it soon. To remove them textures from the unmarked plane, put this in the init line: this setObjectTexture [0, ""]; this setObjectTexture [1, ""];
  19. For the gunner to be looking at a screen perpendicular to him in the cargo area, you would either have to modify his cargo animation(s) (RTM files, you twist his neck and upper body to look at the screen), or rotate his proxy 90 degrees, if it makes sense for that vehicle interior..
  20. Howdies, I spent the past year working on and off, on a Sukhoi-17/22 model, and i reckon it's at a stage where i can present it. It's a normal low-poly model, but with very high resolution photo textures, and good detail. Last summer, i made a detour from one of my roadtrips, and drove to Plovdiv in Bulgaria, where they have 2 of these planes on exhibit at the Krumovo Air Museum. I crawled around them for hours and brought home several Gigabytes of photos to help me texture it. Even so, it took hundreds and hundreds of hours to cut, stretch and blend these photos, but i pulled through and the job is largely done now. So i popped the model into the game, made some quick and dirty specular & normal maps, and here is the result, the mockup: My intention is to first release a simpler version that would use about the same amount of resources as the native game aircraft, and would be as close as possible to the Albatros/Buzzard in every way. Basicly, a version that would fit well with what BIS have created. I hope to make 3 camo schemes: 1 olive drab (the one in the screenshots), 1 spotted (i'm thinking the colors used by the Polish AF or the Ukrainian AF, maybe both) and one "desert" (Egyptian or Syrian camo). Later, i'd like to work on a higher resolution, more complex, simulationey version, with more features and more eye candy. This is where i could use some help. If you know anyone that could help out with information about all the aircraft's systems, better yet - if you know someone that has acces to it and can take pictures of details (i'm low on cockpit reference), someone that can measure parts of it for me, someone that has authentic manuals or any other documents, someone that has flown or serviced these planes - and would be willing to help, please PM me. I myself don't speak Russian or Polish (they still operate the aircraft), so my access is very limited, even to the little online info that's available on forums and elsewhere.
  21. Thanks for the plug & mirrors Foxhound and Sonsalt. I don't know yet. It might, but the current proxy/arming system is so complicated, that i might just do several fix loadouts (mixed like it is now, bomb heavy, ATGM heavy) instead of fully customizable pylons. All of the weapons are stand-ins right now, they are ArmA3 stock, except for the FAB-250s from ArmA2 masquerading as FAB-500s. But it will get an authentic assortment of weapons eventually, giving mission makers some options. In real life, it's a daytime only, black and white (projected onto a brown-yellowish screen) TV system used for missile guiding. In my addon, it's mostly decorative (PIP textures do not support post processing, and the rendered view distance is too small to be useful). The optic is supposed to mimick that TV system, but i didn't have the time to set it up with post processing, 2x and 4x magnification, etc..
  22. teacup

    Model appears black

    If i were you i would take a RVMAT from the game and use that first. Then, one by one, modify only the 2 paths to your normal and specular maps: texture = "hlunits\data\combinesoldier_nohq.paa"; texture = "hlunits\data\combinesoldiersheet_smdi.paa"; It seems like you're trying to make a soldier, so take a RVMAT used on a BIS soldier, and use that as a base. See if your color/diffuse texture shows up ok, with obviously the wrong specular/normal. Then add your stuff to it. That way you can trace what's causing the blackness, it could be a number of things: either one of your textures is messed up (e.g. specular map has shininess info in Red channel instead of Green) or maybe one of the procedural textures in the RVMAT are wrong (i notice in Stage4 the blank AS texture is all black, while in most RVMAT's i've seen, it's white like this: #(argb,8,8,3)color(1,1,1,1,AS)). Like WarLord554 says, it's also worth looking at the UVs, see if they got imported ok. Normals are unlikely to be causing all black shading. If you can't debug it yourself, might want to post the files, someone could take a look for you.
  23. Has anyone figured out how things work in A3, regarding weapons/magazines/proxies on aircraft? 4 days into it, and i can't make sense of anything, it's such a royal, unpredictable, unintuitive mess. I hoped making the correct proxies (referencing the correct weapons/mags), properly indexed, and then adding the magazines in config, would result in a simple, working loadout. I had no ambitions of dynamic or flexible loadouts, just basic stuff. Was i in for a lot of headscratching.. First oddity is that missiles "travel" down the hardpoints: remove all mags from the Wipeout, then add "2Rnd_Missile_AA_04_F", and fire them. Repeat. Even though all hardpoints are empty, the newly added missiles are not placed on the base hardpoints numbered 1 and 2, but 3-4, 5-6, and so on, untill all hardpoints are used up and missiles start coming from the center of the aircraft. Can these planes be properly rearmed via scripts, even with their original loadout? The other weird thing is ammo multiplication: you add a 2 round mag, it shows 4 bits of ammunition, you add a 4 round mag and it shows 10 bits of ammo, provided you have enough proxies they can populate. Is this a bug or a feature? What's the logic? Then come the odd combinations: 2 round mag AA + 2 round mag AGM = asymmetric loadout (showing 3 x AGM + 1 x AA), even though proxies are ordered correctly, even numbers on one side, odds on the other. After all ammo is fired one AGM still hanging onto a pylon (?). To make matters more complicated, A3 comes with some new stuff to pile onto the old: model.cfg has some stuff for hiding/showing different loadouts, Buzzard has some mistery MemoryLOD points called "missile_1", "missile_2", "missile_3" and "missile_4", and there's also this: If anyone could shed some light on any of the above, i would be grateful. Otherwise i have to get back to testing, isolating, trying to make sense of things, and i'd rather spend time more productively.
  24. You should install "vcredist_arm", only if you're running ArmA3 Tools on your iPhone.. :) https://en.wikipedia.org/wiki/ARM_architecture For Windows, it's one of the previous 2: "vcredist_x64.exe" for 64 bit, and "vcredist_x86.exe" for 32 bit.
×