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
S S 
Those were missing from the above post.

Also 'brush entities' as opposed to 'entities'.

Having a baby is the greatest thing in the world, but your head is all over the place for lack of sleep. 
. . . And 
Its an optimisation (AFAIK) of AguirRe's that the compilers don't light all brush entities no matter where they are, like id's did.

Definately a plus, but also shows another b0rky map feature common in the originals.

Mind you, very easy to be aloof ten years+ after the fact. 
Thanks for the help! The last post is what i wanted to know. I found it weird that the original quake maps had different lighting when starting in Worldcraft. Thought it was a problem in my Worldcraft configuration or something.But that explains it all.

And i am not sure if you notice that the in_game_screenshot.JPG was a screenshot of the original E1M1.bsp not mine small testing maps.

Anyway Big thanks! 
Yeah 
That's why I said that AguirRe (who's compilers come bundled with the wc3.3 adapter) made optimisations that id didn't.

If you used their compilers it'd work without showing the door black but take alot longer. and run very slightly slower in game I think as well. 
Congrats Ijed! 
you lucky father and happy mother.

apparently the same goes for a good map:
Having a map is the greatest thing in the world, but your head is all over the place for lack of exit. 
Thanks 
silver_key-gold_key-exit.

change-feed-sleep.

Now that's a nerd comparison. 
Pak File Programs 
PakExplorer: 'explorer' type view, limited to 8 character filenames. sucks.

PakScape: 'explorer' type view, not limited to 8 character filenames. converts all upper case chars to lower case and progs.dat is case sensitive. sucks.

DZip: not limited to 8 chars. doesn't change char case from upper to lower. is NOT an 'explorer' type view, just a long list of crap so very difficult to organize pak files. (as it's primarily for zipping demos anyway).
sucks.

are there any other pak file programs? one that doesn't limit file chars to 8 or change the case around and that has a proper way of displaying files so as to be able to organize things well? 
Heh 
That is one thing QuArK can do very well. 
 
there is a pak plug-in for total commander. It satisfies my needs for exploring pak files. 
 
i was under the impression that both of those could only open and extract files from paks? 
 
Nope, QuArK let's you save just fine. 
 
I have just tested and the tc plugin is creating pak's as well. Very straightforward 
Necros 
Pakker 
 
thanks :) i wasn't able to check myself today.
wasn't able to find pakker though, but i should be able to use quark as i've already got that. 
Pakker 
Wad Problems 
so, i made a few pathetic textures and im trying to get texmex to put them in a wad, like i did once before i think, but now when ever i try to import it gives me "was ignored" on all the textures

the textures are in .bmp format and i believe they are 8 bit color

...i don't get it any clues? 
 
i remember that happening, and don't really recall why it did, but i'm pretty sure if you convert your bitmaps into 24bit targas, the problem should go away.

it might have to do with the 8bit bitmaps not having the correct palette (it's not enough for it to be 256 colours, it has to be the correct 256 colours). 
 
Are the bitmaps compressed? That might be it. 
Copy 
Your texture, then 'paste image as new mip' in TexMex. 
Ok Thanks 
those both worked :D

... i don't know how to compress bitmaps so i dont think i can decompress them :S 
Brush Heaps 
I'm working on a terrain map. I use triangle shapes to lift the corners to equal heights and then use force to grid 1 to fit the brush.

Sometimes the brush takes the grid on a counter line and it is possible to move the brush back into its original position, gaining a clean, converted brush.

Othertimes it gets out of grid and causes the vieuw to get out of position.
http://members.home.nl/gimli/align.jpg

The first method , without forcing to grid, brings a well compiled map with errors, caused by the compiler with warnings and heling points. But a fitting brush order.

The second , with force to grid and reposition, brings a misaligned map with less errors and a better compile log, and a rather blurry brush fit.

How to avoid the process and which would be best suitable?
I never minded thes misalignements, I'm already glad the compiler takes it. But then again, the small difference could change vistime considerably. 
 
when i make terrain in qe3, i just do my terrain mapping in 3d view after copying and pasting all the triangular shaped brushes i need.
i keep the grid on 16 (or 8 if i need fine details) and just pull individual vertices up or down depending on what i need in the 3d view.
this usually creates good results for me. 
Actually 
It would be really ace if editors allowed you to select say, 4 brushes and lock 4 vertices which all interleap with a simple keyboard shortcut, then you just drag the locked vertices into the appropriate position as one, and then "ungroup" them. 
Yeah 
or when you rotate a group of brushes. why do editors persist in snapping vertices to different points when they were initially sharing the same one...

also, why does firefox keep underlining 'vertices' like i'm spelling it wrong. what a bastard. 
Heaps 
As I read, I think my failure is caused by using the 1 grid option in force to grid. It turns out to become a disordered 0.x grid position that hardly can be healed. 
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.