logan4

Do you also use the standard Insignia.tga decals-s on the meshes or just the camo decal that includes the national insignia itself? If it is a separate insignia.tga then probably that what lightens up the overlapping section and causes the flickering issue too. Also keep in mind then number of max decals per mesh.

Good day for everyone. As in the title, it is the time for this year's virtual airshow. The event actually started on 12 nov. Today is its 2nd day. Live feed is from 17:00(GMT) to a bit after 22:15(GMT) Link for live feed (at the same place you can review the recordings from yesterday's event): https://www.twitch.tv/virtualairshows https://www.twitch.tv/virtualairshows/v/100707504 Schedule: https://docs.google.com/spreadsheets/d/17qvhoUpQuNrs3g3-uGDvyQ--osgQwUgNuiJku348uLE/edit#gid=2120745992 Enjoy it!

Not sure if the right ones but try to play with their parameters: RollInRange RollInAlt PullOutAlt PullOutRange ReleaseRange

It's OK kurdistan1. Everyone can get frustrated from time to time. Proper wordings can help to lessen the effects of miss communication or occasional argument. True we have slightly less models coming out recently but it does not mean there are none in the works. Life can throw around us in ways we not anticipate or sometimes have to miss modding due to other duties or deployments. I for example, in the last 3 months have 12hours shifts 6 times a week, so way less available time to wrap up the things that are almost release ready, compared to times I had only 5 times 8 hours of work. And there are many of us can have such changes. If you look back for several years interval, there were always ups and downs in the amount of mods being released. It is a "natural" phenomenon, just like tidal periods, but you have to be around to notice it. Personally I started modding so I can fly things we do not have yet in game or in few cases just see how my own designs would look in "real". You already have most skills you need to jump in the pond, if you think you can not, be brave, I did not know anything about 3ds max modelling and even less about animating anything. With patience anything that required can be learned/mastered. There are many topics and many good videos that can help clear out some issue, and if all else fails someone can always ask for help.

Creating a data.ini might take a while. I would suggest for a quick tests - use an already existing data.ini from a plane that looks similar in shape and layout as the bird you work on. Correct weapon station positions, mesh name call outs of major and sub components (wings,nose,stabs,gearsystem,engine,pilot,etc,etc.) Then adjust min/max extents and collision points, fueltank and light positions, speed,size and range parameters. After that you can dive into the more complicated ones which makes your bird handle as you wish. This later would be more time consuming, but even if you get the urge to just quit it - carry on with the adjustments. SF1 and SF2 knowledge base has several posts about certain aspects of it, that might help you with it or shed a light on. The FM is the trickiest of all and I personally have no full knowledge of the quirks of every part of it so can not advice you on that - I do know it takes lots of editing, testing, editing, testing and so on till you satisfied.

2 - Sometimes life gets into your way and slows things down. Does not mean that work will not be resumed on those projects whenever that is possible from the side of the modeler. Just a side info, due to time availability in Real Life several projects are going on for years before it can get into release status. Certainly betas can be punched out quickly, but then comes the nagging about certain points that "user" dislikes and complains about and the creator of the work had no time to iron out yet even when he had plan to do those modifications himself for final release. Also there are project "priorities" what a modeler would like to finish first, second, third, etc. I think I can say in the name of others: we work on models specifically for that reason, because they are NOT in our games, if they were there already then we wouldn't need to create them. 1 - Depend on the modeler and how that was made. FSX and X-planes have their own program that can create models and it is not that simple to port over, sometimes you need a 3rd party exporter/importer that might not free at all. Secondly the creator of the model might not even work or use SF series titles so why he would take the hassle to convert one for it. Beside that sometimes an AC is over detailed for other titles and would require quite some time to make it less system heavy, so your SF2 game engine can run it without a hick-up. Also an other aspect that the creator of certain models are not agreeing to convert/use their work in other titles or simply not share source files so can be converted by someone else - and they have a right to it, their product, their work. Patience young padawan. Creating an AC in modelling software is not that too different from a house - although for this later there are specialized software that makes it easier and simpler for the user, but if you use autodesk architect then you have more than half of the know-how to make one without much of a trouble. You only need to get used to round shapes and their connections and how to work with smoothing groups, etc.

