scotg

I'm glad to have gotten to the end of this thread and found that someone else has brought it back to life after two years. My seven months since then doesn't seem so bad all of a sudden, and I was very eager to throw in my $0.02 after reading through it. BTW, I found this topic while searching for -any- tutorial in allowing some small, one-man vehicles I modeled a semi-turret functionality - think small helis and tanks with turrets that move like human heads, and can even be operated with TrackIR... If anyone wants to discuss/brainstorm this with me further, then we could start a new topic or a PM, or both! The problem I saw in this thread is that people seemed to be using extreme examples on both sides of the fence, and hung up on the whole "Arcade vs. Simulation" principle. I just want to point out some things I've noticed: Each person's definition of "simulation" is different. Personally, I like my simulation via immersion focused on realism of visuals, sound, and movement. Working with a team to accomplish a goal is even better, when practical. I liked BF2/3/4/2142 because they immerse you with animations and visual qualities (each according to their time), but it did seem hokey in BF when one person could control an M1A2, carrying out a 4-man job with just one guy. I like Arma 2/3 because they provide large battlegrounds, a sense of being part of a team, and even the long spans of between-the-action draw me in. However the simulation of A2/3 tends to be a joke when the AI can't move for crap, and you have the same lack of player animations that most other FPS games suffer. Simulation is a tricky word. For a flight sim or race sim game, it's understood you will not get out of the vehicle - you're only focused on operating whatever vehicle you've chosen. In a military sim game, however, there are multiple types of vehicles, infantry movement, squads/teams, and AI. Thus, the term "sim" has to be taken with a grain of salt when these features are not fully immersive. The die-hard "sim" guys seem to be caught in a contradiction. Often, they seem to rant about the virtues of playing on a team with an objective, not having one guy in a tank dominate the landscape, and how unrealistic not doing it their way is... But then they use 3rd person POV. This doesn't make sense to me, but I think we all know the type. They are usually the ones who are also crying, "go play BF/COD." On the flip side, (I'm not saying that anyone is blatantly suggesting this) one-man large tank operation is crossing the line, even for a sim-arcade hybrid game. Incidentally, for all its faults the Battlefield series, esp. BF2, did blur the lines between arcade and sim. I can't say it fits into either category, but it has a lot of strong arguments for both. Having played other simulations or "sim" games, one could say the same about Arma. Anyhow, the fact remains that operating a tank by one's self is not consistent with the spirit of the game. If you're dominating with a tank because you have a good team with you, then good. But if you can't find at least one person to swap crew roles with you as move between encounters, then don't expect sympathy. You should recalculate your tactics to include something you can operate solo. Granted, this can be a frustrating paradox for the co-op players; I wish I had better advice for them. They definitely don't deserve to be harassed about wanting a solution. In the US Army, training occasionally involves using a simulation video screen and converted weapons or vehicles to control your avatar with. EG, an airsoft M249 (which is actual M249 weight, feel, construction minus vital components) would be fitted with control sticks and some buttons for movement, or a desk would have the dash and wheel of a HMMWV and then a monitor. In such scenarios, the soldier experiences a simulation of the situation that he/she is training for, and there is even an AAR. It's practice. It's very stiff and bland, but the use of real equipment as controls, and how everybody reacted to the series of events, were pretty much the simulation. That's good for staying focused on the training objective. In BF2, the scenarios aren't as specific, but at least there are shadows in the environment and moving parts on the virtual vehicles. Being more immersive doesn't mean good simulation, but being a good simulation isn't enough to cut the mustard. Arma 3 may be a simulation military game, but it's still a game. Have fun, and loosen up.

Thanks, uka! That did the trick, and I must have fiddled with those values before realizing I had to hide-unhide a non-lit model piece... I hope there isn't anything else that comes up.

Headlights, taillights, reflectors, reverse lights, and interior lighting. All these things that operate on vanilla vehicles, I want to make function on my LM002, AND how to properly set up the textures, model, and configs. Is there a resource or tutorial for making fully functional lighting on vehicles? I can place memory points and proxys, but the challenging part to figure out is what parts of the model correspond to what textures, what named selections, and what rvmats - to give it those fine details. Trying to tackle this task with basic custom vehicle knowledge is insufficient.

New lights testing reveals another flaw in my development of this vehicle. Previously, I had been testing the lighting at dusk, right when the game engine allows for lights to come on. The lit dash was bright, and the non-lit dash was not. In fact, I was considering darkening the _ca file a tad in order to get a less bright dash... Then I tested the lighting in the thick of night, when everything is nearly pitch-black, and the lit dash was barely visible under these conditions. IE: The lit dash at midnight should still appear as bright, or even brighter, as it does at dusk - which it doesn't. Any ideas how to correct this?

