modemmaik

This defines the way arma loads the modules: requiredAddons[] = {"Cold_War_Rearmed", "CAWeapons"}; This way, the class Cold_War_Rearmed must be activated before the changes are activated. To my very own surprise... because the correct definition for your case should be: requiredAddons[] = {"CWR_weapons_rifles"}; This way, the CWR_weapons_rifles should be activated before changing the sounds.

Just a suggestion: Check chamis soundmod config for a proper soundmod configuration config.cpp. You included more or less the complete weapon config in your mod, which may cause conflicts, when the CWR team releases their patch. E.g.: your version: class KozliceShell : Rifle { scope = private; displayName = $STR_DN_KOZLICE_SHELL; sound[] = {"\ca\Weapons\Sound\kozl_single.wss", db0, 1}; drySound[] = {"\ca\Weapons\Sound\M16dry.wss", 0.01, 1}; reloadMagazineSound[] = {"\ca\Weapons\Sound\kozl_load.wss", 0.000316, 1}; ammo = "KozliceShell"; count = 7; multiplier = 1; burst = 7; division = 7; dispersion = 0.0001; soundContinuous = 0; reloadTime = 0.001; magazineReloadTime = 3; ffCount = 1; recoil = "sniperSingle"; recoilFixed = "riffleSingleFixed"; autoFire = false; aiRateOfFire = 5.0; // delay between shots at given distance aiRateOfFireDistance = 500; useAction = false; useActionTitle = ""; }; this will also do the job: class KozliceShell : Rifle { sound[] = {"\ca\Weapons\Sound\kozl_single.wss", db0, 1}; drySound[] = {"\ca\Weapons\Sound\M16dry.wss", 0.01, 1}; reloadMagazineSound[] = {"\ca\Weapons\Sound\kozl_load.wss", 0.000316, 1}; }; BR, mike :edit: I have uploaded such a "stripped" config to pastebin.com. Not very well tested, just to give you an idea ;)

Nice one :) Especially the rings in the sky :bounce3: @Sumrak: Very, very well done :eek:

