Wall Worm Forums

No worries, you're welcome. Hope it works out. If you get stuck on anything or need any further help, just ask... and of course, don't forget to show off your finished model in the forums!! ;)

https://www.wallworm.net/index.php/board,8.0.html

Np. You're welcome. Can you tell me what game you are making this for? Do you want a l4d2 door with fallbacks and break models? Or is this just for CS:GO where you aren't worrying about breaking, gibs and fallbacks? Either way it isn't all that complicated. To start with make your model the way you normally would, i.e mesh, hull, materials etc. However there is one extra thing you need to add and that is a DoorRootBone, just add a single bone node and call it DoorRootBone and place it on the axis you want the door to rotate around. You'll need to include this in your smd export so your smd has 2 nodes, your model node and the bone node. After that you also need to go into PropData and select Door.Standard with Phys Mode "Auto" and then Override Base... Allow Static and Block LOS all checked. It is possible that this is all you have to do in order to get your model to work as a prop door rotating. When I made mine because I was also adding break models I had to lock the QC in WWMT at this point and add the rest of the info by hand.

My final .qc file is pasted below. You can see it is all pretty standard with the important stuff being in the $keyvalues "prop_data" section. If you are making a non-breakable door then in the door options you can remove the damage1 damage2 etc fallbacks. The only thing I am not sure about is whether the "breakable_count" part will count for anything. This controls the gibs the model gives off in its breakable format when changing between base models... the base model changes for a more damaged one and x number of gibs are spawned to give the impression of bits flying off. The thing is the starting model in l4d2 door doesn't give off a visible gib the first time it changes to a more broken version, it just forms cracks... nonetheless there is still (as you can see here) a break count of 1 and it actually throws off an invisible gib (an untextured cube 8 units square). Its like it had to be put in there for the system to work. Now in GO this may be completely disabled/ignored as the door never tries to break, that said however Source can be weird so you never really know.

Hope this makes sense, i have no idea what level you are at with models etc. which can make explaining things tricky. If there is anything you don't understand here just ask. If you are trying to make a fully breakable door with gibs and fallbacks I will send you my scene file, however if you are trying to make a simple non breakable door looking at that may just confuse things for you as 95% of it you wouldn't require.

$modelname   "gmaps/props_doors/slatted_door.mdl"

//$staticprop

$body slatted_door "slatted_door.smd"

$cdmaterials "models/gmaps/props_doors"

$texturegroup "slatted_door_skins"

   {

   {  "slatdoor1" }
   {  "slatdoor2" }
   {  "slatdoor3" }
   {  "slatdoor_custom1" }
   {  "slatdoor_custom2" }

   }

$hboxset "default"

$surfaceprop "wood"

$contents "solid"

$cbox 0 0 0 0 0 0

$keyvalues {

      "prop_data"
      {
         "base"      "Door.Standard"
         "allowstatic"      "1"
         "breakable_count"   "1"
         "blocklos"      "1"

      }
      "door_options"
      {
         "defaults"
         {
         "open"      "Doors.Wood.FullOpen1"
         "close"      "Doors.Wood.FullClose1"
         "move"      "Doors.Wood.Move1"
         "pound"      "Doors.Wood.Pound1"
         "surfaceprop"   "wood"
         "damage1"    "gmaps\props_doors\slatted_door_dm01"
         "damage2"    "gmaps\props_doors\slatted_door_dm02"
         "damage3"    "gmaps\props_doors\slatted_door_dm03"
         "damage4"    "gmaps\props_doors\slatted_door_dm04"
         }
      }
   }

//$illumposition 27.5 0 55.5

$sequence ref "slatted_door_base_ref" fps 30

$collisionmodel "slatted_door_base_hull.smd" {

   $mass 50.0
   $inertia 1.00
   $damping 0.0
   $rotdamping 0.00

}

$collisiontext {
   "break" { "model" "gmaps/props_doors/props_null.mdl" "health" "100" "fadetime" "10"}
   }

Yeah. I did make a break door model for which I basically copied the L4D2 door setup/system. In csgo the break fallbacks don't work, but the doors still rotate correctly. Below is a link to the finished complied model I made. If you can hang on until tomorrow I will dig my max scene, .qcs and .smds and throw all that up here so you can take a look and explain what I did - I have to be honest it was such a long time ago I cannot remember the details of how I did it off the top of my head.

https://www.dropbox.com/s/w47px4jcil9ezij/break_door.rar?dl=0

https://youtu.be/kAFScjAlxJE

