Jackal326

Sorry about the late reply, I thought I'd posted one but apparently hadn't hit "post" Anyway, the alphas for lens textures is determined by the alpha channel in the texture itself. The RVMAT has little/no bearing on the alpha and is only used to simulate reflectiveness and/or slight curvature of the lenses with normal maps and smdi textures.

After doing so ensure any/all faces are part of the correct named selections for animating etc.

"Yeah, hi game developers, would you mind adding the paid DLC that was created by a third party and licensed by yourselves to the main game so people don't have to pay for it?" That sure is a good way to go about business

That doesn't look like proxy triangles to me, that looks like a broken shadow lod with unclosed, unsharpened and non-triangulated faces...

I'm not going to pretend to be an expert, but most modern systems should be able to contend with 2k resolution, so long as your model isn't using lots of them.

I am of the belief that rendering in-game and overall performance is impacted more by the number of sections the model has, so one 2k texture is better than multiple smaller ones. Something to do with draw-calls or some-such...

Short answer, no. Long answer, there used to be a tool that allowed you to un-binarize a model and extract the model.cfg. I think it was made by Mikero. It was more for educational purposes to learn how something was animated/coded etc rather than a practical "edit this model.cfg and re-binarize the model" kind of deal as the extracted models were often incomplete or otherwise broken/corrupted - I think this behaviour was intentional as to prevent theft/misuse of other people's work.

There is no such thing as a "simple edit" of a model.cfg as it is Binarized into the models themselves and cannot be directly edited.

You can sort all of the faces that use a particular texture to be part of the same alpha layering. You can do this by opening the texture library window with ALT+T and then double-clicking each texture individually in sequence whilst holding CTRL. This will select all of the faces that use that one particular texture. For the sake of your own sanity it would be worth at this stage then pressing E, to view the Face Properties window and making sure that all of the faces selected are using the same RVMAT. I've had it happen in the past where some faces haven't had the rvmat assigned or with Object Builder being rather fussy about things being CaSe SenSitiVe and some faces having lowercase and some having uppercase .rvmat extensions etc. Once you've determined all faces have the correct/same texture/rvmats combinations, you can then move each texture through the alpha sorting with CTRL+SHIFT+END/HOME to move them to the bottom/top respectively or CTRL+SHIFT+PgUp/PgDn to move them one layer up/down respectively. Be warned, faces that use _ca.paa or other textures with transparency will need great care when using alpha sorting as it can cause parts of the model *above* the transparent texture in the sorting to become invisible when viewed through transparent texture parts. Once you've done this for all textures in the LOD, you should hopefully have reduced you section count down to 5 (4 textures and 1 unmapped part, presumably a proxy) - I'm not sure if its the correct method, but in the past I have mapped textures/rvmats to the proxy triangles in a bid to further lower the section count by one and haven't seen any adverse reactions.

The first (blue) entry is the unit defines, this is where you define the characteristics of the character that wears the uniform. The second (yellow) is the define for the uniform itself where you detail its carrying capacity and display image etc. Using the same classname for both is a bad idea, your best bet would be to adjust not only the classname but also the unit's displayName for the first (blue) entry as currently it would show up as 'IRI [Commander_uniform]' in the editor's unit list and personally I think that might look weird. You can safely remove the blue model line without causing any issues as the uniform takes its model from the uniform define (the yellow one).

Then...just remove one...I'm not really sure I understand your problem.