Tanks for the info, but: Such an issue needs to be fixed in the model (pilot's position)... But usually the view of a person seems to be aligned with the left eye, causing this issue. So I am not sure weather thix is fixable without causing another issue.. But we will see ;) I think you are talking about the Mi 24V CAS pods. Well they fired FFAR before and I intended to fix the issues only, not to include new features... BR, mike

I have trid to fix the 1.14 issues and contacted Shadow NX for release permission. He gave me the permission after a check. DL-Link Modem's RHS Hind 1.14 fix @Hosters: Shadow NX mentioned that the RHS-Hind 1.0 addon should get a link to this fix, to pervent further issue reports ;)

It seems that Vilas has permission to do this job. His latest pics shows a Hind, very simmilar to the RHS one. BR, mike

Can you post a pic of your problem? Most of the "clipping" problems can be fixed by "sharp edge"-ing in O2. Other "shadow" issues on transparent faces can be solved by using non-shadow rvmat's. E.g.: First (assigned) rvmat: ambient[] = {1.000000, 1.000000, 1.000000, 1.000000}; diffuse[] = {1.000000, 1.000000, 1.000000, 1.000000}; forcedDiffuse[] = {0.000000, 0.000000, 0.000000, 0.000000}; emmisive[] = {0.000000, 0.000000, 0.000000, 1.000000}; specular[] = {1.000000, 1.000000, 1.000000, 0.000000}; specularPower = 5.000000; renderFlags[] = {"NoAlphaWrite"}; nextPass = "modem_tiger\tiger_glass_2nd.rvmat"; PixelShaderID = "Glass"; VertexShaderID = "Glass"; class Stage1 { texture = "#(ai,64,64,1)fresnelGlass()"; uvSource = "none"; }; class Stage2 { texture = "ca\air\data\materialy\env_co.paa"; uvSource = "none"; }; 2'nd stage rvmat (tiger_glass_2nd.rvmat) ambient[] = {1, 1, 1, 1}; diffuse[] = {1, 1, 1, 1}; forcedDiffuse[] = {0, 0, 0, 0}; emmisive[] = {0, 0, 0, 1}; specular[] = {0, 0, 0, 0}; specularPower = 0; PixelShaderID = "AlphaNoShadow"; VertexShaderID = "Basic"; renderFlags[] = {"NoColorWrite"};

Hi wld427. I noticed that vilas merged his weaponpacks into the P85 release. Because your UN-troops needs the GWP, the GWP might conflict with P85 installation. Or do you plan to switch the P85 for inf-weapons at the next release?

Hi RicoADF, I found an interesting comment about this "missing material" issue: The binarization process removes "unused" materials (rvmat's not used in the model, but used as damage materials). BR, mike

I detected some issues: - Tiger and CH47 seems to have some materials missing: - You use a 3-man config for the M1A1, so the loader gun muzzle is visible. When you use a 3-man config, you may remove the corresponding zasleh from the model to fix this issue. - The ASLAV Bushmaster seems to fire from the mainguns position. BR, mike

The BI samples include correct ural model including the hitpoints for the tires (to my very own surpise, the hitpoints are named levy/pravy predni/zadni tlumic...). For config's purposes, I used the Truck5tMG as base class for my wheeled vehicles, so I guess your Damagetextures, HitLFWheel etc. are correct. The model.cfg shows the corresponding sections: class CfgModels { class Default { sectionsInherit=""; sections[] = {}; skeletonName = ""; }; class Car: Default { sectionsInherit="Default"; sections[]= { ... "levy predni", "levy prostredni", "levy zadni", "pravy predni", "pravy prostredni", "pravy zadni", ... };

Congratz and thanks for the release And greetings to "down under" :D BR, mike

Well... Leo 1A5 tracks are moving on my rig... I tried to check the wheelspeed with some models, but no luck. You may modify the wheelspin by setting the maxValue in the mode.cfg's Wheel_kolxxx animation to a value > 1.0, and it looks good in the buldozer, but the wheels in game do not spin full 360 degrees... :( Each tank including bigger wheels than a M2A2 wheel has this effect (M1A1 etc.). wld427: Big thanks for you hard work :bounce3: BR, mike

I just noticed that your milestone included "all units". Does that include the OFP M2A2? While using OCA with your CWC demo, I noticed that the Demo-BMP includes the same "non-commanding" issue, as discussed lately with Rygugu's T-55A (got sovled by adding a fakeweapon to the commanding position, including all needed points in the memory LOD). Looking forward to the next release of CWR. :bounce3: BR, mike

Looking good Oooh, memories pop up, when I saw them the first time on my rig :bounce3:

Well, the breaklights on my rig are "square", but I recon this as minor: zShare pic link Well done wld427 (once more) :D BR, mike

The commanding differ a bit from BWMod values (com=3, gunr=2, lodr=1 drivr=0), so I agree to namman2. At the moment, loader and driver have the same commanding values (=0). Well, one suggestion: The maingun always hits the same position, independent from the ammunition. I would suggest to replace the magazines initSpeed value with matching values (e.g. WGL's 3OF32 has initSpeed=700, BM8 initSpeed=1415, BK17initSpeed=800), if you want to have an impact of muzzle-velocity depending on ammunition type. @Nick: I think that is the treads-sound. Old and rusty :D BR, mike :edit: Just located the root cause of the obsGun message: You have gun = "ObsGun"; defined in you commaderOptics. To fix this, replace this by gun = "";

I think you refer to the commanders / loaders inablility to give commands via the menu, which is related that those positions do not have a gun. Just had a quick check of your config. May be you can fix the "command issue" by adding a fake weapon to the commander: config.cpp sniplet: class CommanderOptics : CommanderOptics { weapons[]={FakeWeapon}; magazines[]={FakeWeapon}; body = "ObsTurret"; But this raises another issue, because the "FakeWeapon" needs a complete gun config (gunBeg, gunEnd, memoryPointGun) for the commander's turret, else the 3'rd person view is static. Also it may be possible to have the dskhm in a static position, while the loader has hatch closed. model.cfg sniplet (I dunno the gunnerhatch axis. I used ?? for the axis): class GunTurret_close // traverse to 0.0 degrees when driver hatch is closed { type="rotation"; source="hatchGunner"; selection="Gun_2"; axis="??"; animPeriod=0; memory=0; minValue=1; maxValue=0; angle0=0.0; angle1=0.0; }; But I am not sure, weather this works... ;) Your model.cfg.txt does not include any ObsGun animation, which is correct for you case... I wonder where the the message comes from (Turret gun ObsGun not found while initializing the model bds_t55\bds_t55.p3d), but may be your actual model.cfg includes a ObsGun definition, which is to be removed. BR, mike

Congrats on the release of this wonderful tank :bounce3: It seems that the 3'rd LOD texture is not included (check in the armory shows a white hull on distance). I have noticed, that this tank shows disabled hitzones. Well done. Excellent work on the upper side of the tracks, because they move with the wheels :eek: What do you issue by this in detail?: "The commander's command is not made good. I have no idea." BR, mike It seems that ObsGun animation is included in the model.cfg, while the .p3d does not include a "ObsGun" section. You may solve this by removing the obsgun animation from the model.cfg. rygugu, PM me if you need support. I am a bit busy at the moment, but there should be enough time to fix those issues. Alternatively, open a thread at ofpec. One of those guys fix all the config-bugs ;)

Sorry, when I return to the first post: So you simply have to rename the hit-point naming for the motor (e.g. xmotor). class SkodaBase: Car { class HitEngine {armor=1;material=60;name="xmotor";visual="motor";p assThrough=1;}; }; This should disable the hitpoints for the motor section. Hit's on the front will be counted to the "telo" or "karosserie" section so the vehicle will not get indestructible. Btw: This is the default for the BMP-2. That is why the BMP survives a direct AT-hit :rolleyes: In-game check of config: Use Helijunkie's Config-Explorer

Well, this effect mostly depends on the used materials (.rvmat-files) and the .smdi textures. The material is assigned in the O2's "Face properties" (E-menu). for example the "standard" BI-rvmat file: ambient[]={1.000000,1.000000,1.000000,1.000000}; diffuse[]={1.000000,1.000000,1.000000,1.000000}; forcedDiffuse[]={0.000000,0.000000,0.000000,0.000000}; emmisive[]={0.000000,0.000000,0.000000,1.000000}; specular[]={1.000000,1.000000,1.000000,1.000000}; specularPower=70.000000; PixelShaderID="NormalMapSpecularDIMap"; VertexShaderID="NormalMap"; class Stage1 { texture="smurfct72_nsv\t72_nsv_nohq.paa"; uvSource="tex"; class uvTransform { aside[]={1.000000,0.000000,0.000000}; up[]={0.000000,1.000000,0.000000}; dir[]={0.000000,0.000000,0.000000}; pos[]={0.000000,0.000000,0.000000}; }; }; class Stage2 { texture="smurfct72_nsv\t72_nsv_smdi.paa"; uvSource="tex"; class uvTransform { aside[]={1.000000,0.000000,0.000000}; up[]={0.000000,1.000000,0.000000}; dir[]={0.000000,0.000000,0.000000}; pos[]={0.000000,0.000000,0.000000}; }; }; The metal-effect depends on the specular values (100% specular for RGB and specularpower value of 70). The smdi-texture defines how "reflective" the area is. I usually invert the colors of the smdi texture for editing. This way, the specular / non-specular areas are easier to detect. There is also a easy was to define a material without nohq and smdi: Simple material: ambient[]={1.000000,1.000000,1.000000,1.000000}; diffuse[]={1.000000,1.000000,1.000000,1.000000}; forcedDiffuse[]={0.000000,0.000000,0.000000,0.000000}; emmisive[]={0.000000,0.000000,0.000000,1.000000}; specular[]={1.000000,1.000000,1.000000,1.000000}; specularPower=70.000000; PixelShaderID="NormalMapSpecularDIMap"; VertexShaderID="NormalMap"; class Stage1 { texture = "#(rgb,8,8,3)color(0.5,0.5,1,1)"; uvSource="tex"; class uvTransform { aside[]={1.000000,0.000000,0.000000}; up[]={0.000000,1.000000,0.000000}; dir[]={0.000000,0.000000,0.000000}; pos[]={0.000000,0.000000,0.000000}; }; }; class Stage2 { texture = "#(rgb,8,8,3)color(1,0.01,1,1)"; uvSource="tex"; class uvTransform { aside[]={1.000000,0.000000,0.000000}; up[]={0.000000,1.000000,0.000000}; dir[]={0.000000,0.000000,0.000000}; pos[]={0.000000,0.000000,0.000000}; }; }; You may assign such a simple material and play with the values, if you want to. #(rgb,8,8,3)color(0.5,0.5,1,1) is a standard blue color, used as nohq it generates a plain surface. You may modify the first 2 values (0.5,0.5) to modify the surface direction (normal vector of the surface). #(rgb,8,8,3)color(1,0.01,1,1) is a magenta style color, creates a standard reflection when used as smdi. You may modify the first value (0.01) to modify the "reflectivity" of the surface. As an exaple, you may check the M2 bradley unbin version. I included materials with and without smdi / nohq textures. BR, mike

I might be wrong, or at least, I do not know it exactly :o The Proxies are numbered in the config (proxyIndex), so when you add a proxy, take care to set the correct proxyIndex in your turret-config. example from BI sample air config.cpp:

Rotor-Speed is definitely lowered on all but CIV and UN-version. You can simply modify those values using a repl-config :) But your "green"-parts are still moving... But the unarmed versions seem to include more than a pilot in the config. You may check this using the armory (civ-version shows one more pilot running around the chopper.). But, as stated before, just minor issues. Good work and thanks for those additional beauties mike :edit: Found it... civ version includes hasgunner=1, but the choppe has no gun-turret. hasGunner=0 should fix this ;)

I think, that you find some very good examples in the BI samples. Check the BMP or the BRDM, they should match your ATV most. Also check the face properties in O2 (E and shift-E after face selection), because they influence the way the face looks. The samples also include good exmples for bump- and specmaps.

Now I got you... sorry this was a missunderstanding :( In reality, the green part does not move, am I right? But even the BW-mod UH-1D has this part rotation... I am totally confused about that... but you are right (0.34-0.36 shows the lower part is not moving).