This is another update. There's an updated preview pic in first post, and more lighting-focused screenshots and general screenshot of the LM002 in-game can be found here: http://rooster3d.deviantart.com/gallery/32775893/3D-Showcase Here's another preview:

I've got another little hiccup with lighting, but it's probably a really minor oversight on my part. Although my dash lights are now coming on beautifully, I cannot see the dash readings at all when the lights are off. Is this a setting with the light brightness in config, or should I have another, less brilliantly lit dash piece laying under the lit one (so that it'll be visible when the light go off)? I'm trying to imitate analog instruments with circumferential ambient lighting when lit, which means they need to be just visible labels without lighting in the daytime - pre-1990s tech. EDIT: Solved, although I'm not sure if this was the correct way: I copied a new instance of the lit dash panel objects. Where the original uses an rvmat with "Emmisive" properties, I applied an rvmat with a way more subtle emission setting, and subtle ambiance to boot. Finally, I disassociated it from the lights' named selection, so that it's visible all the time, and then moved the lit objects slightly in front of them, such that they'll be seen when they "unhide." The result is the intended, subdued, high-res labeling using the same .paa which is also visible in the daytime, when lights aren't allowed to come on, AND there is a visible difference between them, as if they are really lighted dash panels. However, this seems like a convoluted way of doing something that might have otherwise been accomplished more efficiently. glossary for this post: lit - having the appearance of self-illumination turned on. lighted - given the ability to self-illuminate, whether on or off. emmisive - an incorrect spelling of the word emissive, as it's recognized by RV engine's materials scripts. The material properties that give textures a lit appearance, in the rvmat file. I am considering posting screenshots of this vehicle (with a theme focused on its lighting), if anyone is interested. I may even consolidate everything I've learned and create a vehicle lighting tutorial, but I feel like I'm the last one who needed help in this area.

uk_apollo and x3kj: Thanks guys, so very much! I've almost got the lights in great working order. There're some minor tweaks needed with the artwork, then it'll be lit like aunt Rosie on Christmas Eve (couldn't resist - just sounded funny).

