scotg

Update. Still using pboProject, it was finally able to pack a vehicle with no errors... I had to put the "common" PAAs and RVMATs back into the specific vehicle data folder, because I have no idea how to tell the engine where to look. That means I'll have to do the same thing for all the other vehicles, now that I know it's going to work - at least until I figure out a config for common assets.

Yes, sorry. I have been battling with setting up Mikero's Tools properly to help workflow. In doing so, I have lost the ability to make anything new at all. My overconfidence and trust allowed me to lose all packed vehicles. So, once I get either Mikero's Tools or the way things were, working, then I can get back to providing more screenshots, videos, etc.

@Dedmen It's understandably confusing, because it all seems so convoluted to me. EDIT: Okay, forget everything that was here. It turned out to be a fix that wasn't taking hold, which seems to happen more frequently when packing from a P:\ folder. It was missing damper axes in the memory LOD, which were actually named differently, but the change wasn't sticking. I commented out the sections of the model.cfg that called for these axes, crunched it, and got a new error... hopefully a progressive one. Going over the .p3d and model.cfg I made sure each part was matched and had the proper axis. It finally worked and again I got the new error... Yay-ish~! The new error is more inline with this thread. It cannot find a config.cpp for the common RVMATs, which are called for in the .p3d. In other words, my common textures folder is just sitting there without a config - at least I think that's what the problem is. And... indeed I have no config in that folder.

Oh good. See, I didn't actually get that from the reading. Any idea why I might be getting a binarize error when I "Crunch?" Also, I still cannot use buldozer. This is an issue I am having, posted on a different thread on how to set up the Work Drive, but I now think the setup and file path issues are somehow related:

Sigh... in these files I have seen unique values called sha or shakeys. According to Mikero's documentation for pboProject, there is an SVN generated by vbs2lite? What's the difference, how is either one generated, and what are the consequences of skipping them?

Thanks for all the help! :-) It's now starting to look like I'll be able to get things in order.

Prior to streamlining my mod's internal directory and setting the texture path in OB constant for every model, everything was working. Prior to making the move to utilize more of Mikero Tools, my mod components were pumping out. It was a few more steps, but vehicles were visible with proper textures in Buldozer, and more importantly they were coming out nicely in the game environment. I even made some videos featuring many of my vehicles. Between BIS, Mikero, and Windows 10 Fall Creators Update I think they are all conspiring against me :-P But seriously, after re-install of Mikero's Tools, Arma 3 Tools, and Arma 3 itself, I finally got to a point where the pboProject was giving me actual output. Now encountering a binarize error: Noisy: I don't know how it's supposed to work, but I wonder if it's supposed to have the space in "-binPath=P:\ GIJOE\vhx_soft\gijoe_vamp" between P:\_and_GIJOE? If not, then what's causing it? I tried to use "Addon Breaker" to see if it would still push it out as before. The result is an empty entry in the virtual garage that causes the character to spawn without a vehicle, and I cannot select other vehicles. Using alt+F4 yields an error message after killing it. So, whatever changes made in the all-encompassing effort of getting Mikero's Tools to work also affected Addon Builder, probably Binarize.exe to be specific. If it's a problem with my config or model, then sorry, but I still think there's a setup mishap somewhere.

Cool. Can I just install over everything, or do I need to jump hoops backwards now?

Gone through the process a few times, but it's not operating right. I get to the part where I'm about to start Buldozer Configurator, and everything looks to be in place. I attempt to configurate, but I get an error message telling me buldozer is missing, and to run DevP (whatever that is). For grins, I start up OB and then buldozer to preview a model. The window starts and the model loads, but some rvmat textures are missing (e.g.: nohq, smdi, as). Some show up fine, though. The textures pulled from a common file directory in the root folder are displaying completely, while the textures specific to the model are only showing the *_co.paa files. The RVMATs seem to be trying to work - just not the textures they are assigning. I believe this because there is a weird darkness caused from a missing NOHQ file, which means the RVMAT has to be trying to call one in the first place. Maybe my file path is too many folders deep, if that's even a thing? P:\MYMOD\vehicle\land\soft\scotg_car1\<scotg_car1.p3d>, <configs> P:\MYMOD\vehicle\land\soft\scotg_car1\data\<PAAs and RVMATs> Packing, previewing, and playing my assets has been working fine before setting up P: drive. The only reason I wanted to do it with P: was (A) to allow common assets/textures to be used by many vehicles and characters, and (B) to eliminate having to setup paths in OB options every time I open a different model.

