Hatchet_AS

Wow most excellent. It's nice to know how that actually works, as I've pondered it more than once. Very cool, and many thanks for taking the time to share the information and provide a functional example. All Pro.

That is correct and is due directly to the way the attachment system does not work. What we had to do here is utilize one of the default slots. The weapon models do not actually have a direct method by which to 'attach' things to the visible rails. Rather only the specific points/slots available in the models. I addressed those without rails with the 3way barrel mount. The intent is for the barrel mount to become functional. And if that goes arounding to plan, we'll be adding in fairly functional rail systems to all weapons. More tinkering needed first. We'll take it as far as we can. BIS might update things to make it easier, we'll 'Adapt' if that happens. OP updated with example mission for the bipods. I have some other things to do right now, but I'll address the crates tomorrow at some point.

Fair enough. Let me think on the crate for a minute, might just go ahead and do that. I will be uploading a mission here shortly though, as an example of 'how-to' do these classname/code things. I highly recommend VAS, but that might be a little much if you're new to this stuff. ;)

I'm an old FO myself, love all things involving raining steel! Appreciate the script version, will check it out soon. :D

Lol, you made me go back and read. And now I'm not even sure why I included that, guess I read something wrong. ;)

Thanks for the kind words, and very much appreciate the linkage Foxhound (OP updated). Cheers

Oh snap, is BIS planning to deliver a Keltec KSG? I plan to counter with a UTAS UTS-15 if that is the case. ;)

Glad your ship is moving! I would jump in and help you with the config stuff, but honestly been a year or so since I really got into those things. Others around are probably much more able/capable of explaining these things clearly. Everything you have listed is doable/reasonably easy, with exception to the 'walking on' part. I'm actively working on that, but it is not functional currently without mad sorcery. Hopefully if I get some attachments out this week I'll update the PhysX thread in the DEV branch forum, with my current test setup. Which has some valuable stuff in it. Probably be the weekend before I get to it though. Busy work week.

I think out of everything involved in the process, having the link between 3d app to O2 and on, is for sure more needed than the rest. Like Fennek mentioned, tons of how-to model things out there. I was silently hoping you might be one of those uber O2 users, and were about to drop an O2 bomb. Lol, obviously you're not insane though. I think utilizing whatever makes your process easiest is the way to go. I'd personally roll with something complete, and just back the process up and show things. Pro enough. :cool:

I don't claim to be any sort of expert here. But you can plainly see using the LODBOX object that distance is in fact part of the process. And in my testing, my conclusion is simply that the engine is hardcoded to handle those distances. We can not influence that, except by how many LODs we have in a model. That will change the 'distance' at which the LOD switching occurs. And it is fairly exact. Although 'very' different depending on the objects class. On top of that, in my testing of attachment things ... I saw no difference between having 1, 2 or 3 sections, and the distances at which the LOD switching occurs. Again the only thing I found that seems to affect things in purely the number of LODs in the model. After that it's up to engine to determine what to do with it. For whatever it's worth, in my testing I also tried named LODs (as I have seen those same tutorials of old), it had no effect. Rather the engine will (default too) ordering the LODs based on vertex count should things not be in named order. I have no interest whatsoever in debate here. I'm simply sharing my very recent experiences. Take it or leave it. Tis all good with me. :)

Ooo.. nifty stuff here. Much appreciated gammadust. Looking forward to playing around with it. :cool:

I've tried for a few minutes to understand and I'm failing to do so. For what it's worth guys, this mod is really intended to allow other model makers a means by which to unify things for the community. I wish Robalo or myself had time to configure everything to work properly together, but honestly we barely have enough time to configure things for our own servers with everything else we have going on. Please don't be put off if we don't make it by this thread to address things on a regular basis. Model makers with specific issues might want to PM me if stuck. Many thanks to you guys who are fielding questions though. Much appreciated. As always we'll update whatever we have in play, as that's easy. :cheers:

Well, I've been around for a while and think in general there will always be people who want/need a tutorial. This day in age, video tutorials are a great way to go. And if planning to carry it from to finish (including the O2 bits), that would very worthwhile I think. Having more than one, from different people would be ideal. As most people who model know, theres a lot of ways to skin the cat. So it makes sense to have a variety of examples available. Curious, what apps would you be using?

I believe you. Perhaps it's still broken in Stable. From reading the ticket last night ProGamer linked, I 'assume' it's currently fixed in the DEV branch. Could also be totally broken there still also I suppose. (you might know!) I apologize, as I am really disappointed that this was even an issue in the first place. My expectation level of what 'quality' should include has been lowered. I'll fiddle with it when I back to the hole in a bit. I imagine it's just broken though, not really mystical in how it works.