Thanks guys! Such great help! Okay, so this may sound dumb, but I'm assuming I can use this for front, non-headlights? When I look on the SUV and Offroad, they have "daylights" that come on whenever the vehicle's rpm is activated - some in the back and some in the front. Looking at their model.cfg files, it seems confusing. This is from the SUV: class daylights { type="hide"; source="rpm"; selection="daylights"; // sourceAddress = clamp;// (default) minValue = -0.8;//rad -45.836624 maxValue = 0.2;//rad 11.459156 hideValue = 0.2; unHideValue = 1.0; animPeriod = 0.0; initPhase = 0.0; }; class reverse_light { type="hide"; source="Gear"; selection="reverse_light"; // sourceAddress = clamp;// (default) minValue = -1.0;//rad -57.29578 maxValue = 0.0;//rad 0.0 hideValue = 0.2; // unHideValue = -1.0;//(default) animPeriod = 0.0; initPhase = 0.0; }; class Display_off_hide { type="hide"; source="rpm"; selection="display_off"; // sourceAddress = clamp;// (default) minValue = 0.0;//rad 0.0 maxValue = 1.0;//rad 57.29578 hideValue = 0.001; // unHideValue = -1.0;//(default) animPeriod = 0.0; initPhase = 0.0; }; The brake lights and daylights make sense. Here, the dash looks like it should come on when the engine starts, but that's not the actual case when I use the SUV in game. Also, the choice of names for class and named selection is convoluted and a bit misleading. So the real question: Is the dash geometry actually named "display off," or rather "light_r" / "light_l" (I think this is what x3kj was talking about)? Also, if it IS included in the "light_l/r" named selection, then how does it stay on when either of the lights is shot out?

I know what named selections are... Sorry, I should have clarified: what are the named selections used for dash lights? I have been checking out the guts of A3 cars using eliteness, but I cannot seem to match all the components to see precisely how it works. It tells what materials, textures, and named selections are used for the entire vehicle, but as far as I can see it doesn't explain the combinations used per function of the vehicle. Some sort of flow chart would be nice, but that's wishful thinking.

x3kj +1 pulling through again! Cool, so then reflectors are the cone volume lights? Is it possible to make the brake lights so that they turn the environment red, like a real car? If the glowsticks can do it, then I'm thinking yes. What about interior dash lights? Is there anything different there? What are the named selection? If it's covered by glass, will the glass properties interfere with its shine/glow?

I'd like to know more. I sent a friend request via Steam.

Thanks, mikero! This community can sometimes feel a little elitist and unwelcoming (with a few great exceptions), but the words in your reply have given me new hope.

I'm sensing irritation towards my struggles. I probably did overlook something, or I've forgotten it, or perhaps I'm just not good enough to use your tools.

To be precise, I hope, you mean C:\Program Files (x86)\Steam\SteamApps\common\Arma 3\arma3.exe, right? Furthermore, if it's installed on a different drive, like E in my case, then it should point to E:\Program Files (x86)\Steam\SteamApps\common\Arma 3\arma3.exe, correct? should there be any other commands in the options. eg: -window, -buldozer, etc?

which is why I've come to this thread seeking your help or the help of someone who understands your tools and developers' needs. Maybe I have too much on my plate to see what changes I need to make, combined with doing what I'm used to doing by default. I have been using eliteness, but I also need visual interface for my models, hence OB, TB, TV2. So what's the solution to Addon Builder, what's the solution to imagetopaa, and what's the solution to Buldozer? Obviously I need a compiler. A mass-texture converter tool would be nice, but imagetopaa doesn't work without P: drive. A model preview would be great, but getting buldozer to work for me is like herding cats with ADHD.

Ok. It's fixed!!! Simple solutions in a nutshell: Once you create a proxy for vehicle light volume, named "proxy:\A3\data_f\volumelightcar" for defining its function, then 1) rotate/move entire proxy in OB, without deforming the original shape and size. 2) whatever your light is named in memory LOD (eg: "light_L"), also make a new selection of proxy:\A3\data_f\volumelightcar.001 (or whatever corresponding number) with the same name. Therefore, each light polygon will have two named selection entries - a proxy and a selection. It was the simple step of giving the proxy polygon a second name that tripped me up, and I think it's so simple that it's easily overlooked in defining the process. Thanks to x3kj for your help in clarifying how this works! Now I'm off to figure out the interior lighting effects, whatever it's called... anybody chime in if you know, before I start running around in circles again.

It seems as though I already have such a thing in my code, but maybe misplaced? My vehicle's memory-defined lights are "light_L" and "light_R." However, the visible geometry in LOD1, 2, etc. are "light_head_L" and "light_Head_R." Maybe name the geometry light the same name as memory lights? Here's my config.cpp: Here's my model.cfg:

re: 2) I've been using eliteness to extract the model.cfg files from Offroad and SUV. I just copy the code from the eliteness window, paste into a new notepad++ window, and save as something I'll recognize that won't interfere with my own model.cfg. I suppose that means I DID miss/overlook something... but after another look I see that I do have the hide animation for class daylights with the source "rpm" and selection "daylights." If that's it, then do I need to include my proxys in the selection "daylights?" If that's not it, then I'm stumped.

Cool, cool... You're a big help, x3kj! I'm grateful to be learning so much from your replies, but this raises new questions. 1: Do I need to rotate the entire proxy polygon, eg all the vertices as one? I've just been manipulating individual vertices to get the position that seems appropriate, but to no success. 2: My vehicle code is patched together from the vanilla vehicles, Offroad and SUV. There is no indication of where the light cone hide/unhide animation is in their files, yet it is working on both of those vehicles. So where do I find and where should I place the hide/unhide light cone code? I've scoured thru Data_F, A3, Soft_F, and Soft_F_Gamma in hopes for a lead... maybe I missed something?

Forgive me for digging this up, but It's relevant to my question about Headlight Effects. Instead of creating a new thread, I'm hoping this will be more appropriate. Here goes: The proxy that x3kj mentions will be fine for my vehicle's headlights, and so will its texture. However, when I apply the proxy on my vehicle and then start it all up in the editor, the volume light is already on and facing the wrong direction. Issue 1.Turning lights on and off do nothing; the cone is just always on. Issue 2. Cone is facing wrong direction, usually the wide end "UP." Logical re-orientation of the proxy only seems to yield unpredictable results. I've looked at the .cfg and .cpp files of my model, and compared them to the files of BIS models, which obviously have working headlight effects. The lines of parameters related to headlights shouldn't affect the light volume as far as I can tell, but I searched through it again just in case I might be wrong. Something, somewhere in the mix, is missing or in error. Could it be the location of the proxy and its textures in relation to my model's location that's causing it to work improperly?