My mod folder is E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE E: is an HDD, secondary to C:, which is primary and an SSD (in case any of that is important). wa Here are a few specific asset paths: E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE\vehicle\land\soft\gijoe_aweStriker\<aweStriker1.p3d, config.cpp, model.cfg> E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE\vehicle\land\soft\gijoe_aweStriker\data\<PAAs and RVMATs for buggy> E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE\vehicle\land\soft\gijoe_vamp\data\<vamp1.p3d, config.cpp, model.cfg> E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE\vehicle\land\soft\gijoe_vamp\data\<PAAs and RVMATs for jeep> E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE\data_f\comms\<common asset radio textures and mats> E:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\GIJOE\data_f\vhx_gear\<common asset vehicle parts and gear, like tires, pioneer tools, decals, gerrycans, etc. - textures and mats> All together, I have 10 vehicles, 2 helmets, and more assets on the way. Can I simply copy-paste the GIJOE folder with all these assets into the P: directory, and still be able to add more as they become ready for import? Or is there a more official method? This is the part I do not understand. Also, I looked up PBOPREFIX to determine if I had the right thing in mind, but it turned out I had no idea what it was. I had a paid version of the mikeroTools in 2016, but my project wasn't ready to adequately utilize it at that point. It just sat there while I was busy creating models and trying to figure out configs.

@jandrewsYou have older posts in this thread. LOL. The thread has been renamed, by suggestion of moderators, to avoid BIS policy conflicts, and thus avoid getting removed. I was told it's the reason why a certain very, very popular sci-fi franchise mod covering an ancient and extremely remote universe has been forced to leave mod discussion (pun intended). The advice was basically to say the mod is inspired by GI Joe, which is actually more accurate than to say it is GI Joe, because I have clearly put a lot of work, unique design, and research into developing and distinguishing these assets.

That means they won't show up in Buldozer or ARMA, and the Resource Library panel in OB represents them with yellow "?" instead of nice little green or blue icons. I'm not surprised with the P: drive being improperly set up. It has been on and off again since 2013, and just a big headache. I have it on, but only because Buldozer won't run without it. In previous times, I had thought P: encompassed anything within a certain location of the Arma Tools folder, where my mod is located. However, this time it pretty much only encompassed barely anything it needed to allow for it to exist, if that makes any sense. Perhaps, this is the typical result when a determined digital artist tries to be tech-savvy.

Object Builder adds to the confusion of the path problem. The .p3d files aren't recognizing textures and materials unless their paths begin with the folder LEVEL containing the .p3d itself. For example, I have the directory parked like this: z\scotgMod\addons\vehicle\land\soft\scotgCar1\<scotgCar1.p3d> z\scotgMod\addons\vehicle\land\soft\scotgCar1\data\<textures and materials files> BUT... How I have to assign texture groups in OB: Exterior Texture: scotgCar1\data\<scotgCar1_ext_co.paa> Mats: scotgCar1\data\<scotgCar1_ext.rvmat> Sounds normal until I realized I can access lateral folders this way, and it all displays like it thinks it's normal: Texture: scotgCar1\data\<scotgCar_int_co.paa> Mats: scotgCar2\data\<scotgCar2_wtf.rvmat> Analogy: To me, it seems like accessing the 5th floor of the next building from the 5th floor of the building I'm in, via some magical secret skyway. But if I wanted to access the second floor of another building, I can't even do that by going downstairs 5 floors of my building and then going up one floor of that one! (speaking in American, where the 2nd floor is one after the ground floor.)

Cool, but it's a bit more complex than that. I've got several vehicles I've made across multiple types, each one being packed on its own, and stored within relevant file paths. I've tried the straightforward approach but then either models or textures (incl. materials) come up missing. Here's what's working (using your illustration): z\scotgMod\addons\vehicle\land\soft\scotgCar1\data\(specific files and common files) z\scotgMod\addons\vehicle\land\soft\scotgCar2\data\(specific files and common files, duplicated from above) Here's what isn't working, but what I'd like: z\scotgMod\addons\vehicle\land\soft\scotgCar1\data\(specific files) z\scotgMod\addons\vehicle\land\soft\scotgCar2\data\(specific files) z\scotgMod\addons\data_f\(common files) I've also tried it without putting in the extra "addons" folder in the directory, since it's already required, unpacked, in the overall mod folder.

