News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
Thanks. 
 
Saving the file to c/program files/worldcraft/textures...

Maybe I'll try saving it in the wally folder? 
Hooray For New Tools! 
No, I'm not done yet but I do have TreeQBSP running on OSX and it solved my recent compiling woes. Well, it's hacked together so it works anyway. I need to go back and fix my hacks and smooth out some rough spots before I can call it "done" but at least I can compile my level again.

I'll work on LIGHT and VIS next... Woot! 
Out Of Curiosity... 
What is the standard today in terms of WAD specification? I know that multiple WAD support is a must but is it generally assumed that the worldspawn entity has full paths to the WAD files or are relative paths still expected to work (i.e. "gfx/metal.wad")?

I ask because it's getting hairy trying to support both and would be easier if I could just support full paths. 
Initial BJP Tools Done 
These aren't perfect and require things like full paths for WAD files to work correctly, but they do work on OSX with multithreading support:

http://wantonhubris.com/BJPToolsOSX/

There are binaries in there as well as source code for those who are so inclined. I'll be massaging these a little as I get a new version of my level editor ready for release (one of these months), but these work! 
Willem 
relative paths are prefered. there is a maximum limit to the number of characters you can put in a string, so when using multiple wads, if you had to type in the absolute path all the time, you'd quickly use up those chars. 
 
OK, I'll have to come up with a set of rules about where it looks for everything then. 
Hmm 
Surely just getting it to check the folder the tools are in and <quake root>/gfx should be enough.

That and mebe a default WAD dir settings option added to search locales. 
 
Well, <quake root> and <quake root/mod>. There's a bunch of permutations. I'll figure something out. I'm probably just going to pass the Quake path and the current mod name to the BSP tool to give it a big hint. 
Hmm 
Shit, forgot about mods (again). But yeh, throwing it the Quake path and mod name should let it find the WADs easily without having to search the entire HDD... 
 
That's my current plan. I'm going to pass it the Quake directory and the current mod name. That will allow it to try looking in the gfx folder in the mod, the gfx folder in id1 and if those fail, use whatever it has as a literal path. That should be enough! 
Hmm 
User defined custom 'uber wad folder' path from settings?

(I'm just making suggestions, all my WADs are in the Q3 map folder with my compile tools/batch files) 
Wait... 
is is all this an attempt to avoid supporting both full and relative paths? 
 
It's cool, the code is written now. It support relative and full paths as best it can. Now to add multiple WAD support to ToeTag itself... 
Mapping Isn't All That Easy, Actually ... 
I'm having a bad feeling about my map ever getting finished.

First I got a (new) error, this time in the VIS, a nasty "Vismap expansion overflow".
I thought I'd try something to (try and)fix it, I made large parts into a Func_wall.
The (fast)Vis works OK now.
Only now the Light does not work, I don't get any errors but the level is full bright.

Now I understand the phrase "don't give up your dayjob" 
 
Well, mapping for Quake is actually one of the harder disciplines. Quake is relatively primitive and therefore has many gotchas for stuff that modern engines don't care about. It's very unforgiving at times. :) 
Ron 
Either your map is VERY huge, or it's leaking. Are you using the latest (Bengt Jardrup's) compile tools?
Turning stuff into func_walls has to be done with caution. It lowers the VIS time, but may well be contraproductive in other areas.

A map usually doesn't get fullbright over night (heh). Double-check your settings. Or maybe it's caused by func_walls + skylight.. 
Wait 
You didn't box it, did you? 
Post Your Compile Log 
So we can see it. Beware the maximum post length though, you may have to split it into two halves...

The QBSP log would be the most helpful 
This Is It, Without The Func_wall Trick, 
** Executing...
** Command: Copy File
** Parameters: "E:\Quake\ID1\MAPS\map.map" "e:\Quake\Id1\maps\map.map"


** Executing...
** Command: F:\gametools\WorldCraft\QTools\Qbsp.exe
** Parameters: e:\Quake\Id1\maps\map

TreeQBSP v2.05 -- Modified by Bengt Jardrup

Input file: e:\Quake\Id1\maps\map.map
Output file: e:\Quake\Id1\maps\map.bsp
---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
----+----+
13386 faces
2308 brushes
523 entities
79 unique texnames
2400 texinfo
27 texture frames added

