Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[WxTech]

We're 180 degrees out of phase in our little typing exercise!   

Interesting oddities you're getting. My 'corrected' House.class classfiles may not have been required after all. And it seems that perhaps the latest B.A.T. House.class has not been changed...

Just why your message omited "Vehicle" from the allowed body types is really puzzling.

Yes, you could add from your 'stock'/older static.ini those objects not present in mine as I had supplied. If the object count is not very different, this could well be the fastest way to make the changes, as my total number of reassigned body types is in the range of a thousand, if memory serves.

If you have a file compare utility, this task could be made very easy.

[Old_DaD]

I hope this doesn't mean the dreaded re-install of BAT 4.2....etc.
But..probably like you, I'm a bit jaded with it all now.
Will look at it with fresh eyes, after Murine of course.

[WxTech]

To reiterate. If one's static.ini is fundamentally nearly the same as mine (from B.A.T. 4.0, with some additions), then using mine in its entirety, adding any objects from one's existing static.ini to mine, could be a quicker way to update the many hundreds of body type reassignments. A file compare utility should make the work easier, identifying object titles missing in my static.ini.

I realize that this creates a not small amount of work, requiring some care. Just keep a backup of one's original, working static.ini and all will be retrievable in case of a screw-up.   


I'll stress again that the effort will pay dividends in effect variety and appropriateness, as well an easement on resource requirements in a number of scenarios.

[WxTech]

I hope this doesn't mean the dreaded re-install of BAT 4.2....etc.
But..probably like you, I'm a bit jaded with it all now.
Will look at it with fresh eyes, after Murine of course.

If using my static.ini results in no errors due to the new 'Vehicle' body type, this bodes well. I don't get the feeling that something as drastic as a full game re-install is called for.

[Old_DaD]

I'm already on it. .a small mammoth task but as said .. perseverance.

[pied]

From the peanut gallery, I used WxTech's static.ini in its entirety and added in the entries that were missing from my working one. Luckily I keep a list of what I've added to these files, and it works a charm.

Pied

[Old_DaD]

Good day.
Just did a classcheck.exe to ..um..check classes..I noticed this entry:
8D6CE2FE0EE939B2 exists with :
   CRC 3117cd48 :   .\#WAW3\!!0_WxTech_Effects_v1.6_ALL-game-versions\8D6CE2FE0EE939B2

   CRC -49d17fa2 :   .\#WAW3\!!!WxTech_GUN_classes_ALL-game-versions\8D6CE2FE0EE939B2
I Have GUN classes above Effects v1.6 in my #WAW, at this moment.
Is that hierarchy ok? or should I swap them over?

[Old_DaD]

And thanks to all helpers.."Vehicles" body type  is now being recognised.

[WxTech]

Good catch on that duplicate classfile, POPS.   I've added instructions in update #5 in the top post to retain the version of this classfile (Bullet.class) that resides in the main effects folder, and discard the version in the GUN classes folder.

[WxTech]

I've encountered a strange video artifact not seen before. It seems to result from a change I recently made as part of disabling the drawing of the brief  'starburst' smoke for the small calibre flak bursts.

If you use the subsequent small update I offered (linked to in UPDATE #3 in the top post) for making the small calibre flak bursts more prominent, this WILL NOT apply to you.


If, however, you use my flak burst effects as provided with the base effects pack, this WILL apply to you...


Navigate to the following TWO .mat files:

  !0  WxTech_Effects_v1.6\Effects\Explodes\Air\Zenitka\Germ_20mm\FlakBurst.mat
  !0  WxTech_Effects_v1.6\Effects\Explodes\Air\Zenitka\USSR_25mm\FlakBurst.mat

For each of these two FlakBurst.mat files, change

  tfNoTexture 1

to

  tfNoTexture 0

You may delete any text--residing on the same line--following the number


It would seem that setting this parameter to "1" causes an odd visibility aspect that can cause brief but awful, bright artifacts on water and sky. I discovered it while playing the Kamikaze 02 track, with manual view control.

And recently, while working on the Hawk 75 cockpit, I found that for a .mat file where I also desired invisibility for a small object, setting tfNoTexture 1 caused the object to be unexpectedly visible. My surmise is that this parameter is intended to make an object remain visible as a monochrome shape but with no texture mapped to it. The parameter/setting which properly renders an object invisible is tfModulate 0.

[blackshark]

Hi, anyone tried it with 4.10/DBW ?

@WxTech: on your opinion which configuration should I try in DBW 4.10 ?

[WxTech]

I've never used DBW. I suspect there will be some fundamental difference somewhere that will preclude the incorporation of this massive, far-reaching pack. There are a number of fundamental base classes that I've touched, just for starters. Even merely trying just the base effects folder and only the 18 classfiles pertaining only to Explosions.class might not work due to a new dependence on another class, which permits the new differentiation in effect invocation for crashing planes based on the number of engines.

Perhaps you could try v1.5's main effects folder, and its Explosions.class files. That would give you a better chance at at least obtaining the bulk of the new effects. But there could result issues with ship wake effects, which we can deal with then...