Thinking outside of the box... A tricycle is kind of like a unicycle towing a trailer. Maybe if we reconsider a trailer as a FWD tricycle, it's a good place to start? By that, I mean the front "wheel" would be under where the hitch is connected to the vehicle, and its steering axis would be right there. You'd have to make new trailers special with an invisible front wheel in the memory - probably not possible with existing vehicles. The front "steer" wheel should always be parallel to and centered with the towing vehicle. This could possibly allow jackknifing and other real trailer events. It would have to dynamically inherit power, brake, and acceleration from its towing vehicle, and apply the power through the front wheel. I'm probably missing some key factors, but hopefully getting the ball rolling on some kind of solution.

Removed post; content was obsolete and not useful to anyone.

@Donnie_PlaysThanks for checking in! It's always good to see interest in the mod, for sure. Public interest is better than facebook , in my opinion, for that much needed dopamine fix we all crave! These links are great, but we're doing a more realistic take on GI Joe, the way it was meant before studio executives said "no-no" to cartoon violence (but not holding that against them). I appreciate the mildness of GI Joe cartoons from my childhood, but in this more realistic "simulation" we want to simulate real bullets and missiles. This is still useful information, indeed! While blaster rifles may not be the standard weapon, there are plans for weapons that emulate LASERs (spelled as an acronym on purpose). These are large, high energy consumption devices that cannot simply be carried around as a personal weapon. Here is a prime example of the possible rare inclusion of a LASER (Note that the included operator is an expert in conventional weapons, the M16 and M1911): Of course, I would have to investigate real life LASER technology and make design changes accordingly.

Thanks for the compliment! Nobody will hold that against you. It wasn't emmy-award-winning TV by any stretch, and the movies were generic sci-fi garbage using a few familiar characters and a new GI Joe logo slapped on them - not my GI Joe. That being said, part of the reason why I want to do this mod is to bring back the original GI Joe and Cobra equipment with a realistic twist. I want to show where the ideas for some of the vehicle designs came from, and then show how they'd work within a military/combat setting, such as what Arma3 provides. It really bugs me how media executives get hold of a great franchise and totally make it into something else, not to mention how the original creators or current copyright owners tend to keep reinventing their properties these days. Look at Gotham, the TV show. The show will end when Bruce Wayne finally becomes Batman, but by then, after all that has happened, his emergence will be like, "so what? Yawn." The show's concept was in a good position to tell an interesting back story of Commissioner Gordon, but instead it turned out just another sloppy WB/DC Superhero/Supervillain drama (without the superhero). I digress...

Here's a list of things that didn't work so far: - I had the front wheel steering axes sharing vertices with the front damper axes. I created new axes for the steering, but there is still a lean. - I have tried using two different methods for the damper motion. 1. Using 4 independent axes, one for each wheel/damper. 2. Using one center axis, Basic Damper Destruct Axis, for governing all wheel dampers. Each method yielded slightly different unfavorable results. - I tried relocating all desirable LOD contents, geometry, etc. into a new file by copy-paste. I was hoping this would leave behind any unseen points that might be causing problems. If it did, there was no benefit. - Specifying in the config spring strength on all wheels, rather than inheriting from wheel_1_1, and increasing the value (the same for all 4), has fixed the floating problem, but there is still a lean to the right side of the vehicle. - I wasn't completely sure if having a bunch of items in the "transport magazines" section would weigh it down adversely. There were a lot of magazines listed (I used the Ifrit/MRAP_02 config for a big chunk of this vehicle), so I deleted all but one item. No change. - imported new geom and geom phys LODs. no change. - tried the geom LODs on another otherwise working vehicle. There was no lean in those vehicles, so I ruled out the geom/mass being the culprit. - totally replaced the configs with configs from other vehicles and left the suspension parameters alone. Aside from different suspension performance, the lean was still happening, so I reverted to previous configs. Now that the wheels are all on the ground, but the car is still leaning, it does seem like there is an imbalance in the mass, as @Yano suggested. I combed over the geometry a few times, but still cannot identify the problem. EDIT: FIXED! One of two things did the trick: 1. wheel parts in the shadow LOD did not correspond with the ones in LOD1. In LOD1, I have wheel_#_#_hide and wheel_#_#_unhide, but in the shadow LOD I just had wheel_#_#. It doesn't seem like it would affect things, but to be safe, and consistent, I made the shadow parts hide and unhide for when the tire gets blown. 2. I deleted all the related "wheel_*" memory points and recreated them from scratch (e.g.: axis, bound, land_damper_axis, steering, etc.). I'm not sure why the old ones were not working, but the new ones are not causing a lean. Whatever I deleted, I recreated; I didn't add or omit any points. All in all, it just goes to show that when you think you have it mostly figured out, the simplest, least obvious thing can cause problems.

