swambast

Yakarov, thanks - much appreciated! I'm trying to optimize some mesh/textures... The challenge I'm also having is identifying which ones I could collapse and smooth into a single mesh element without affecting something like cockpit functions defined in the _data.ini Therefore, is the only way to ensure I don't screw something up would be to consult the _data.ini and ensure those elements are not selected and their hierarchy maintained?

Yes, of course it does Niels...it can do both (e.g., renumber target entries and target types).

Niels, I have created an arsenal of helpful tools for this series, some private and some public. Anyway, I thought the limit for target limitations was also 999. But more importantly perhaps for you, is that I have a development tool with a built-in targets.ini renumbering function. Feel free to PM me your file and perhaps it will save you a tremendous amount of time and effort...

Ummm...while I applaud performance enhancement efforts, I'm struggling a bit with this proposed solution. That looks to me like a DirectX 9 dynamic link library file...combined with an ENB post-processing file. So of course reverting back to DirectX9 and is going to help with performance, but you do realize you're giving up bump mapping, speculars, etc. under the Gen2 engine, right? Unless I'm misinterpreting something, which could be the case and I'm all ears... Edit: WOW, this is for the Gen1 engine series, not even sure who's left playing that - but anyway, might be better to move this post to that forum rather than SF2 forum?

Hi all, must have messed something up in my modding efforts. I have these unwanted, long "laser beam" tracers on most of my guns. Pretty sure it's related to TRACER.tga. But can someone help me remember what is the fix to reduce the tracer tail length (think it might be an .ini tweak?). Right now when the aircraft is firing, the tracers literally appear behind the wings, like in this example screenshot. Thanks for any guidance!

KJ, thanks for the update - but where specifically would the check be for the generic guns using for example tracer.tga??? Also, I noticed in your tag line you're the "Ground Object Data.INI Guru" - give me a PM when you get a chance as I have something that I think might be extremely interesting and helpful to a modder like yourself...

Hi there, Can someone please refresh my memory regarding the sequencing requirements for Aircraft or Ground Mission entries in a mission file? For example - would both of these scenarios/entries be acceptable? Or must they absolutely be in strict numerical sequence order like in Scenario A only? Scenario A: [GroundMission001] [GroundMission002] [GroundMission003] [GroundMission004] [GroundMission005] Scenario B: [GroundMission001] [GroundMission003] [GroundMission002] [GroundMission005] [GroundMission004] Thanks for any insight!

Geary, are you really sure it's off - and not just the notifications/settings turned off? Did you disable it using the security policy editor and ensure it's actually disabled? Also, try to move the program to the root, like C: drive and try to manually register the .dlls using regsvr/regsvr32.

Hi Geary, man I remember running into tons of issues just like that on a Windows 7 build...even emailed Mue and no luck, etc. I finally figured out the fix, but honestly don't recall all the steps. Anyway, it was something to the effect of UAC blocking permissions. So I thought I did something like created a shortcut on the desktop, go to compatibility mode and check "Run this program as an administrator" AND check "Run this program in compatibility mode for Windows XP Service Pack 3". You'll have to play around with some of those settings as well perhaps, maybe try disabling visual themes, etc. Anyway, I am absolutely POSITIVE some variation of that the solution worked for me...!

Hi Quack, just a refresher that you had asked about this previously in this thread and I suggested implementing this feature to Mue prior to that. Anyway, the answer is - that feature doesn't currently exist today. I know I had been collaborating with Mue and also sent him a proposed features list with detailed requirements including priority rankings. However, he has been busy with some real life demands, so I am absolutely confident he has this on his list and we had ranked this one highest of priorities. I'm hoping once he frees up he'll get back to it, so for the time being we'll need to be patient and optimistic that another revision will be here in the near future!

What he said... In my opinion, too many "I wants..." and lack of taking more ownership to get the desired results or at least coming together to rally around a smaller, "common", achievable goal where members can put aside their differences at least for a while...

Quack, that is absolutely a masterpiece - best "train/rail area" I've ever seen in this sim - well done!

Hmmm, revisiting this challenge - I think more of what I'm after is actually editing the weapon’s _data.ini entry as opposed to the aircraft stations. So on that note, I did hunt and search, but I didn’t come up with anything in the knowledgebase... I'm looking for some details and explanations regarding weapon _data.ini entries (e.g., EffectClassName, DragAreaMultiplier, WarheadType, GuidanceType, Accuracy, etc.). Is there something I’ve missed in the knowledgebase or another post that describes what each of the entries do? I was surprised I couldn’t find anything but must be overlooking something!