Initial Overview: - Arma 3 Mod Experience - Texture UV problems - Movement problems - Instrument problems Mod Experience I have a few custom vehicles, of all types, which I am going to bring into a mod pack. I've had a moderate level of success with helicopters, but there is still much to fix. For example, I can get a heli to fly, use instruments, main and tail rotor blades spin, and flight stick movement, but I cannot get elevator wing and other code-based animations to work. The important part at this point is that it is flyable and readable. I've stepped away from that for a little while to try wheeled vehicles, starting with a basic civilian SUV, the LM002. Texture Problems Right off the bat, you can probably see some UV issues in the _ca textures above. That is, the texture containing alpha channels, which holds the glass and the grilles, is ignoring its UV coordinates. The result is we get white chunks of texture in unwanted places. You can see half of the grille is working fine, and the bottom half is crap. Also, on the windows we see white stripes. The headlights seem unaffected, but there could be unseen issues at another angle. Below is the UV coordinates for my glass and grilles. The yellow lines are the UVs as seen in Object Builder. The red UVs are copied from the first row of shapes, and happen to be the outer windows; however I scaled them up to about where they seem to align in-game. Where yellow is in X, Y, the red turned out to be 2X and 2Y. I believe the whole UV layout is blown up 2X, 2Y in-game for some reason, apart from the headlights, which seem to look like they are in position. Here's an interior look: The color of the grille is seen through the opacity of the window. In other words, the UV seems to be working for the ALPHA channel in this case, but not for the RGB - even though it's the same _ca.paa file. Movement Problems The vehicle won't budge at all. It turns on, but won't move. I can attach slings, but I cannot lift it. What happens is the slings stretch out to their max, and then it just breaks off. The overall "mass" of this vehicle is temporarily at about 2700. Seems feasible. Memory Animation Problems The steering wheel ("drivewheel") doesn't turn, nor do the front wheels. None of the instruments come on. Everything has proper memory points and axis to function, but nothing moves. This, combined with the vehicle's overall lack of movement, makes me think there's a skeleton problem, or naming problem in the model.cfg file. However, some things do work to some degree, such as the exhaust, entry points, and PIP for mirrors; I haven't bothered with lights yet. I hope to get help on this and get it out to everyone soon. I have more vehicles in the works, as well. Aside from the UV problem, I need to fix my textures. Thankfully, that is within my control at this stage.

Well, I've got most of the initial issues... solved, I guess. The dampers are working, wheels touch the ground, textures in RVMAT are at the right scale. Now it's on to some special problems, for those finer details. - First, I've noticed there are light cones on the A3 vehicle headlights - a cone-shaped volume of light that extends from the headlight, outward. I wonder how to achieve this effect, and will I need to create new geometry, textures, rvmats, etc? Is it possible to also do this on the taillights? EDIT: I've included in my vehicle's .p3d a volumelightcar proxy. This makes the light cone thing, but it's hard to figure out its orientation. As is, it just faces straight up, and adjusting it to any other direction has unpredictable results, except that it never faces where it should. Also, the cones are ON all the time. - Second, how do I get the actual lights to brighten? I considered that a new texture with brighter colors might do the trick, but how to implement that? It's not clear by looking at any of the sample model material, nor the A3 vehicle files. Whatever the solution, will it also work on the interior lights? - Third is a modeling question. I feel like I may have asked this somewhere before, but how can I smooth out some surfaces where multiple polygons meet? I've got an area where I'd otherwise have used normal mapping to smooth out a surface, but it seems that a baked NOHQ map, where a low-poly model has the lighting information of a high-poly model, creates new problems. NOHQs created from grayscale height work fine. So, are there any tricks out there that get this to look a little better?

I'm not sure if you're talking to the OP or me, but I think FPS drop is insignificant enough to justify either sitch. For OP, it seems to be a matter of arranging much needed storage space by moving files from his SSD to his HDD. For me, it's an attempt to make the P: drive work, and subsequently all the Arma3 Tools, which I think will mean moving A3 from my HDD to my SSD. In both scenarios, I believe the SSD is primary, and the HDD is secondary - I can say that's the case for me at least.

Do you think this will help with the P: drive and Arma3Tools?

I have this problem frequently: I call it texelizing, from the word texel which in DXT format is a quad of pixels using 4 averaged (?) colors within the quad to come up with optimized results... sometimes the difference is too insignificant, which results in the blocky artifacts. You confused me here, though. I don't understand what you mean by "make your diffuse a 'solid' color, no 'pores' in the paint so to speak." I've noticed in PS that there will be pores in a channel. For example if I make a gray layer #4e4e4e, it should be 4e solid in each channel. This is often not the case in all channels. It might be solid in Red and Blue, but in Green (this is all arbitrary for the example), it might show up as 4f with some 4c pixels scattered evenly. Are these the "pores" you meant?