This occurred to me as well. I have placed 4 mass distribution cubes in the geometry LOD to better govern the mass. The sides are 400kg each, and same distance from the center of the vehicle/world axis. The front cube is 750kg while the rear is 700kg; both are centered (L/R). The rest of the geometry weighs 5kg. It's a small amount to make such a difference, and the geometry is L/R symmetrical anyway. I think I can rule out the center of mass, unless there is some unseen heavy point floating somewhere in the sky...

I am wondering if you mean stationary, instead of static? I ask because I will be creating some stationary defense systems myself (eventually), but I want them to have soldier interaction. In my mind I thought they would be done as if a vehicle, but give them zero power to move - effectively making them stationary. "Static" sounds like not even turret animations, but maybe that's just me. Try making it an unpowered vehicle if you want animation and interactive use.

Car leaning to one side, need help seeing problem (w/pics) [Admins: I didn't want to hijack a thread, but it seemed related to the topic. If this needs its own thread, then by all means please move it and delete the contents of these brackets.][Edit/Update: I seem to have fixed the problem of the wheels floating for my vehicle, but the leaning problem still persists. I'm not sure if it is relative to this topic anymore...??] Hey everyone! I need some extra eyes to see what I might be overlooking. Another vehicle I've made is leaning back-right, as pictured below. Depending on whatever value I give the spring strength, the wheels will either float or sink through the ground, but none are level to each other, which gives it the leaning and bad handling. (Green lines added to clarify distance from ground within shadow area). The closest to accurate wheel is wheel_2_2, which is still a little raised by about 3mm. Configs included below the pics. I've been over it again and again, but my eyes are getting tired. I feel like there might be a simple solution that I am overlooking because of fatigue. portion of model.cfg: config.cpp: Anyone trying to figure it out, LMK if I need to post anything else for solving this.

Hey everyone. Today, I just encountered a strange new warning message when loading some of the missions I've already made, played and re-played in the past. This isn't happening to all missions, but it goes something like this: In a green dialog box with a red warning bar, it says there are a list of assets not installed. Continuing allows the scene to load, but without any of the said assets. Some are custom assets I have made, and some are BIS assets. Sounds straight forward so far, like I accidentally deleted stuff, right? Not likely, but I continue... I click the button in the dialog to continue, allowing it to load the scene. I can now manually go and locate all of the assets it says are not installed, place them on the environment, see them, and play with them. That's a miraculous thing to be able to do if an asset is supposedly not installed, eh? So, my question is: why do some missions/scenarios try to load like these assets are missing? EDIT: I just noticed, and it might be worth mentioning, is that the scenario title is also not appearing in the editor (top right by the X) for the malfunctioning missions.

Perhaps it might be a good idea for future installments, then (e.g.: ArmA 4).

This is a very good point, but you seem to be coming from the vanilla A3 perspective, whereas I am "speaking" as a mod'er. Many other mod'ers have era-specific tanks and other tracked vehicles that would be great to control simply by allowing this method. We're not stuck in 2035, just because that's the timeline of the game. Even in the current day tank tech, levers are more the norm - considering all dual-tracked vehicles, big and small. Users have an option for helicopter controls, and so should it be for tanks. Therefore, why not build it into the engine, let the mod developer decide if it should or should not be a lever tank, and let the user decide if he/she wants to use lever controls on available tanks? Too easy!