EMCON360...THANK YOU for your reply and providing this insight, this is really helpful. The info you provided below certainly helps clarify some things and gives me enough I think to begin experimenting more - really appreciate it! If anyone else has additional thoughts to share, including having already achieved a similar result and would be willing to share, please feel free to PM me or post here would be great!

I know it's possible to remove cockpit mesh components using _.ini edits, but is it possible to add new mesh .lods to a cockpit? For example, use a different pilot model .lod and "import" him into the cockpit mesh? Or would you need to edit the source 3ds max file?

Hi everyone… I’m struggling with an issue that I just can’t seem to resolve. When I try to add another area to my _Targets.ini file, it never shows up. I’ve done the typical trouble shooting such as double-checking numeric sequencing. But, the odd thing is that when I run a test mission and place an object exactly at the center of the new target area I’ve added (US Army Infantry Camp), it never shows up! Looking in debug mode brings even more strange results. For example, under “Nearest Target Area” instead of seeing my new target area, there is always another area that is overriding it (Pleiku in this case). I then test it using Mue’s tool, and there it is properly listed at the end of the _Targets.ini and displays everything exactly as I placed it (and as it should be)! Could this be something to do with radius issues? Any ideas on why this is happening? What can be done to resolve it? Appreciate any tips, this one is driving me nuts! [TargetArea059] Name=Pleiku Position=632000.00,366000.00 Radius=5657 ActiveYear=0 Location=1 Alignment=FRIENDLY [TargetArea202] Name=US Army Infantry Camp Position=641050.00,347050.00 Alignment=FRIENDLY Location=1 ActiveYear=0 Radius=5657

Thanks Dels for the reply, appreciate it. I wonder if anyone has ever been able to come up with an innovative way to add components to the cockpit, as it looks like it's still not possible without the source .max file of course. But I'm thinking we probably would have heard something about it after all these years...so I guess not!

Hey there Modders, Let's say I have a target object defined in the _Types.ini with an animation slot such as ID1. For example, a simple rotating light that goes around in a circle from a lighthouse. Can you, or how can you, transfer that animation effect to turn it into a GroundObject target that still preserves that animation effect?

Hi Wrench, thanks for hanging in there with me on this. I think the example you illustrated with the truck while interesting, wouldn't apply in my case. I'm familiar with self-illumination effects and modeling actually. The difference Wrench, is that those headlights are static - there are no animation effects at all. It's simply a mesh cone mapped with a transparent texture that is permanently attached to the model, but does NOT have any animation key frames/effects applied (at least none that I'm aware of). I'm kind of surprised other modelers haven't chimed in - surely someone with much more experience than me on this would be able to provide a simple answer as there is no way I can be the only person that ran into this, so we'll see what other feedback might be shared.

Wrench, thanks again for your reply, appreciated. Well honestly I picked a bad example, and should have been more clear. Here really is where I'm hitting a brickwall: I need it as a groundobject because it has to move (using the _data.ini) and I want to include in a mission. So it's a firetruck as a more appropriate example. That truck needs to move around and go places. But if I use it as a groundobject, - from my understanding - the animation within the model will not work. And you can see now the brickwall. I can't seem to do both. If I use as groundobject then I lose the animation effect. If I place as terrain object I can't get it to move. If I try to do both, I have a moving firetruck that was in such a hurry, it ripped off it's emergency light and left it hovering in space...

Hi Wrench, correct - that works for a targetobject placed in the terrain. For example: ...\Terrains\[TerrainName]\Lighthouse But how can the same object, with the same animation effects, work as a GroundObject here: ......\Objects\GroundObject\Lighthouse

Hey guys, is this out yet...?

How's this coming along, looks awesome!

Hi 3D Modelers, I need some help understanding the game engine rendering on 3d objects. Especially those that are “stacked” in height. Assume I have the following basic model. When I stack these models like so, and put into the SF2 Vietnam game I have a very undesired effect. What happens is when you look at the model from a far distance… The red box/model begins to shimmer horribly. It looks like the red box is actually moving down the Z-axis into the green box…sort of giving a result like in the picture below. Question: what can be done to prevent this from happening? Would adding another height segment help (like in pic below)? Would adjusting the Z-buffer offset in the .ini help (didn’t appear to do so)? Would adjusting the pivot points on either model help (experimented with this but not much difference noted)? Other ideas? What else has worked (other than of course directly extruding from the base mesh)? Would like to solve this using the proper 3d technique as opposed to other work arounds.

I think the reason for the lack of stacking is because it would require a different approach to actually creating the base 3d model. But in fact, IF my testing trials prove out, it would actually result in a more optimized model that should either prevent or limit far distance flicker. I'm only testing on one model right now, generically similar to the example I've shown...and it seems quite encouraging even with aggressive horizon distance settings But more to come.