- First what you need, are a folder in your C: drive called textures, or whatever name you want for it, make sure it’s one line, no spaces only words. Secondly, you may need to create a folder containing your porting materials, which will be linked in a .rar file to save you the time, and energy of installing these programs. You can learn how to mount Half-Life games with J.A.C.K online, as this tutorial won’t cover that, sorry. (Yes, I know I have a folder called cheats. PLS DONT BAN ME!) DOWNLOAD -> https://we.tl/t-b4UPXBIpDD
- Inside of your primary porting folder, should contain J.A.C.K, and mbspc, our primary decompiler.
- First, let’s set up your textures folder correctly. I must warn you this step isn’t always completely concise for everyone, even I struggle with it occasionally because the parameters demand to be so excessively specific. Create 2 blank shortcut files with the parameters for both xwad.exe, and vtex.exe, they can be found in: Steam\steamapps\common\<game name>\bind\vtex.exe and Steam\steamapps\common\SourceSDK\bin\source2009\bin\xwad.exe (INSTALL SOURCE SDK FIRST!!) Secondly, you want to address the two shortcut files in here, vtex.exe and xwad.exe. You want to make sure your target line is set up correctly, so right click xwad.exe first, and make sure your target line, and start in folder are correct. Make sure you have Source SDK installed, or else you won't have access to both of these files.
"C:\Program Files (x86)\Steam\steamapps\common\SourceSDK\bin\source2009\bin\xwad.exe" -basedir "C:\
If your steam directory is not correct, make the adjustments to both Start In, and Target line.
Your Vtex.exe Target line, and Start in line should look like this.
"C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\bin\vtex.exe" C:\
If your game directory is not correct, make the adjustments to both Start In, and Target line.
If you are doing a game like CSGO, it should be the same, just check your bin folder, and for vtex.exe.
You’re done setting up your texture folder, leave it be for now, we’ll address it later.
- Now you need your .bsp file. This can be from either 1.6, or the original Half-Life. From my experience Quake 1/2/3 files also work the same, but the extraction of textures is an entirely different process I’m not going to delve into in this tutorial. I suggest storing your .bsp file from 1.6 or HL1, in your “store maps” folder (I included one in the .rar file.) This way you can get rid of it easier, and quicker when its no longer needed for extraction and decompiling.
Make sure your .bsp file is in the correct location, then move onto the J.A.C.K. program. Launch the program after mounting your HL1 games, and navigate to the option- Plugins>Half-Life>Extract textures.
First off, click the + button, and navigate to where you stored your .bsp file, and click open.
Now, you need to store your outputted file somewhere, click the … option on the menu now, and head to where you originally made your vtex/xwad shortcuts, and place it there.
Once there, I suggest changing the file name to something less than 4 characters, and easy to remember, or type out. I usually modify this step for convenience and thoroughness just because I don’t want dozens of new texture/material folders in my base games material folder, and it cleans up a lot better just to have one, I name mine “abc” for example, and it all goes into one place.
Note: Do this EVERY time you have a new .bsp for porting.
Once the name is changed, and you click save, click the bottom left extract button, and it should extract the textures very quickly.
NOTE: DO NOT use over 5+ .bsps files at once, I suggest doing them 3 at a time. The reason for this, is because sometimes the .bsp file has certain textures that are corrupt, and need to be manually extracted with a program like GCFscape, and converted into .tga files for conversion with vtex. It’s not uncommon, and it CAN happen sometimes.
Navigate to where you extracted the textures.
Once there, right click on your Xwad shortcut, and vtex shortcut, and change the parameter “wadfile” to the name of the .wad file you just outputted from your map.
Run in order of xwad -> vtex, make sure to wait for xwad to finish, and vtex will prompt you to press any key to continue once its done, if either crashes or closes, refer to where I mentioned extraction with GCFscape.
Now, navigate to the materials folder in the directory, and drag+drop the only folder in there, into your games materials folder.
Also, this is a VERY important step so do not skip this part. You NEED to have drag+dropped all the .wad files in your original Half-Life and 1.6 (Half-Life/Cstrike, and Half-Life/valve) directories into this folder (with vtex/xwad), and extracted ALL the textures from them, and put them ALL in your games materials directory, along with the .bsp’s textures. Some, if not most of the base textures from the game will most likely be used in the maps, and you’ll get invalid textures, and be forced to use new textures.
- Now, the fun part. The process of decompiling!
I suggest using Bspc-lessbrushes.bat because it will sometimes automatically take care of/clean up broken, and unused brushes in the map, thus giving your map a much better chance of not having a leak.
Once its done, it will tell you to continue.
Now you have two files at hand, the original .bsp, which you can either throw out, or put in your original game folder, along with the .map file. I HIGHLY suggest you store the .map file back in your store maps folder, because if you’re an avid decompiler like me, this mbspc folder can get very unorganized, or just make a separate folder where you can store .map files.
- Now, open the .map file in J.A.C.K.
The first thing I highly suggest you do, is do a quick clean-up of the broken areas of the map. This can be accomplished by simply going to Map>Check for problems.
Once there, scroll down to where the first entry called “Texture Axis Perpendicular To Face” is. This means the texture is broken, and will appear stretched, and off color if you do not fix this. This is imperative to fixing the map, as changing the texture simply does not fix it, this has something to do with invalid brushwork. Select it, and click Fix all (of type).
Now, if your map has a second entry where it may say something like “Invalid Brush (tiny edge)” or something of the sort, repeat the same process, click the first entry, and fix all of type.
Go up to file, and click save as, save as type .vmf in your Source/Csgo/etc maps folder. Make sure you name it first, too. If it is not in your cstrike/maps (assuming you’re using cs:s) your materials WILL NOT WORK OR PACK!
- 7. Open the newly created VMF file in hammer.
Wait a moment as it completes, then re-load the map, and CTRL+S to save.
Now that the textures have been re-applied, open map->Entity Report and take note of a few things.
- All func_door should be changed to func_detail. this is an old mpbhop method that is no longer viable.
- All func_water needs to be manually re-done.
- Logic_relay, trigger_changetarget, trigger_multiple, path_corner, and anything else inside of timer boxes need to be cleared. you can mass delete them with Entity Report.
- Light environment should be at a good pitch, use -90 for default.
- Func_button should be made into func_detail, they will be black if you leave them. This was an old addition to the in-game kz-timer which is now completely obsolete, so it can also be your choice to remove it entirely.
- Go to any func_ladder and delete it, and replace the existing brush that has a ladder texture with func_ladder. This is due to how in old Hammer, ladders were pre-existing, invisible entities that were placed in front of an unworking ladder. In new hammer, ladders are perfectly visible, and can be seen as another way to manipulate a func_detail brush.
- Select all info_player_start in Entity Report and click Properties. change the entity to info_player_terrorist, or info_player_counterterrorist.
- All func_wall entities NEED to be changed to func_detail. This was an old brush wrapping option that no longer works correctly when ported to the source engine.
- Click on map->map properties and make sure you have the skybox being used (only if you aren’t porting the skybox too, which is optional).
- * Do NOT remove any brushes with the tools/skybox texture, or change any brushes with this texture. These are essentially how the decompiler deals with nodraw brushes, and if you replace one, the entire map is most likely going to break, and the nodraw will be compromised.
- The map isn’t going to have a skybox most of the time. You’re going to have to go into Map>Properties and select a skybox from there. I suggest visiting https://developer.valvesoftware.com/wiki/Sky_List for a comprehensive list of skybox textures, and their default ambient/HDR settings, or you can use your own custom skybox texture, that is if only you know how to pak it properly to avoid errors.
- A recent work-around to finding random, unlit areas in your map presumably by a leak, is to wrap all the spots (black spots, we refer to them)
by holding ctrl+left click on the desired entities with the error, and pressing ctrl+t, then clicking yes, and changing their values from func_detail > to func_wall, applying it, then changing back to func_wall > func_detail.
It’s a strange bug, but we think it has something to do with an error in the conversion/decompiling process when converting the func_detail entities for the source engine for use.
13. Entities/brushwork named func_rotating, func_illusionary, and other entities may need their color set to white should be edited in their respective properties window, the reason they appear this way is unknown (completely devoid of light), but we think it's again just an error in the conversion from old to new engine.
Replace all trigger_teleport with the tools/invisible texture. The reason for this is that they can be buggy sometimes and this is a quick fix.
Regarding tight spaces, holes too small to properly fit in (which is a common procedure in porting maps but not always necessary as some maps don't have this) I would recommend rewriting it to keep all the open areas the same, but whenever there's a closed area/cave/tight corners with obstacles just resize that area by the offset of the cs 1.6 player model and the CSS one because no one will notice the size difference in big open areas, really only tight places, and manually resizing it with the vertex tool, avoiding the transform menu altogether.
If there are leaks, it’s probably because the skybox isn’t properly closing up all of the map (OR because the port didn’t come out clean and there’s a bit of missing brushwork/etc.) one quick fix for this is wrapping a new skybox around the entire thing, and just learning how leaks work in general https://developer.valvesoftware.com/wiki/Leak
Now, if you’ve managed to fix up most of the brush-work, if the map is complex and has a lot of pre-existing displacements, and brushes that needed to be fixed, or manually repaired, and the map looks to your liking, with all obsolete, or old entities removed, and cleaned up and ready to be fully tested, I suggest you test with lighting first. Go to File>Run Map, and test your map, with Vvis, and vrad checked under fast, then normal if the process goes smoothly the first time. The reason for this, is that with some computers maps don’t render in a quick amount of time unless you’re running them under fast settings. I’ve had this happen to me a number of times and it’s screwed with my productivity and ruined some good progress on maps I’ve tried to port in the past.
If the map has any black areas that are unlit, it means that particular brush is broken, and needs to be replaced manually.
If the map has any areas with stretched, red error textures, it means you didn’t do the Check for Problems step correctly.
If the map has any tunnels, or holes which are too small to fit into due to the old 1.6 crouch hitboxes being smaller, manually resize them, or make an entirely new way to enter the tunnel.
Sometimes, on occasion a map will have to have extensive re-working done on it, and most likely won’t even compile, let alone decompile with mbspc. An example of a map like this, is rvp_tundra-bhop. I’ve never fully been able to get it to work with the least required steps. This is an example of a map with HEAVY displacement, and complex brush-work that needs to be manually restored, and most brushes just don’t decompile as you would want them to.
Our current theory, or idea of how the decompiling process works is a bit tricky, but we’ve narrowed it down to the idea that a map is simply ripped directly from the gldsrc engine to source, so a lot of assets, and face brushes, vertexes are shipped over, changed in the process.
Each map contains a large number of skybox entities that surround the map, it’s CRITICAL you do NOT mess with ANY of these unless you have advanced lump/hexadecimal editing experience and know how to fix issues these things cause by hand, what these are are nodraw entities. These prevent you from seeing the rest of the map from the outside, even so much as retexturing one of these entities, or any of the triggers (it’s random as to which ones) causes severe issues and bugs, and most of the time inoperable leaks that render our vmf file completely corrupt, and the entire worldspawn inaccessible to the source engine by normal means.
We’re always striving towards perfection, and making our maps as less-leaky, and breakable as possible, and due to the fragility of our knowledge of how map porting works as of now, and the past year, we’re constantly facing issues like this.
If you have any suggestions, or ideas as to how to prevent certain things like this, PLEASE let us know.
A good number of our ports are just neglected, left in the dust, and most of them don’t ever see the light of day, because of our lack of knowledge, and discouragement from wanting to continue, and keep making more maps. This is evident in some of our maps not appearing fully finished, or rendered.
VERTEX TOOL NOTES
Vertex tool: vertices are stored in a floating point value with 3 decimal places while Hammer’s grid uses whole numbers. what this means is that while you may be using a grid scale of 8 units, the vertices can be out of whack and placed on .235 or whatever, they’ll need to be lined up with the brush, and on the grid.
this is an example of a messy brush caused by vertex inaccuracy.
If you find the problem areas then you can do Ctrl+Shift+B which snaps the brush individually to the grid and then move the vertices of the other wall on grid to meet it. If left untreated, vertex errors will make tiny cracks in your brushes where the skybox is visible.
Lightmap scale: when porting, all textures will have a lightmap scale of 0, try using 128 or 64 for less errors and a faster compile time.
Porting skyboxes: If they’ve included .bmp files for a skybox, simply Import them into VTFedit and save them as VTF.
Make sure to use a similar format to this in the VMT, since you’re creating an entirely new skybox texture. There are plenty of tutorials online I bet on creating a skybox texture, so closely follow those.
Porting models, and sprites: https://steamcommunity.com/groups/CrowbarTool
Using the utility crowbar, which I’m sure there are plenty of tutorials out there is the current standard for porting models over from the gldsrc engine.
Porting audio/sounds: The standard audio bitrate for source is 41000, I highly recommend finding higher quality sound bytes for audio, since the old bitrate for hammer was significantly smaller, and usually really low quality audio would be heard(around 11k) this isn’t necessary unless you’re aiming for a 100% perfect rendition of a map, which is entirely pointless.
Learning how to make a cue point is crucial in understanding how to make looping ambient_generic entities, if your map either wants to have some outside, indoor ventilation ambiance or just be really annoying [which I don’t recommend, since people might actually want to play your maps :^)]