This is about as step by step as you can get.

NB: It should no longer be necessary to contact Zeq about Crowbar as he has since released a public update.

Ah k, Max is making a new material. I never use drag and drop but I am guessing that if you have mutlisubobject materials and you drag bitmaps onto that then maybe Max doesn't know where exactly to substitute the texture so it makes a new material. Whatever the original cause, now it is like that, you simply need to set up the material correctly in slate, renaming/replacing the extra materials. Alternatively import the model again (into an new scene if you want) and use the dropper tool to grab the original material from the model, substitute in the correct bitmaps a la CopyCat above. Then reapply that to the model you are working on.

As for the normals... I am not sure why Edit Poly modifier will mess up all the normals but the subject of bad normals on a model came up in another thread recently: http://www.wallworm.net/index.php/topic,1499.msg4677.html#msg4677
In this thread it is explained how to reset the normals on a model.

However if you are trying to weld the vertices on and skinned/rigged model, the welding will probability mess up the skinning completely. Vertices in a model are identified by number and certain modifiers can become completely messed up if the number of vertices a model contains is altered (essentially its topology - because this causes all the vertex IDs to change) and normally skin modifier is one of those.

CopyCat has given a clear explanation. Tbh it isn't making a lot of sense to me when you say that you are getting "extra" materials. In your smd a material name is given on a per triangle basis, with each tri starting with the name of the .vmt of the applied material. You cannot have more than one material applied to a tri within the smd. Any other materials would come from the .qc

When reexporting/compiling a model using WWMT you need to set the correct path names for the materials. I would recommend always assigning materials by using the eye-dropper tool. That will set up all the correct nodes for you in slate.

As for weld verts you can do it manually if it isn't importing welded. A lot has changed since Wunderboy/cannonfodder last updated their tools and anyway the whole process of decompiling and importing has never been 100% reliable. Smd importer would often also have problems with welding and smoothing groups which would have to be fixed manually.

Quote from: Joris Ceoen on January 19, 2016, 04:06:40 AM
For the more programmatical stuff people could consult Gully I suppose  ;D

No no no no no! If your problem is coding related you will probably have more chance of getting a correct answer by preying to Jehovah than you will be asking me!!! :)

Or tarot cards!

Or by going to the end of the rainbow...

So long as the names and paths are correct there is no reason why adding the materials using CopyCats method above should add extra materials to the exported .smd

Quote from: pito2901 on January 19, 2016, 03:07:14 AM
Actually I said CS:GO and not CS:S  :-\

Either way it is the same. In WWMT Settings you can create profiles for both if you like. You simply need to make sure that you set the Mat Lib root file to be your "materials" folder (remembering that bitmaps must be in .tga format if you are not using WW Pro) and that you decompile the models into the games modelsrc folder.

The principles are the same for all Source games, just make sure you set the correct directories for your content in CS:S.

Get the content in the correct places BEFORE importing your vmf. If you import the vmf before ww/max knows where to find the textures and models you won't end up with much you can work with.

Did u get my reply to your message, Onur?

Looks good, onur!! Want to share some more details about your workflow?

U said at the start "I couldn't make U-spiral stairs", what was the issue you were having there?

I haven't tried it for a while but in the past I also would have some skin/weighting problems when importing certain models, tbh it has never worked 100% perfectly for all models. Some models would work fine whilst others wouldn't, and oddly I would sometimes get different results depending on which version of Max I was using.

Historically, the whole Source model decompiling and importing has always been a little bit unreliable, a problem which has only gotten worse with more and more engine versions, game variations, DMX files etc. It seems to effect rigged characters or weapons models more than anything else, but that makes sense as they are generally the most complicated models a game will use, having the most variables/parameters... if just one of these gets mis-translated between the mdl/smd file and Max it is likely to throw everything off.

If you happen to still be running Max2012 you can try using Wunderboys importer instead until Shawn gets a chance to look at it, or try importing with WW in different versions of Max if you have them.

I sympathize though, I have suffered frustration in the past because it has turned out to be completely impossible to get certain game models into Max as a correctly rigged object.

I never used Flexs myself, as I understand it they are normally separate from sequences in the sense that they are not bound to any specific sequence and can be overlayed on any sequence at any time... giving a wider variety of combinations of movement/expressions. But I always assumed they had to be called by the engine directly depending on the specific animation needs, but I didn't think they could be called via the entity I/O system...

Sadly Valve have never been great about documenting their systems, there are some good articles about as well as some huge holes!