I have been modelling for source for some time now, I have made a few models for the engine, probably up near the 100 mark if you include the ones that I made for particular mods and others that I never released, and I gotta ask the question. Really valve? Really? What the hell is with the outdated, clunky, buggy, unstable workflow? On countless occasions I have had unfixable issues with studiomdl which required me to restart the pc, redownload SDK or reinstall entire games. It changes one day to the next. I have compiled a model one day and the very next day compiled the exact same .qc file, completely unchanged, and studiomdl cracks the shits.
UDK has a program that you just drop the exported model file into and apply all the settings there, cryengine has a GUI and in-engine model viewer/compiler, hell even the SIMS has a logical interface for importing models.
Source gives you an obscure programming language to learn, a hidden compiler that works only a quarter of the time on a good day, long filepaths that you have to create manually to get your models in engine, non scaleable models in hammer meaning if you didn't get it right then you've gotta recompile again, textures which require the same long winded filepaths and another obscure language for your materials. All the programs to help you with the model importing process are community made, VTFedit, GUIstudiomdl, Studiocompiler.
That can NOT be the way they do it at valveHQ. They MUST have a program that streamlines the process, or computers that are configured precisely for modeling and nothing else. Can you release that shit valve? Please? It takes me about an hour to model and texture my prop, 30 minutes to get the files and filepaths ready for import, 1 minute to try compile my model, 4 hours to troubleshoot why my four different versions of studiomdl won't work, all with different errors, and then 30 minutes to complain about it on facepunch. Honestly valve. Really?
Really valve?
Really?
You're all a bunch of cunts.
Heh, don't forget the fact that the current tools are now pushing 12+ years old as most of the source tools are modified GoldSRC tools. God, I hope Portal 2 comes with a much, MUCH improved SDK.
Hey, this engine is a lot easier to work with than the Gamebryo engine.
[QUOTE=Omolong;25890020]Hey, this engine is a lot easier to work with than the Gamebryo engine.[/QUOTE]
Why would you ever even consider using that engine?
I've compiled a lot of models, of all varieties, and I can honestly say it's nowhere near as bad as all that. The SDK has its fare share of problems and areas for improvement, but an educated user knows how to avoid the pitfalls and organise their workflow properly.
If you take the time to actually learn how to write .QC files, as opposed to using dumb community-made GUIs, you'll cut back on half of the time you spend running in circles by actually knowing how to rectify a problem when it arises. Studiomdl always works for me, so if it's only working 'half the time on a good day' for you, you're obviously bungling something.
[QUOTE=Black_Stormy;25887814]non scaleable models in hammer meaning if you didn't get it right then you've gotta recompile again, textures which require the same long winded filepaths and another obscure language for your materials.[/QUOTE]
Scaleable models would be nice, but not as a method of medicating a mistake you made. Why whine about having to recompile your models, anyway? Since the 2007 engine, models update in Hammer the second they're recompiled. Also, the flexibility of the VMT system is great and I sincerely hope you understand why it exists.
[QUOTE=Black_Stormy;25887814]On countless occasions I have had unfixable issues with studiomdl which required me to restart the pc, redownload SDK or reinstall entire games.[/QUOTE]
Honestly? That has never, ever happened to me. I can't imagine that happening to [i]anyone[/i], in fact. You really need to revise your strategies if this is happening because it's not normal.
[QUOTE=Black_Stormy;25887814]They MUST have a program that streamlines the process, or computers that are configured precisely for modeling and nothing else. Can you release that shit valve? Please? It takes me about an hour to model and texture my prop, 30 minutes to get the files and filepaths ready for import, 1 minute to try compile my model, 4 hours to troubleshoot why my four different versions of studiomdl won't work, all with different errors, and then 30 minutes to complain about it on facepunch.[/QUOTE]
First and foremost, [i]you[/i] need to revise your methods. There's no reason on earth for it to take this long if compiling models is something you do frequently and there's no reason to faff around with 4(?) different versions of studiomdl. There's one, in the \orangebox\bin\ folder that will do everything you want it to. I can't fathom how it can take you 30 minutes to write a .qc and drag it onto the studiomdl icon.
To reiterate, the SDK has its problems, but the bottom line is [b]a lousy workman blames his tools[/b], so here are a few tips that can speeed things up for you in the future:
[b]1.[/b] Do all of your modelling from a working folder (IE C:\Models) and create a subfolder for each individual model (IE C:\Models\Ninnyhammer\).
[b]2.[/b] Reuse .QC files. If you're just making simple physics props, there's no reason whatsoever to make new .QCs for each one. Copy the .QC from \Ninnyhammer\ to \Jinnyhammer\, open in notepad, CTRL+H, replace all instances of 'Ninnyhammer' with 'Jinnyhammer', save, drag, drop, done.
[b]3.[/b] Don't generate redundant content. A convex object can use its reference model as a collision model and every model can use its reference as an 'idle' animation. Only one SMD needs to be exported for a convex object.
[b]4.[/b] Don't use community-made GUIs. It harbours total incompetence. Actually learn the applicable .QC commands and their syntax so you can use them on the fly.
It sounds like there's a lot more that you need to know, but I'll leave it there. Bottom line is: Yes, the SDK could really use some improvements and updates to streamline things, but you're wasting a [i]lot[/i] of time due only to a lacking skill-set. Good luck.
I agree to some degree, but I have not encountered an error which I couldn't solve
The only problem i have is my physics models keep getting shrinkwraped even when i tell it not to...
To be honest I can more or less agree with you on the texture issue. The way of dealing with those is merely longwinded, but at the same time it's extremely human readable. It's just annoying really.
As to the models itself. While some better tools would indeed be better, most of the stuff works quite well actually. Sure, I'd kill for studioMDL to be able to create folders on itself but it's not the most important thing.
Likewise scale is quite easy to do - just add a line to the QC $scale X.X and voila you have something that works. Plus recompiling an already compiled prop takes about 4 seconds at most. Even shorter if you have your QC's auto compile via a batch script.
Also agreed with Tanner - actually learn QC syntax. It's not that complex and will save you a lot of time.
Likewise I'd love for an option to mirror R and L bones in the HLMV when working on limits, but again that's not the most necessary thing.
So to cut it short - the SDK is indeed outdated, but still very very workeable.
I reckon I must have some configuration problems on my PC. I have constant problems with the orangebox compiler. It invents its own filepaths to find my .qc in when I have dragged the fucking .qc to it already, it looks for the wrong .smd's when my fucking .qc says exactly what they are CORRECTLY and then I go and use the l4d studiomdl and it compiles fine. You can't tell me that that is my fault for not knowing .qc. I am relying on valve abandoning all support for left4dead so they don't update and fuck my config again.
I know how to write .qc, after compiling complex models I have had to teach myself, but when someone first starts off compiling for source wouldn't it be better to have a program that you can drop the .smd into and select options on a gui and then it would write the .qc for you? Much like the [i]community made[/i] vtfedit does with .vmt files. You might say "oh that's too complex" but fuck off. It's not. I didn't know that you could use a models .smd for it's idle sequence though, thanks for that, one less file to copy across.
I also know about scale x.x but that's still re-writing the .qc and if it's just the tiniest bit off, which it ever so often is when you need something just right, then you have to either put heaps of decimal points in there or scale your models and re-export and recompile. Gee hammer, can't you just scale the shit like all the other level editors?
As for hint 3 there, you might want to point out that you should only use a models reference for its collision if it a very simple model. All effort should be made to make a simple collision mesh to limit the strain on the physics calculation. Maybe a hammer or a pen could use it's reference, but even then you're better off making a relevant shaped cube. And on the shrinkwrapped problem, the main reason for that happening in my models is because the model you exported from your modeling program was too small. Scale it up in your modeling program and re-export.
Anyway I could rant until I'm blue in the face but I've got a config that is working for me *today* we'll see if it lasts.
I reckon valve has one big supercomputer that writes qcs, fixes problems, heck, even models the object straight from the developer's head. the only problem is that it just delays everything. Doesn't stop them from using it though! :3:
but in all seriousness, they probably have an advanced gui that keeps workflow faster and smoother, but they're not releasing it for the sake of keeping above mod developers. It would be embarrasing for a mod team to release a half decent game faster than them!
[QUOTE=gothiclampshade;25900399]I reckon valve has one big supercomputer that writes qcs, fixes problems, heck, even models the object straight from the developer's head. the only problem is that it just delays everything. Doesn't stop them from using it though! :3:
but in all seriousness, they probably have an advanced gui that keeps workflow faster and smoother, but they're not releasing it for the sake of keeping above mod developers. It would be embarrasing for a mod team to release a half decent game faster than them![/QUOTE]
No. Valve doesn't really have internal tools, unless you count Perforce integration.
What they do have is a compile farm, at least for maps, probably for models too. Anytime the .smd or .qc is changed, they can have a server automatically recompile it. Maybe do a nightly recompile of the entire model library.
The OP has been my attitude towards the SDK for years. The routine of model compiling is reflex at this point, and from finished model to ingame prop can easily be a 5-minute affair including the game's loading times. [I]Can[/I] be, if I'm not presented with some inane, indecipherable error message from somewhere deep within the bowels of Steam resolvable only through hunting down a completely community-forged work-around (not solution) to a Valve-created problem (free with every Steam update!) in long-dead message board threads from years past that should bear no relevance now because the problem should have been fixed long, long ago.
When my tools stop working from one day to the next with no input from me, that's not me being a lousy modder, that's Jesus shit the bed what the fuck is this garbage.
But hey, Valve's games have been held afloat by the modding community since 1998, why not their tools?
Valve claims to be a "game developer that supports their community"
Well then, where the hell are our tools?
agreed. source fails.
To be honest using VTFedit to make VMT's is probably more trouble than writing them yourself. Sure it works as a quick and dirty way to make a lot of them, but otherwise it's faster just to copypaste around.
I reuse QCs, Physics models and VMTs :v:
[QUOTE=Haxxer;25904350]I reuse QCs, Physics models and VMTs :v:[/QUOTE]
And I set up a batch file so I can recompile them all quickly. Between that and NP++'s "Replace in all open documents" feature, I can work pretty quickly on multiple models.
I'm positive Valve knows how pissed the modding community is over the wonky tools they're stuck with. We'll just have to be patient for them to fix everything.
Also, if you're working with studiomdl.exe, you should definitely look in to getting GUIStudioMDL. It uses Valve's compiler of course, but it presents you with a GUI to make things much easier. All you have to do is specify the EP1 and OB bin folders to configure it. Then you just load up your QC and select the engine version and which game to compile it for and it will go, and it presents you with an error log as it compiles so you can debug your QC and such. You still have to [B]make[/B] your own QC, which sucks of course.
However, there's another program called Duct Tape that's meant to fill the gaps in the work flow for Source mods. It's got a VMT editor, a map compiler, a QC editor, a model compiler, and even a soundscape editor. Someone over at Interlopers was working on it, but unfortunately he moved on from Source modding so I don't think the program is being updated anymore. He had a partner helping him with its production and that guy's still around so maybe it's still active, but I'm not sure he's working on it either. Look it up on Source Forge when you get the chance, it might come in handy for you.
Anyway, I wholeheartedly agree with you about the workflow. It's terrible, it aggravates me on a daily basis, and I can't even get in to mapping anymore because of Hammer being so shitty now. It's not just the modelers suffering from it, the entire modding community feels your pain.
PS: The VMT language is super easy to learn and remember, so I rarely ever have any trouble writing up a QC for a model or a map texture. The only time I need to look at the developer wiki is when I'm dealing with more advanced shaders or multiple parameters. But if it's just a basic Lightmapped Generic or Vertexlit Generic, I can get a working VMT up in about a minute. My keyboard suffers from it though. D:
Besdies, it's really easy to search for commands on the Valve Developer Wiki.
it takes me less than thirty seconds to get the qc right AND compile it.
Oh yeah I almost forgot, there's another program someone posted about on Interlopers called VIDE. It's got a "Mass VMT Editor" built in, so that might be a dream come true for any texture artists. :D
[QUOTE=nubblecakes;25926835]Oh yeah I almost forgot, there's another program someone posted about on Interlopers called VIDE. It's got a "Mass VMT Editor" built in, so that might be a dream come true for any texture artists. :D[/QUOTE]
Just looked it up, all I got to say is 'holy shit'
I have never had the problems you explain and I doubt I ever will. Sounds like you're just frustrated that you aren't doing it right.
Though admittedly UDK is much easier. Hopefully the workflow will be streamlined with the new Source engine.
I'm doing it right. I have compiled heaps of models and I know the language, it's the updates from valve that are screwing my files. An unchanged .qc compiling correctly one day and then studiomdl not even getting to the compilation stage because it has created a folder that it is searching for my .qc in the next day is my fault? Eat a dick valve, fix your shit.
You have to remember Gaben used to work at Microsoft. It's the way he rolls.
The compiling process is incredibly retarded. Especially when stuff breaks for seemingly no apparently reason what so ever, its insanely frustrating.
If anyone in this section ever works at Valve, you can go slap Mike Durand in the face because he's the person responsible for the public SDK, and has repeatedly stated he didn't give two shits about it
I've never had any serious problems with compiling models. The only thing that goes wrong (and isn't my fault) is that studiomdl becomes out of date after engine updates and starts erroring, which is fixed by running the SDK launcher.
Then again, I do remember being confused at first by the whole "material name in the SMD, material folder in the QC" thing. And I have three tools to help me:
[list=1][*][url=http://code.google.com/p/blender-smd/]The Blender 2.5 SMD exporter.[/url] No hassle getting things out to SMD.
[*][url=http://developer.valvesoftware.com/wiki/Notepad++_VDF_languages]The Notepad++ QC syntax highlighting rules.[/url] Makes reading them easy and spotting typos much easier.
[*]The Notepad++ exec plugin (comes bundled). Run studiomdl on a QC by pressing Ctrl+F6.[/list]
[QUOTE=Varsity;26012550]The Notepad++ exec plugin (comes bundled). Run studiomdl on a QC by pressing Ctrl+F6.[/QUOTE]
How, exactly?
[QUOTE=Varsity;26012550]I've never had any serious problems with compiling models. The only thing that goes wrong (and isn't my fault) is that studiomdl becomes out of date after engine updates and starts erroring, which is fixed by running the SDK launcher.
Then again, I do remember being confused at first by the whole "material name in the SMD, material folder in the QC" thing. And I have three tools to help me:
[list=1][*][url=http://code.google.com/p/blender-smd/]The Blender 2.5 SMD exporter.[/url] No hassle getting things out to SMD.
[*][url=http://developer.valvesoftware.com/wiki/Notepad++_VDF_languages]The Notepad++ QC syntax highlighting rules.[/url] Makes reading them easy and spotting typos much easier.
[*]The Notepad++ exec plugin (comes bundled). Run studiomdl on a QC by pressing Ctrl+F6.[/list][/QUOTE]
Wow, thank you so much for this! Alot better than using notepad, heheh!
Sorry, you need to Log In to post a reply to this thread.
