scotg

I have some textures with supershaders for a helicopter (seems like everyone is making choppers). There is some kind of funky artifact going on, and I suspect it's in the _smdi or _as map. None of my maps have any mipmaps, yet, but the textures look like over-compressed images - very "blocky". I'm also experiencing problems with surfaces. Baked normal maps come out too well done, causing flat surfaces with soft edges to look caved in a little. Here's an image that depicts both issues. Note the red buttons on the dash, and the boxy texture reflecting. This type of thing is happening all over the vehicle. http://www.scotgilmore.com/wip/a3/2015-03-19_00017.jpg (462 kB) Here are links to the actual files, pre-conversion to .paa (converted from tga to jpg for web viewing): _ca _as _smdi _nohq

OF course. pics added to first post. Also note the missing ocean in the window. I didn't realize that until now.

So this isn't something we can just drop into the vehicle's config.cpp? How would we go about setting this up for a new vehicle? I just realized yet again how little I know about making addons. I have a new chopper working, but so far I haven't tackled the weapons (cannon turret, 4 missiles, 1 bomb) or the MFD stuff.

Hi all, I was previously using Addon Builder to "binarize." It would go ahead and create the pbo, which allowed me to fly the chopper in game. There were issues: the sounds weren't working, and I always got an error message in the editor (upon clicking "preview") regarding the "missing" rvmat. But of course the rvmat does exist and did show up in game, and all the paa textures it calls for did their job well. The only time it didn't load any textures or rvmats was if I forgot to mount my P: drive before working. Since the sounds weren't loading, I decided to switch to pboProject and see if it can tell me why - and to see if I can find out why the editor error message says the rvmat is missing. I decided to also try using sounds that I know work - the in-game sounds. So I replaced the file path of my sounds with the file path of Blackfoot sounds. In the View Output report, it said it could not find the sounds referenced in the config.cpp. I commented out ALL sound references from the config just to get to the rvmat issue. It didn't really give me much information I didn't already know, besides confirming there is an issue with the p3d file not recognizing the rvmat it calls for. Of course with pboProject, that is a show stopper, and no pbo is made. The same rvmats DO appear in buldozer, and they were showing in game when Addon Builder pushed the model through with "errors". Here are some other possibly related issues: - My P: drive shows different content before I mount it. - In Object Builder, paa files don't display in the viewport, but tga files do. - In my assets, the file paths called for in the config.cpp and chopper.p3d files go all the way back to the \P:\ drive, whereas the game assets path only goes back to the a3\ folder. - Buldozer wont display this model in certain resolutions, like resolution LODs or viewPilot. It will render the geometry, the shadow (as a model), and the view Geometry. Also, I can copy eg the LOD1 model into view geometry as a loophole to see LOD1. It's a mess. Please help?

Somewhere along the way, I overlooked setting options for file types that don't get binarized. It's either that, or I DID set it once initially, didn't include *.rvmat in the file types option, and then forgot about this part of the process immediately afterwards. So if you're looking for answers to this problem, here's the fix: You'll want to go into the options for whatever pbo creator you're using, in the list of file types to not binarize, and make sure to include *.rvmat, along with *.paa, and *.wss. Some of you will likely need to include other file types as well. Eg: My textures were not triggering a problem, but I was having problems with the game locating my materials and sounds. Therefore, I already had *.paa in the list, but needed to add *.rvmat and *.wss, respectively, to fix the problem.

I just want to add: I had a similar problem with my main rotor, and I simply swapped the two memory points for the mainrotor_axis in the .p3d file. In other words, if the first point created is on top of the second, then recreate them with the first point below. Theoretically, it's the same technique for turret rotation (yaw). For turret pitch, it would be left/right to right/left instead. I came across this because I am looking for a solution to my stick_pilot problems. The flight stick is moving in wrong directions forward to back, and from the wrong pivot point when left and right. But anyway I felt I had a good contribution to the turret problem.

Good stuff! Love the video. As tested in copilot mode, it moves at about 0.5 rotations per minute using TrackIR - uselessly slow, but still barely perceivable. Compare that to about 5-10 rotations per minute with a mouse, which is the normal rate of turn in game. I attempted to disable mouse handling, which incidentally is bound by the "aim *" series in both the View control menu and the Vehicle control menu. Disabling one or the other is not enough to disable the mouse control of a turret; it must be both. But it's a moot point anyway, because disabling it had no effect on the control speed with TrackIR. And like you said, altering the sensitivity of the TrackIR itself will have no bearing on the turret movement. I just don't know why it takes so long to catch up to the view while controlling it this way. This is still a good step forward. Working with other vehicles is a great plus if it can be for a solo operator. I can think of some tracked construction vehicles and small tanks that would benefit from that. I wonder what happens if your AI gunner dies? Again I say good stuff Zodd!! I half-expected this request to be ignored, but you've done a great service here!

That's an excellent start! So, that means someone could fire seeking missiles at enemy units in their peripheral, right? As a gunner, using the TrackIR to move the turret is very sluggish. I assume that could be changed via sensitivity settings, but then wouldn't that make it too sensitive for analog (i.e.: joysticks, control pads)?

I'm sure someone has come up with this, but a search for more info yields unfavorable results. I'm requesting the integration of IHAADS for new vehicle addons. In simple terms, it's the ability of a pilot to aim a turret with his helmet. It could be useful for solo-manned aircraft or if your gunner dies of sudden, chronic IBS. Players who utilize the freelook feature or have the TrackIR setup will benefit more. Players who take advantage of neither probably don't fly much, or will be encouraged to evolve. :p The challenge would be to work out a way that the turret aims at the same spot as the pilot, even though it is usually located a few feet from the pilot's head. I imagine an invisible line is calculated indicating the pilot's line of vision, and where that line intersects with terrain/geometry is where the turret will aim - and adjust accordingly for distance arc. So, I can see where this bit of scripting might be the tricky part. Also, to aid in this type of control, the use of TrackIR for turret control can be temporarily adjusted. I find that adjusting for good turret control via control pad messes up the way it handles with TrackIR, and vice versa. The problem here is that a control pad may be preferred when you are a gunner, but not while a pilot or driver. Here's to hoping!