I would say, probably the engine components were mirrored and the axis of the upper part was not reset to world alignment. The other thing is, the trust vector control swivels the exhaust from the center point of the engine afterburner mesh thus it will always tilt away with that long rotation arm. Not likely that you can get around it without adjusting the source file and reexporting the lod.

I use this settings. I never use opacity on those materials. This is for Yakarov, on the Ch53 mirrors, since in the file release thread attaching pictures works a bit differently.. Regarding your question on the mirror. Depend on how you mapped it. if you mirrored the right side one from the left without flipping the mapping in 3dsmax then will show mirrored left side picture. This is the mapping of your mirror's mesh. the bellow shows what I have for the M4k mirrors. So wherever you place them on the UVW they will show those areas or certain overlaps in case of multiple meshes. Only they will show a bit above rear view, never perfect side image like on the cars/trucks, that part is probably coded in.

RADAR_IN_RANGE_INDICATOR - is a function that shows you the target you are locked onto is in range of your selected weapon (radarhoming/irm) marked with white on the pic. RADAR_RANGE - is a function that shows you via a light what is your selected radar range. If you look at the F-4 it has the range lights on the right side of the radar base 5,10,25,50 miles it is that, other example A-7E. I personally never used RADAR_RANGE_SETTING yet so a wiser one will have to chime in.

I do not think that kind of counter exists in our game... in Real Life can be set up something like that, but we do not have such. The above is the closest you will get to it as "consumption".. You can set up a TOTAL_FUEL_QUANTITY_INDICATOR which will show your total amount (internal+external) then count back to 0. This is the most common way.

You can use the one I put in the bottom of post#22, works perfectly and would be fine for the SE, the same way I have it in the M4K only that is digital.

I think it is KG/Sec and also can be LB/Sec in game. Fits more the flow rate I see.

In theory should move on both cases. What controller you use for it? FLAPS_CONTROL_HANDLE or FLAP_ANGLE or EXTERNAL_ANIMATION_LINK? Should work with something like this. [FlapLever] Type=FLAPS_CONTROL_HANDLE NodeName=Flap_Lever MovementType=ROTATION_X Set[01].Position=0.0 Set[01].Value=0.0 Set[02].Position=25.0 Set[02].Value=1.0 Set[03].Position=45.0 Set[03].Value=2.0

I think with the analog altimeter the main issue was that you used Type=Pressure_Altimeter_3. And my bad on the scaling parameter instead of Scale=10 should be Scale=0.1 I normally only use the simple Type=Pressure_Altimeter without any numbering and works fine with 4 or even 5 digit counter. As you can see it on this pic. I set up 2 analog counters beside my digital counter instrument for comparison. The 4 wheel counter works with 10feet on last digit the one bellow with 5 wheel works on single feet. These are the setting I used for it, no need for anything else with position/value parameter. [AltimeterAn1] Type=PRESSURE_ALTIMETER CounterNodeFormat=Altan_dig%d MovementType=ANALOG_COUNTER ValueUnit=FEET Scale=0.1 <----will show 10ft increment [AltimeterAn2] Type=PRESSURE_ALTIMETER CounterNodeFormat=Analt_dig%d MovementType=ANALOG_COUNTER ValueUnit=FEET Scale=1 Regarding the fuel flow it can be analog counter. As the pic show works fine.The only thin with KG unit is that need to use scale value as not sure if it measures in KG/sec or Kg/min. As on the pic, it works OK. These are the settings for it: [FuelFlowCounter] Type=FUEL_FLOW_INDICATOR CounterNodeFormat=FFlow_dig%d MovementType=ANALOG_COUNTER ItemNumber=1 ValueUnit=KG Scale=10

