Search

[ZappyzoopyRoboHuxtable]

I'm trying to create a model for a mod running on 2006 sdk base.

I'm continually getting an error of "can't find steam user app info". I've changed the paths to just about every combination of existing folders in my mod and sdk directory, even mix-matching and trying all sorts of crazy things.

Though I do get that error, I have managed to get it to spit out a vmt file, a qc file, an smd file, and a batch file.

Please let me know any further information I can provide.

[wallworm]

The only mod I've messed with from that branch is Hidden:Source. For me, the Bin directory is "c:\program files (x86)\steam\steamapps\mysteamusername\sourcesdk\bin\ep1\bin"

But I haven't updated Hidden since steampipe. It may not be the same anymore if you don't have the old Steam paths. In that case, I'm not sure.

Is Steam running? That version used to require Steam to be running to compile anything.

[ZappyzoopyRoboHuxtable]

Steam is running. I have run SDK for this mod since. I've played around with using the bin in the mods directory and the sdk\bin\ep1\bin. I don't think I had to restructure anything for SDK or the mod since the steam pipe update. I do remember SDK wouldn't launch for a day or so, but I believe an update fixed it.


EDIT: After the steam pipe update broke SDK I got it to work again by copy and pasting steam.dll into <username>\sourcesdk\bin\ep1\bin

[Joris Ceoen]

Quite amazing to see a mod for 2006! Is there a specific reason for you (or your team) to stick with such an old build? There are quite some limitations to that version  :) Just curious

[ZappyzoopyRoboHuxtable]

The game in question is Fortress Forever and is in fact quite old now. I'm not on the development team, just a community member. There was the intention of porting to the 2013 sdk, but last I checked no one is working on that prospect any more. The dev team had dwindled down to about 2 members, and the last one who actually did much has either burnt out or moved on with his interests or life. Understandably so.

Regardless it's the only game I really enjoy and I love to create content for it. I've mostly been into mapping but in the past few days I've learned enough about gimp and 3ds max to whip up this silly thing:



A community request for the replacement of a long lost custom "medkit" model. Hoping to move slowly into mapping props and view models.

[wallworm]

Well I wish I could help, but I don't have the game and also this might be hard to fix. When Hidden started popping up a notice that it needed to do an update (which I presume was to move it to a steampipe format) I always hit "No" and leave the legacy version installed. Since all of our players are still able to connect and the server runs without the update, I'm not eager to run the update for the simple fact that any support for the game is unlikely at this point.

That being said, sorry I don't have the answer necessarily, but welcome to the WW forums. I'm always happy to see new creative blood here. And I'm always excited when someone says they are a mapper. You'll have to start testing making your maps in Max instead of Hammer like Joris is now doing :)

[ZappyzoopyRoboHuxtable]

No worries, thanks for giving it some consideration. Source 2006 has always been pretty bad, and it was only a matter of time before it got worse. I have one potential solution I can test out, and I'll let you guys know if it works out.

[ZappyzoopyRoboHuxtable]

Update:

I did manage to get a model to compile. I ended up copying the bin from common\Source SDK Base 2013 Multiplayer and dumped that into username\sourcesdk\bin\ep1\bin.

Although it did have the expected result of breaking the sdk for FF. So I'll have to see if I can just copy studiomdl or some combination of files while keeping sdk functioning for this 2006 mod. Are there any other tools besides studiomdl I should copy, or do you know of a better way to handle this knowing that it seems to be just the 2006 tools that are broken?

[wallworm]

I'd first try just studiomdl.exe and vtex.exe . Those are the only ones you need for models specifically. If you start mapping in Max and the mapping compiler fails, you'll also want to copy vbsp.exe, vvis.exe and vrad.exe .

[ZappyzoopyRoboHuxtable]

I'd first try just studiomdl.exe and vtex.exe . Those are the only ones you need for models specifically. If you start mapping in Max and the mapping compiler fails, you'll also want to copy vbsp.exe, vvis.exe and vrad.exe .

I'm not likely to even contemplate mapping exclusively in max for a very long time.

I've reinstalled sdk and seem to have it and the compiler working. I haven't tried to compile a map yet, but have been able to use the model viewer. For now I just plan on keeping two copies of my bin, and rename them according to which one I need at the time.

I have managed to get my item in game, the only problem is that WWMT tells me it has trouble configuring the paths for just the vtf. VMT and mdl compile fine. I suppose I have a missing/missplaced folder somewhere.

Edit: Actually I have no idea why it does that. It says "problem figuring out outputdir for  (x86)\Steam\steamapps\sourcemods\FortressForever\materials\Map _1" This is a two piece model with two textures.

[wallworm]

Make sure that the materialsrc directory in global WW settings is set to the one expected by vtex and that the output path in both materialsrc and materials exists. This is because vtex will only work by compiling TGA/PSD files FROM materialsrc folders... and it does not always have permission to create folders in the materials folder.

See this document on sdk paths. The content was written pre-steampipe so uses the old examples, but should be helpful in understanding this. Also, the video on that page shows the fastest way to set the correct paths.

If the paths are already right, then it may be a file permission problem where either Wall Worm cannot create a folder/file and or vtex.exe doesn't have permission.

[ZappyzoopyRoboHuxtable]

Aha, yes thank you. Setting it to a materialsrc folder gets the job done. It now compiles model and textures with success.

though, I still for the life of me can not get the textures to show up on the model in game. I'm trying to replace a model:


FortressForever\models\items\healthKit.mdl

which corresponds to:

FortressForever\materials\models\items\Healthkit_blue.vmt
FortressForever\materials\models\items\Healthkit_blue.vtf

I set the model path to items, and the material path to models\items, and have deleted all the original content.

Everything seems to be in place but the model comes up with a checker board in game.

Sorry for being overly needy, this is my first foray into modeling.

[Joris Ceoen]

The reason why that is is that you might have copied a vtex.exe that has a higher number than what 2006 supported. By number I mean the build/version of the texture. For instance, all CS:S texture versions are 7.4, all those of CS:GO/Portal 2/L4D2 are 7.5 (the latest number).

I guess those of 2006 should be 7.0 and anything higher might render it useless or unreadable for the engine.

To fix this (if that is the problem) you can open the original texture(s) with VTFedit and give them the number manually by going to advanced tab and in the 'Version' section, check 7.0

Because you have probably lost the original vtex.exe for 2006, I'm afraid this process will always have to be done (unless you can change the exe or something to make it give them all 7.0 by default)

[ZappyzoopyRoboHuxtable]

Yeah it turned out to be 7.4, the rest of the default textures in FF are 7.1. I tried setting mine to 7.1, and then 7, but neither worked.

My model is name healthKit, and my textures are "box512texture" and "pizzatexture" while the vmts are named 01_-_Default and 02_-_Default. Is there some sort of a problem there?

[wallworm]

Well... your solution is two-fold: Go to the global WW settings and make sure that you have the WW SMD Exporter chosen.

Second, rename the Materials in the material editor to your desired material name (for example, something other than the default names of the materials). The WW SMD Exporter uses the material name for face material names instead of the diffuse bitmap name as we the case for the legacy exporters. Although you can also change the settings to use the legacy settings, you should not do that because I no longer test those settings as I add features to WW.

[EDIT] Then re-export both the Materials/Textures and the Model.