Ah thanks for that Monkey, was educational. Please excuse my misleading linkage :D

Took a quick look at the Panther and Cheetah models, they appear to have the selections present (camo1,camo2,camo3). So I would assume they would work the same as anything else.

1 mass = 1kg (see Collision Geometry) Not sure about the armor equation. Where is that from?

Halp! The gentleman is indeed still trying to sort this, and I have no clue personally. :)

Unfortunately (speaking from experience), it can be quite challenging trying to find/utilize 3rd party assets. First and foremost, you generally don't find game ready assets for free. Secondly, what you do generally find for free (or even paid 'high quality' models) is a clusterfoo of geometry that has to be reworked for a game engine. The amount of time it can take to work through the model to find everything that is not correct and fix it ... is generally more than it would have taken to model it properly the first time. You're better off in most cases remodeling off whatever you get your hands on. This can be very efficient if you know what you're doing in your 3d app. If you're not a 3d artist as it were, then it might not be a reasonable thing in the first place. Assuming you can find something free that is usable and you have your resolution LOD, there are still the additional resolution lods, geometry and shadow lods, and all the needed named selections and memory points that have to be generated. Again, not something you'll likely find in a free or even paid model. At any rate, there are a few sites like grabcad, blendswap, TF3DM I browse on occasion (google ftw). What to look for ... it's all relative, considering you're scenario ... I'd say you'd want game ready assets. Which would hopefully include all the 'work' involved. Like the low poly model with UVs and textures. Otherwise, you're going to be doing all that work yourself. And again simply means you'd be better off doing it all yourself from the start. I know thats not a reply you want. But is what it is.

I was recently trying to sort how things are working in A3 for misc. things. While rather crude and simple, this little thing can be helpful in understanding how things are setup in RV. I configured it for relative house base stuff for this thread. However the models can be configured for whatever (like attachments as I needed), and you can see how different classes behave. The .zip package is not binarized as it contains some PhysX stuff for the Floating_Structures. Feel free to tinker, modify, destroy as you see fit. http://www.youtube.com/watch?v=yu6fIoQEaoI (hmm bitrate fail, will upload again latter. Nope youTube just being slow..) Hope it helps.

Hmm.. that is interesting Sakura and makes good sense. Appreciate the poking around and sharing of information. Not an ideal solution in the global sense, but would probably be worthwhile for a dedicated project. I'd personally like to be able to add the trailers for a few watercraft/vessels to misc. vehicles. Having separated models and functions to allow the towing functionality is ideal, for most I suppose. Is there a proper ticket floating around? I was really hoping BIS would include the needed parts to make things functional (which could still happen). Why even put the 5th wheel HEMTT in without it.

It was Nou, caught up with him just now. Think the issue is with attachTo still, so that is on hold currently. Pretty sure deanosbeano has tinkered with these things also.

Ok, that is a good sign if it is sitting uneven in the water. Need to go back and revisit the topic of 'MASS' assigned to the Geometry LOD. The basic concept/goal is to weight the vehicle accurately, so using my MkV as an example (image in higher post) you'll notice I have the 'center of mass' (the dark blue dot, with the X) about center vertically, and towards the rear of the vessel. This makes the vessel sit a little deeper aft when idle. What is important to note, is that the weighting is being applied to the Geometry LOD, but I balance the 'center of mass' around the shape of the PhysX GEO LOD. What is also important to note is that the amount of weight you enter must counter the 'displacement' of the PhysX GEO LODs. I say LODs because I can't recall exactly if the Buoyancy LOD was actually responsible for that calculation. Either way, one of the PhysX LODs assumes a certain amount of displacement, and your total amount of mass must be balanced against that. So the MkV actually sits just right at it's actual real world weight of around 56,000kg. Additionally the placement of the water effects is important. They must be below the waterline. Worth noting, if those memory points come out of the water in the simulation ... the engine will shut off (or wont turn on). These points are also where the 'thrust' is applied to the model. So there is a bit of a balancing act that can go on, depending on the speed/size of the vessel and relative weather conditions (eg.. 30 setWaves 1). If you have the ability to post some images of things in O2, that is always helpful.

Magic powered by, Eliteness.

Pretty sure this is being worked on currently. And I don't mean by BIS. Think the current scheme involves utilizing a simulated ball joint (under PhysX things). Sure it'll make public news if it makes progress. Can't recall who was chatting about it at the moment though.