If you use a dial type of instrument then rotation axis is mostly _Y not X - unless you turn its pivot. If you use a dual digit (tens) for the "single" analog counter node then use "Scale=10" otherwise would not count properly. As Yakarov showed do not put underline in the format dig_% it is only dig%. For a weapon type selector you have on the pic, use something like the bellow example. You might have to fiddle with the degrees value depend on if you use a needle or the plate to move. on a dial like instrument/rotating object the position part is always in degree, the value section in this instruments relate to weapon types as listed in post#3 sectionB [WPSelector] Type=WEAPON_TYPE_SELECTOR NodeName=WPselect MovementType=ROTATION_Y Set[01].Position=-90.0 Set[01].Value=1.0 Set[02].Position=-90.0 Set[02].Value=2.0 Set[03].Position=-90.0 Set[03].Value=3.0 Set[04].Position=90.0 Set[04].Value=4.0 Set[05].Position=0.0 Set[05].Value=5.0 Set[06].Position=0.0 Set[06].Value=6.0 Set[07].Position=0.0 Set[07].Value=7.0 Set[08].Position=90.0 Set[08].Value=8.0

Denis, you do not need to use the itemnumber=1 in that statement. Yes, I know might be confusing, but sometimes you can get away with things like this. I use the bellow way and works OK. Depend on how you have the lever in the pit model, you sometimes need to flip values in the cockpit.ini [LandingGearLever] Type=LANDING_GEAR_INDICATOR NodeName=Gearlever MovementType=ROTATION_X Set[01].Position=-45.0 Set[01].Value=0 Set[02].Position=0.0 Set[02].Value=1 Other things can be as Cliff7600 wrote.

Might be not all of valueunits.. NM FEET LB KG KM METERS DEG KNOTS KMPH MPS FPM My last post above (nr8) about set(x)position/value parameters only reflect the Position_x/z/y as that was the question. If you have Rotation_X/Z/Y or Light then the range can depend on the instrument you try to make. [Light_Bingosys] Type=BINGO_FUEL_INDICATOR NodeName=Light_Bingosys MovementType=Light ValueUnit=KG Set[01].Position=1.0 Set[01].Value=0.0 Set[02].Position=1.0 Set[02].Value=550.0 Set[03].Position=0.0 Set[03].Value=600.0 Set[04].Position=0.0 Set[04].Value=9000.0 [VelocIndA] Type=AIRSPEED_INDICATOR NodeName=VelocidadIndicada MovementType=ROTATION_Z ValueUnit=KMPH Set[01].Position=0.0 Set[01].Value=0.0 Set[02].Position=1080.0 Set[02].Value=3000

The bellow is an example of a rudder pedal moving linear way [LeftRudder] Type=RUDDER_PEDAL NodeName=PedalL MovementType=POSITION_Y Set[01].Position=0.05 <---- moved 5cm forward Set[01].Value=-1.0 <---- right max input Set[02].Position=0.0 <---- original position Set[02].Value=0.0 <---- no input on rudders Set[03].Position=-0.05 <---- moved 5cm back (toward pilot) Set[03].Value=1.0 <----- left max input Game will move only according the input level you apply on the game control. Set(%d)Position always equals the amount you want to move the object 0.001 is 1mm, as in above 0,05 is 5cm Set(%d)Value always the movement's "triggering" parameter. You can set multiple ones for a single object, all depends on the movements you want to generate. Only rule is, they always go in pairs, meaning you can not have a set(x)position without a matching set(x)value entry. How ever you can use other Value= than 1, if you want an earlier or several response from a switch object, range is 0.001-1.000.

