Synide

Yeah, the CfgSkeleton + CfgModel is slightly different, but not overly different. However, there is a disparity 'tween the .p3d's provided selection names and the example .rtm provided. As I can't see the 3DSMax stuff I'm not sure if the .rtm was produced from that end or through O2. If it was produced from the 3DSMax end then the Skeleton structure used there is slightly different to the example .p3d's. If the .rtm was produced from O2 then I suspect the example.p3d's weren't used to produced this particular .rtm cause it has the following joints. It's probably better if you wait a little for Vespa to provide a properly constructed model.cfg that's being used with all A3 bodies rather than faffing around with a cobbled together one. -Sy PS: So, just to clarify the above list is not the Skeleton but just a listing of the joints in the example .rtm provided. As you'll note there's a disjoint 'tween the example .p3d's selection names and the contents of the .rtm. That's why I'd suggest waiting for Vespa to clarify. You could try something like this though... it may work...

Hi, Detailing a new skeleton and joints through a model.cfg would be easy for your new animal. If your developing your model in another 3D application like Maya, 3DSMax, Lightwave, modo etc. and then animating it you need to get those animations over to the Tools Suite. This is a bit difficult to do but not to bad if you know what your up too. At this point you may think that's all... but, then you've still got to do the config.cpp which usually aren't to bad, but since you're doing .rtm's you'll need to properly define & setup all the CfgMoves for the animal. Which essentially describes how all the .rtm's interpolate 'tween each other in certain game situations. This isn't a trivial task. On top of that you've got to do 'geom' .p3d's for the CfgMoves 'states'... Then at that point you might be getting close to having a working animal. But, you'd also probably want to do 1 or more .fsm's to provide arbitrary behaviour during simulation... Never really got into .fsm's tbh, not pretty things to get running properly imo. Maybe, but a bit on the ichy side... Do you know what the skeleton/joint structure that those .rtms for the goat were made with? I suspect not. You'd have to acquire that information through use of community tools. Then, depending on how good you are you may have a few niggle issues with weighting your moose to the expection of the .rtm's. Also, the .rtm's are sized specific so when you moose moved it's leg forward using the goat .rtm it would only move the distance that a goat's leg would move... So, all up I'd say this isn't a feasible idea. The only reason you'd want to do that is because you weren't confident in creating a new model.cfg skeleton/joints definition file. This would be one of the less difficult things to do for your moose. Unless you're well versed in all this stuff I'd suggest you've got a great deal of heavy work in front of you. -Sy

That would have been me... See Multimaterial. It can take _smdi textures too and the Shader just uses default values. The majority of default BIS content uses _dtsmdi's in the 'multi' shader .rvmats. -Sy

That's quite true... if he was using a '_smdi'. However, he's using a '_dtsmdi'. Multi shader .rvmats use 'dtsmdi' maps in the specular stages. They can take an 'smdi' as well and the Shader uses default values. And, although he doesn't mention it that's what he's using his spec maps for at the moment. See Multimaterial on the biki for details. Also, as for the color variation he mentions in his first post. One should keep in mind that the filter he was running that comes as part of the tools installation is used for creating '_sm' textures. Then, when TexView2 saves it out it processes based on TexConvert.cfg and writes out a different result to the one you see after running the filter. Not a big deal, but can cause a little confusion I guess. -Sy

If you so desire you can specify your main '_co' color texture that you would normally put in the 'texture' field of face properties in a 'stage 0' in the 'super' .rvmat. That's fine. But, most modellers who use the 'super' .rvmat specify this 'primary' color texture in face properties so that they can 'see' it in the O2 viewport when DirectX shading is enabled. It's not uncommon though for people to specify the 'primary' in 'stage 0' only and not have anything specified in the 'texture' field of Face Props. Also, you can have two '_co' color textures if you desire... You can have one specified in the 'texture' field of face properties and another specified in a 'stage 0' of the .rvmat. IF the 'super' shader happens to find a 'stage 0' specified it just 'blends' the pixels found in that image with whatever pixels happen to be specified for the 'primary' texture in face properties. It's rare though that people make use of this two color texture capability. Simple really. -Sy

In theory, this shouldn't happen... because the model you have open in O2 has already been read into O2 and then the file handle is closed. The only thing you should loose is the latest edits you've made to your model since you last pressed ctrl-s. However, in saying that obviously something's gone wrong somewhere along the track. Send me the broken .p3d you're trying to open and if you've happened to have made a .pbo of the model recently send that too. You'll find my email in my signature. I'll have a squizzy at it and see what I can do... no promises though... It sounds like in all likelihood it's screwed so you may have to start over. -Sy