Building hulls sequentially...
Processing hull 0...
---- Brush_LoadEntity ----
----+----+
2041 brushes
---- CSGFaces ----
----+----+
11736 brushfaces
14349 csgfaces
11889 mergedfaces
---- SolidBSP ----
15547 split nodes
6673 solid leafs
8717 empty leafs
158 water leafs
29675 leaffaces
26381 nodefaces
---- FillOutside ----
1177 outleafs
---- MergeAll ----
11626 mergefaces
---- SolidBSP ----
----+----+
7485 split nodes
3251 solid leafs
4188 empty leafs
47 water leafs
19866 leaffaces
15947 nodefaces
---- Portalize ----
4235 vis leafs
15742 vis portals
---- Tjunc ----
15158 world edges
55601 edge points
14249 edges added by tjunctions
2 faces added by tjunctions
---- MakeFaceEdges ----
----+----+
---- GrowRegions ----
Processing hull 1...
----+----+
----+----+
Processing hull 2...
----+----+
----+----+
---- WriteBSPFile ----
7856 planes 157120
22989 vertexes 275868
8326 nodes 199824
2400 texinfo 96000
17343 faces 346860
22072 clipnodes 176576
4994 leafs 139832
21337 marksurfaces 42674
81294 surfedges 325176
41390 edges 165560
106 textures 1737648
lightdata 0
visdata 0
entdata 40467

1 warning

Elapsed time : 0:16

Peak memory used : 22.1 MB

** Executing...
** Command: F:\gametools\WorldCraft\QTools\light.exe
** Parameters: -extra e:\Quake\Id1\maps\map

----- LightFaces ----
extra sampling enabled
523 entities read
lightdatasize: 364948
0 switchable light styles
83.0 seconds elapsed

** Executing...
** Command: F:\gametools\WorldCraft\QTools\vis.exe
** Parameters: -fast e:\Quake\Id1\maps\map

---- vis ----
fastvis = true
4235 portalleafs
15742 numportals
************ ERROR ************
Vismap expansion overflow

** Executing...
** Command: Change Directory
** Parameters: e:\Quake


** Executing...
** Command: e:\Quake\darkplaces.exe
** Parameters: +map map 
OK I See One Possible Explanation: 
You should run the vis tool before you run the light tool!

I would recommend compiling the map using a command prompt (windows "dos box").

Copy your tools (TreeQBSP.exe, vis.exe and light.exe) into your e:\quake\id1\maps\ directory.

Then go through your start menu to Programs=> Accessories=> "Command Prompt"

Type (without the quotes) "cd e:\quake\id1\maps\" then press enter

Then type "TreeQBSP map" (where I noticed that "map" is the name of your map :), press enter and the program will run as normal

Then run vis, i.e. type "vis -fast map" or "vis map" then press enter.

Then run light, so type "light map"

Note: If im telling you things which are obvious to you here please dont be offended.
It is definately risky to run light before vis, and I think that might be the source of your problem.

Awaiting more feedback....... :) 
I Didn't Know That ... 
[quote #8651 posted by RickyT23]
You should run the vis tool before you run the light tool! [/quote]
I didn't know that, I always assumed that WC's standard was the right way. I'll give your suggestion a try.

What do you think about the figures though ?
Are they what you would call high, and is there room for adding stuff ? I still have to put some things in.

PS. it takes a lot to offended me ;), I'm actually very happy with all your help and feedback ! 
 
It is definately risky to run light before vis, and I think that might be the source of your problem.
The order in which one runs them doesn't matter. Both tools create individual data and store them in the BSP - they're independent from each other.

Ron: it seems as though while you're using the new TreeQBSP, it's still the old LIGHT and VIS tools that come with Worldcraft? If that's the case, switch to the BJP ones and see if that helps. 
As For The Figures 
They aren't too high or anything. There's still plenty of room for new stuff. TreeQbsp will tell you if the map exceeds any of the BSP limits. 
Im Sure I Read Somewhere That Light Data 
in a map can screw up the vis process. Maybe im going mad! :)

Ron: Negkes right about the tools, use these tools:

http://www.quaddicted.com/tools/visbjp.zip

Also TreeQBSP is good, but I remember AguirRe saying that TxQBSP was better for some reason, TreeQBSP didnt compile sickbase IIRC.

TxQBSP:

http://www.quaddicted.com/tools/txqbspbjp.zip

:S 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.