The modelOptics parameter as I've explained is not for what you're trying to accomplish. Your best bet for 2-step magnification scopes would be to code it like the HAMR or similar scope that has back-up iron sights, except instead of coding BUIS you code a second scope-view with higher (or lower) magnification. Something like the following (though I've just written this now so its untested): class ItemInfo: InventoryOpticsItem_Base_F { mass = 8; // whatever "Weight" you want...its mass/encumberance but whatever opticType = 1; optics = 1; modelOptics = "path_to_your_optic_view_model\2dscopeview.p3d"; class OpticsModes { class LowMagnification { opticsID = 1; useModelOptics = 1; opticsPPEffects[] = {"OpticsRadialBlur1","OpticsBlur1"}; opticsFlare = 1; opticsDisablePeripherialVision = 1; opticsZoomMin = 0.0623; opticsZoomMax = 0.0623; opticsZoomInit = 0.125; memoryPointCamera = "opticView"; distanceZoomMin = 500; distanceZoomMax = 500; }; class HighMagnification { opticsID = 2; useModelOptics = 1; opticsPPEffects[] = {"OpticsRadialBlur1","OpticsBlur1"}; opticsFlare = 1; opticsDisablePeripherialVision = 1; opticsZoomMin = 0.125; opticsZoomMax = 0.125; opticsZoomInit = 0.125; memoryPointCamera = "opticView"; distanceZoomMin = 300; distanceZoomMax = 300; }; }; }; Like I said above, that is untested code I can't guarantee will work... I didn't make all the stuff in the SJB weapons packs, many of the models were donated by other authors and were then imported/converted/tweaked by me. I wrote all of the code though... As far as tutorials go, I'm far from the most knowledgeable when it comes to weapons/optic configuration so I doubt I'd ever go so far as to write a tutorial on the subject. The best I can offer is this page on the BIKI which has a few helpful tips I've used in the past.

OK so the only other issue I can see at a glance is the modelOptics path is the same as the model path. These two parameters do two different things: model defines the model to use as the main appearance of the attachment and modelOptics is used to define a 2d plane model that simulates looking through a scope. Then within the scope subclass you have an array for modelOptics presumably defining different reticles, but they're textures and not models? Might be confusing the game doing that... Below is some code that is less janky and I know works, in case you want to test if its broken code that may be causing the issue: class SJB_AR_AimpointCompM4: ItemCore { scope = 2; displayName = "Aimpoint Comp M4"; model = "\SJB_A3_WeaponsCore\data\attachments\Rifles\Aimpoint_COMPM4.p3d"; picture = "\SJB_A3_WeaponsCore\data\inventory\sjb_acc_compm4_ca.paa"; descriptionShort = "Red dot sight"; weaponInfoType = "RscWeaponZeroing"; class ItemInfo: InventoryOpticsItem_Base_F { opticType = 1; mass = 7.4; RMBhint = "Optical Sight"; optics = 1; modelOptics="\A3\Weapons_F\empty"; class OpticsModes { class ACO { opticsID = 1; useModelOptics = 0; opticsZoomMin = 0.1875; // was 0.375 opticsZoomMax = 0.505; // was 1.1 opticsZoomInit = 0.375; // was 0.75 memoryPointCamera = "eye"; // memory point simulating the user's "eye" position when aiming opticsFlare = 0; opticsDisablePeripherialVision = 0; distanceZoomMin = 200; distanceZoomMax = 200; cameraDir = ""; visionMode[] = {}; opticsPPEffects[] = { "OpticsBlur1" }; }; }; }; }; Granted that is for a red-dot scope but I I am that confused by what you're trying to code it may or may not help you...

Its possible its the position of the scope itself in the X/Y/Z axis of the model. As such the scope may well be showing, just not attached to the weapon and may be floating around somewhere...

You might be right, I've never played around with configurating custom 40mm or similar so I couldn't speak to whether or not that is the case 🤷‍♂️

Perhaps a combination of map being played on and PiP (Picture in Picture) settings used for the optics? Without more precise info its hard to say...

Have you tried verifying the integrity of your game cache, as the error message suggests?

Try unpacking 'language_f_enoch.pbo' and then search the 'stringtable.xml' file for the strings you require.

What do you mean "try to put a bigger distance"? Do you mean changing the zeroing of the weapon? If so the reason that isn't working is because you haven't altered any code referring to zeroing... discreteDistance[] = {100,200,300,400,500,600,700,800}; discreteDistanceInitIndex = 2; The first line defining distances at which the weapon can be zeroed, and the second line being the starting/default zero range of the weapon, taken from the line above it with the first entry being 0 (so in the above example 0 = 100, 1 = 200, 2 = 300 etc.)

There is an existing thread for searches such as this...

If it were easy, you'd have no doubt done it yourself... So after searching the Wiki I've found a few classnames associated with parachutes - I have no idea if any of them are the right one but its up to you to try them out. B_Parachute NonSteerable_Parachute_F Steerable_Parachute_F B_B_Parachute_02_F B_I_Parachute_02_F B_O_Parachute_02_F B_Parachute_02_F I_Parachute_02_F O_Parachute_02_F

This link to the BI WIKI might help you...

Not for the way you're using it, it should™ work fine. If you were for example to make changes to any code contained within sub-classes, e.g. class HitPoints, without first defining the external reference for the base class, either your changes wouldn't work or the config would throw unknown baseclass errors at you. As far as I can tell for what you're wanting to do the abbreviated code should™ be fine.

I used to get similar crashes when playing 'Hell Let Loose' with the exact same black screen and topped-out GFX card fan speed combo - it sounded like my PC was damn close to taking flight. Updating my GFX card drivers seemed to resolve the issue but if you're still having issues with having already done that, perhaps try rolling back a version or two until you find a version that (hopefully) fixes it.