Perhaps a bit of a case of 'lost in translation'. I shouldn't use 'slang' in my text as you've appeared to get the completely wrong intention. I don't think I typed anything there that gives the impression I'm assuming you've made no effort. But, I apologize if you've interpreted it that way. In principal though because you're talking V4 you really should be talking about it over in the VBS2 forums, even if, unfortunately you don't get the responses you're hoping for. It's unlikely your posts would get 'locked' over there whereas it's a higher percentage chance they will here. I understand you're frustration though as essentially you're wanting to use V4 in a non-standard usage scenario so you're unlikely to get a lot of help over in the VBS2 forums from support staff as it's really outside their scope to do so. This then means you're reliant on VBS2 end users that may have a foot in both camps to pass on information. I hope this response hasn't dampened you're enthusiasm or annoyed you. -Sy

You expressed a desire to use the output map from your work in V4 over in A2OA and he was commenting that you'd need to use one of Mikero's tools (or know what to change manually) on the .wrp that is pumped out by V4 to change it into a .wrp that binarize.exe in the A2OA tools will recognize and then process properly so it can be used in A2OA. Perhaps if you posted the details of the error you were having in the VBS2 forums you might get a solution. I can't imagine V4's buldozer would have difficulty displaying A2OA binarized .p3d's and I know it'd have no problem with mlod's so it may be just a pathing problem. If it does have problems rendering OA binarized .p3d's then yeah, it's a simple task to replace the VBS2 buldozer.exe with A2OA's game.exe temporarily so you can view the OA content when you're working in V4... mmmm... but then you might have trouble viewing some of the VBS2 tools supplied .p3d's if you use those in your map. I guess it's just a suck-it-an-see task. Anyhoo, wrong forums for this subject matter anyway. -Sy

I did a doc a long time ago about ladder dimensions but can't lay my hands on it atm... so from memory... i think i used to make the 'rungs' about 225mm - 250mm apart and about 40mm thick and about 400mm wide. There was I remember a sweet spot though in the size... Hopefully, I'll track down that document, but if not trial & error on your part is your best bet. Also, you wanna have the ladder extend about 800mm I think above the point where the character gets off the ladder so it doesn't look like he's climbing in mid-air. Don't take those dimensions as accurate though, my memory is not what it used to be. However, there is a good'ish way of you getting it fairly accurate. And, that is slap a character model temporarily into your building model and apply the climbing ladder .rtm to it. Scrubed it through and adjust your ladder topo appropriately. It's not the quickest method in the book, but making all your models relative to the anims that will eventually run on them is pretty accurate. Don't ask me to remember the name of the climb ladder .rtm... you can track that down I'm sure, or someone else can let you know it.

As Max Power said, it'll do at least 3 drawcalls for the 3 different groups of polygons that represents your 3 different models irrespective of whether they carried completely different sets of textures or not. However, if you can share or reduce the number of different textures used by all three models this would be more optimal I'd imagine than say having 3 different (but similar) models and 3 different but similar sets of textures. What i mean is... if you had say 1 model with 3 different texture 'sets' which may (or may not) end as say 3 drawcalls & you had 3 models with 1 texture 'set' also ending up as say 3 drawcalls, both these scenario's are better than having 3 models with 3 different texture 'sets' if ya get my meaning. -Sy

Yes I did manage to have a wee test. Log a CIT report. It's a bug in the in-built 'destrType' code for the 'DestructWreck' functionality I'd guess and you can't fix or alter that functionality. The settings I described previously are the req'd minimum settings so leave them as is in your model. When the bug report is resolved it should work as prescribed. That's of course if during bug fixing the functional requirements don't change. If, and only if, you really can't stand it, you could develop a workaround in the form of attaching a killed eventhandler to 'air vehicles' in general and have the ensuing scripts remove and create a static variant of the destroyed model for the various air vehicles. -Sy

mmm, maybe that's a bug. I'll test it here too and see if i get the same result. In your wreck model you really only need several Resolution LoD's, 1-2 ShadowVolume LoD's, a Geo LoD and a LandContact LoD. The Geo LoD should have the typical autocenter=0, prefershadowvolume=1, sbsource=shadowvolume. Make your LandContact last by selecting 3-4 points from your GeoLoD and copy-n-paste them into your LandContact LoD. Then copy those same 3-4 points over to your 'wreck' LoD in your original model. And, finally place a proxy from the original model wreck LoD to the wreck model. Once you have the config class attribute setup too it should just work. Btw, which version of the game.exe are you using? -Sy

yeah, what thromp said... just put 3-4 un-named points in the wreck lod along with the proxy triangle. situate them along the belly of your chinook as your wreck model probably doesn't have any wheels right?

Hi, Updated first post to version 3.0.1.0. Cheers, Sy.

You should be able to do a google search for 'how to center my image in Gimp'. I just did a search and it appeared to come up with some useful info. I just downloaded Gimp 2.8.2. Opened a .tga converted from .paa by TexView2. Exported as a .tga as another filename and specified... RLE Compression = OFF Origin = Bottom Left ... It opens in TexView2 fine. -Sy