SF2 has few more: BINGO_FUEL_INDICATOR MISSION_TIMER INTERNAL_FUEL_QUANTITY_INDICATOR - the same in SF1 is: INETERNAL_FUEL_QUANTITY_INDICATOR EXTERNAL_ANIMATION_LINK AFTERBURNER_INDICATOR WEAPON_SHOOT_CUE RADAR_BREAK_X WEAPON_QUANTITY RIPPLE_QUANTITY RIPPLE_INTERVAL WEAPON_TYPE_ID CHAFF_COUNTER FLARE_COUNTER AUTO_PILOT ILS_TOGGLE GLIDE_SLOPE_INDICATOR

ItemNumber is a bit trickier than the above mentioned one. It can refer to several things, depend on what entry it is used with. A - With engine related instruments/entries (tachometer/fuelflow/temperature/fire,etc) it always refers to the EngineID in the AC_data.ini, as an example: [TachometerL] Type=TACHOMETER CounterNodeFormat=RPML_dig%d MovementType=DIGITAL_DISPLAY ItemNumber=1 <--- EngineID=1 Scale=100 [TachometerR] Type=TACHOMETER CounterNodeFormat=RPMR_dig%d MovementType=DIGITAL_DISPLAY ItemNumber=2 <--- EngineID=2 Scale=100 Max number of it same as the number of engines exist on the aircraft. B - When it is part of a Type=WEAPON_TYPE_SELECTOR entry it refers to the following 1 - Gun 2 - IRM 3 - Radar guided weapons either SHAM or AHM 4 - Bomb (unguided) 5 - EO weapons 6 - ARM missiles 7 - Rocket Pods 8 - Laser guided weapons An example: [GUN_Selector] Type=WEAPON_TYPE_SELECTOR NodeName=Gun_select MovementType=LIGHT ItemNumber=1 Maybe there are more of it but these are the 8 I know of. C - When it is associated with Type=WEAPON_STATION_SELECTOR entry it refers to the StationID= in the AC_Data.ini. Few examples: [iRM_Station1] Type=WEAPON_STATION_SELECTOR NodeName=Light_IRM1 MovementType=LIGHT ItemNumber=10 <--- StationID=10 [MRM_Station7] Type=WEAPON_STATION_SELECTOR NodeName=Light_MRM7 MovementType=LIGHT ItemNumber=7 <--- StationID=7 [ARM_Station1] Type=WEAPON_STATION_SELECTOR NodeName=Light_ARM1 MovementType=LIGHT ItemNumber=1 <--- StationID=1 [RP_Station2] Type=WEAPON_STATION_SELECTOR NodeName=Light_RP2 MovementType=LIGHT ItemNumber=26 <--- StationID=26 Max number of it same as max number of weapon stations - 32. C2 The same principle can be used with Type=WEAPON_QUANTITY as could be used to show loaded weapon. In modern MFD display environment this is applicable to stations with a dedicated single type weapon station (fueltank/rocketpod,etc) where only that one thing is ever loaded. This solution provides an alternative to the WeaponTypeID system. However you can use it also on old pit variants where there is only a light or simple text that shows loaded/empty state. An example: [RP_Station4load] Type=WEAPON_QUANTITY NodeName=Light_RP4L MovementType=LIGHT ItemNumber=28 <--- StationID=28 Set[01].Position=0.0 Set[01].Value=0.0 <---OFF Set[02].Position=1.0 Set[02].Value=1.0 <---ON C3 If you associate it with Type=WEAPON_TYPE_ID entry to show what type of weapons are loaded/selected, same as the previous two type, it looks for StationID= in AC_data.ini As an example: [LGB_Station2load] Type=WEAPON_TYPE_ID NodeName=Light_LG2L MovementType=LIGHT ItemNumber=2 <--- StationID=2 Set[01].Position=0.0 <---OFF Set[01].Value=60.5 Set[02].Position=1.0 <---ON Set[02].Value=61.0 Set[03].Position=1.0 <---ON Set[03].Value=71.0 Set[04].Position=0.0 <---OFF Set[04].Value=71.5 the Value parameter in this example refers to the items listed under the [WeaponTypeID] system entry in the cockpit.ini, relevant section for comparison. CBU-24B=57 Rockeye=58 xxxxx=59 xxxxxx=60 //LGs BGL400=61 BGL1000=62 AS-30L=63 FR GBU-12D=64 FR GBU-16=65 FR GBU-22=66 FR GBU-24=67 GBU-10=68 GBU-12=69 xxxxxxx=70 xxxxxxxx=71 //EOG-CGR MARTEL_TV=72 AS30=73 D - With gear system related instruments/entries (landing gear indicator/break/open/close,etc) it always refers to the gears in the AC_data.ini. ItemNumber=1 <--- nose gear 2 <--- left maingear 3 <--- right maingear Maybe others but this 3 I use. E - When it is associated with Type=EXTERNAL_ANIMATION_LINK entry it refers to the AnimationID= in the AC_Data.ini. [Canopyhandle] Type=EXTERNAL_ANIMATION_LINK NodeName=Canopyhandle MovementType=ROTATION_X Set[01].Position=0.0 Set[01].Value=0.0 Set[02].Position=40.0 Set[02].Value=1.0 ItemNumber=8 <--- AnimationID=8 Max number can be 10, as only 10 Animation slots exists currently in game's Aircraft models. There could be other applications or meanings but the above are what I know and use.

