Talk:Configuring the Source SDK for Dreamball: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
I'm am having an SDK problem relating to this game.  I can compile and run the sdk maps, but textures that come with DreamBall show up as black in the game.  For example, in the map '''sdk_checkpoints.vmf''', the red and blue dev textures show up as black in the game.  The ball shows up black when I testrun this map as well.  Only the skybox and the brush with the orange dev texture are not black. Does anyone know what the problem is?  I wanted to play with mapping for this, but I can't seem to solve this problem :(   
I'm am having an SDK problem relating to this game.  I can compile and run the sdk maps, but textures that come with DreamBall show up as black in the game.  For example, in the map '''sdk_checkpoints.vmf''', the red and blue dev textures show up as black in the game.  The ball shows up black when I testrun this map as well.  Only the skybox and the brush with the orange dev texture are not black. Does anyone know what the problem is?  I wanted to play with mapping for this, but I can't seem to solve this problem :(  <br><br>
<br><br>'''Solution:'''<br>
I am running the compile tools outside of hammer.  I've always compiled this way, but it seems '''VBSP.exe''' is just being stupidIf I compile the map from within Hammer, '''VBSP.exe''' works fineSo either I'm doing something wrong, or Valve broke something. Anyway, here's the compile code:<br><br>
I finally figured out the problem, so I'll just post the solution here in case anyone else finds themselves in a similar situation.  I am running the compile tools outside of Hammer from another program.  I had steam make a desktop shortcut for DreamBall, so I could look at its properties to see how to launch the game.  I copied the command line arguments from that shortcut into the setting in the compile manager program that tells it how to launch this particular gameThis was the problem. The shortcut that Steam made launched the game like this: <br>
<code>
CD /D F:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin<br>


"''-gameidlaunch 11957139809064976602 -game "f:\games\steam\SteamApps\SourceMods\Dreamball''"<br>
VBSP.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"<br>
VVIS.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"<br>
VRAD.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"<br>
</code>


I tried compiling in Hammer and observed that Hammer launches the game like this:<br>
<br>'''EDIT (09/19/2009 6:22pm):'''<br>
I was finally able to solve this problem with a little help from the steam forums.  I'll post the solution here so it might just help someone else.  Ok, so the problem was that the working directory was set wrong.  When compiling outside of Hammer, it seems that you need to set the working directory to the first ''\bin'' folder in the ''\sourcesdk'' folder.  So to fix the code shown above, you would change it like this:<br><br>


"''-applaunch 218 -game "f:\games\steam\SteamApps\SourceMods\Dreamball''"<br>
<code>
CD /D F:\games\steam\steamapps\USERNAME\sourcesdk\bin<br>


So I went into that compile manager program I'm using and changed the setting to make it launch using the -applaunch approach above instead of the -gameidlaunch approachAnd with that, the textures are now showing up properly in the game.  I'm not sure why the first launch method shown above causes this problem, but it does.  
f:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin\VBSP.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"<br>
f:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin\VVIS.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"<br>
f:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin\VRAD.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"<br>
</code>
 
<br>
In the code above, the first line sets the working directory to the first ''\bin'' folder in the ''\sourcesdk'' folder.  Then the next 3 lines run the compile tools explicitly by adding the compile tools' path before the .exe filenameWith these changes, '''VBSP.exe''' now works correctly in my batch compile.  I'm using a batch compiler program which automatically generates the batch file and runs it.  I have since modified the program so that the automatically generated batch file has these changes, so the batch compile is now working properly. :)
<br>--[[User:Font38|Font38]] 05:14, 17 September 2009 (UTC)
<br>--[[User:Font38|Font38]] 05:14, 17 September 2009 (UTC)

Latest revision as of 16:41, 19 September 2009

I'm am having an SDK problem relating to this game. I can compile and run the sdk maps, but textures that come with DreamBall show up as black in the game. For example, in the map sdk_checkpoints.vmf, the red and blue dev textures show up as black in the game. The ball shows up black when I testrun this map as well. Only the skybox and the brush with the orange dev texture are not black. Does anyone know what the problem is? I wanted to play with mapping for this, but I can't seem to solve this problem :(

I am running the compile tools outside of hammer. I've always compiled this way, but it seems VBSP.exe is just being stupid. If I compile the map from within Hammer, VBSP.exe works fine. So either I'm doing something wrong, or Valve broke something. Anyway, here's the compile code:

CD /D F:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin

VBSP.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"
VVIS.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"
VRAD.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"


EDIT (09/19/2009 6:22pm):
I was finally able to solve this problem with a little help from the steam forums. I'll post the solution here so it might just help someone else. Ok, so the problem was that the working directory was set wrong. When compiling outside of Hammer, it seems that you need to set the working directory to the first \bin folder in the \sourcesdk folder. So to fix the code shown above, you would change it like this:

CD /D F:\games\steam\steamapps\USERNAME\sourcesdk\bin

f:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin\VBSP.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"
f:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin\VVIS.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"
f:\games\steam\steamapps\USERNAME\sourcesdk\bin\orangebox\bin\VRAD.EXE -game "f:\Games\Steam\SteamApps\SourceMods\DreamBall" "f:\games\steam\steamapps\USERNAME\sourcesdk_content\dreamball\mapsrc\sdk_checkpoints.vmf"


In the code above, the first line sets the working directory to the first \bin folder in the \sourcesdk folder. Then the next 3 lines run the compile tools explicitly by adding the compile tools' path before the .exe filename. With these changes, VBSP.exe now works correctly in my batch compile. I'm using a batch compiler program which automatically generates the batch file and runs it. I have since modified the program so that the automatically generated batch file has these changes, so the batch compile is now working properly.  :)
--Font38 05:14, 17 September 2009 (UTC)