CounterNodeFormat is actually refers to the individual mesh names that are part of a counter instrument - either analog or digital. The name itself can be anything you give to them, I always try to give names that refer to what instrument or function they serve or for. These can go with instruments as MovementType=ANALOG_COUNTER MovementType=DIGITAL_DISPLAY CounterNodeFormat=Ripint_dig%d Where existing meshes of the counter are the following: Ripint_dig1,Ripint_dig2,Ripint_dig3. Bellow is a sample of it in linking structure. MFD_L_AGmode [13 polys, 13 verts] 'Arch & Design (mi)_18' Light_Ripqty [2 polys, 4 verts] 'Lights' Ripqty_dig1 [2 polys, 4 verts] 'Arch & Design (mi)_19' Ripqty_dig2 [2 polys, 4 verts] 'Arch & Design (mi)_19' Light_RipInt [2 polys, 4 verts] 'Lights' Ripint_dig1 [2 polys, 4 verts] 'Arch & Design (mi)_22' Ripint_dig2 [2 polys, 4 verts] 'Arch & Design (mi)_22' Ripint_dig3 [2 polys, 4 verts] 'Arch & Design (mi)_22' _dig1 shows: single number _dig2 shows: tens _dig3 shows: hundreds In cockpit.ini the above looks such: [Ripple_Quantity] Type=RIPPLE_QUANTITY MovementType=DIGITAL_DISPLAY CounterNodeFormat=Ripqty_dig%d [Ripple_interval] Type=RIPPLE_INTERVAL MovementType=DIGITAL_DISPLAY CounterNodeFormat=Ripint_dig%d Not sure what is the limit. I have digital counters for 5 digit display capability working fine.

No, I'm working on the lower lods that we would like to include in the release packages. Only slow down comes from RL. Main lods are finished for 12 different variants to both SF1 and SF2 and the 10 required different cockpit types and their files are also completed in both game's format. Technically we could come out from the dark, but not having some level of lower lods might hinder weaker machines and probably would cause some upset from the player's side. This way the user could also have a chance to skip the highly detailed lod(s) for a level that suits his/her system.

Hang on Raven. There is sunshine after every storm... Meantime, I wish the best for you and your company.

Your welcome!

Well, right click on desktop, select "Nvidia control panel" On the configure Physix option set up like on the picture and click "apply". Also on the "Manage 3D settings" Either under "global" or "program" settings set the Nvidia card to be used as primary card. If you do it under global, most programs will use it, if required under the "program" settings option you can individually assign the SF2 games to use it. My current laptop has only one card and the other is far away now so can not make a picture of that but you should be able to do it easily.