Forum posts

@The303

Thanks for confirming that and @SourceSkyBoxer
Thanks for the tip

I wish scripted were much more flexible and interesting...

I've been wondering what 'export to .DXF' option is in the File menu. Does it have to do with making custom animations for scripted sequences? Like exporting a portion of map geometry to that format to line up the animation with???

Shepard62700FR

I already tried that and to no avail :/

Torekk

Its not a detail texture I'm trying to make work, But as for the first option I guess I will have to

If its possible I would like somone to find a workaround other than making a texture with the decal; so when I get home ill already have a solution.

So I take it there's no way; no workaround; for a decal on a brush rotating in place... Oh well, at least I can take comfort in that its not just me lol but rather a limitation.

@Unq

"Decals can work on some moving entities, func_doors for one."

Could you make a func_door rotate in place on an axis? I cant test it right now cause I'm out of state...

Why is it they dont work with origin brushes that's weird... Seems so random...

When I have a brush with a decal on it and then tie that brush to an ORIGIN brush the decal disappears after compile. Would anyone happen to know why this happens??? The brush is a func_rotating entity and when ever I bind to an ORIGIN brush causes the issue.

I have other brushes of the same type without ORIGIN brushes and the decals on them don't disappear after compile. I have also tried applying the decals after tying an ORIGIN brush to an entity brush.

Well, I'm using vhlt v33 so maybe if use vhlt v34 compile tools then that problem might go away.

I was doing something way to precise because i have trouble staying to a 32 sometimes 16 grid for the basic architecture of the map. I just redid what I had when sticking to a 32 grid and everything was okay im experimenting with arches and thy're a little tough to use correctly

I think it's every half unit unsnapped

Unchecking 'snap to grid' doesn't seem to work really. I zoom all the way in and it seems to still be 'snapping'. Is this a bug with hammer 3.4?

@Dallas Thank you very much for the information. I always learn quite a bit on this website! and everyone else who replied thanks as well.

alright it seems ill have to do a little more work I think i'll live not being old school. Im getting to know hammer to become efficient and proficient !

Edit:A quick question about multi_managers I can't seem to find out what the # sign means. For example welder1mm#1

a better option would be to use the new func_detail from latest compile tools for hl1, it has a thing called level of detail or something so you can control who cuts who and stuff, if you really want to

Im not trying to cut anything, but simply shaping interiors via intersecting shapes and for added challenge, using all default tools.

[url] https://upload.wikimedia.org/wikipedia/commons/c/cf/QuakeMapTrim.PNG[/url]

above is basically what im talking about.

EDIT: A bounding box would most likely solve the problem

really... Well how could I go about it then? is it even possible?

If I make a hollow room and use another unhallowed solid to intersect into the room and make the solid an entity of func_wall will VIS compiler
cull the faces of the intersecting solid facing out to the void? outside the hallowed room. (func_wall because the faces of the world brush won't be split up)

hence over time lol. I have other ambitious things that I want to do like finish learning to program in C++ first and foremost.

both. map modification and looking at entities + to get the hang of mapping. I'm planning, over time, to do all 90 single player maps. Like everyone has played the normal game in sven coop so I want to shake it up a bit

Textures map 1:1. 64x64pixels = 64x64 units

I got my problem figured out finally! my textures are not 1:1 scale i forgot that I passed the -s2 command option BSP_slicer which halved the original scale

EDIT: Since I couldn't seem figure pixels -> units and have the result be a brush of the right size I instead used the decompiled map geometry as a guide for making a brush the exact size of the level then divided that into sixteenths and lo and behold the textures mapped perfectly!

EDIT: Is there a limit to how long someone can keep a thread going?

Textures map 1:1. 64x64pixels = 64x64 units

are you sure? thats 4,906 units. I did 256 x 256 = 65,536 x 0.25 =

16,384sqrt= 128x128 units

Sorry for the long post, but I know what the problem is. In the case you described is not what happened to me. What was happening is that it was giving me the access denied error cause of a command option I was trying to pass was not recognized. I have cut up my 1024X1024 textures into 16 pieces at 256x256 size to get around texture memory limit instead of passing a command that isn't recognized.

EDIT: The maximum texture size for Goldsrc is 512x512 right?? I cut my texture into 4 pieces of that size and I get a checkered pattern.. using
The steam version of half-life

EDIT: Apparently it's 256x256 but im confused about texture pixels to hammer units 1 px = 0.25 units so 256x256 = 64 x 64 units but it isnt the right size!!! sigh... Ill figure it out eventually

But of course there is no disadvantage. However I guess I'm a glutton for pain because I feel that I learn more the more I have problems to fix and issues to work around. Maybe after a bit quake compile tool use I may have earned the right (in my mind) to use tools like Zoners

I've had an itch to get back to mapping and to stick with it recently. I wanted to dissect Half-life maps and see how certain things worked so i could hopefully be a more competent mapper among other things. I decided to use the steam Half-Life SDK with Hammer Editor 3.4 that it comes with for reasons I might get to later in this post. I also went to Botman's site and picked up a couple of tools I found convenient for my purposes.

In the config I set up my directories and build programs directories, wad file paths, and so on. For the build programs I used the valve proprietary compile tools. During the mapping process I used custom 1024x1024 (~1mb) textures made with bsp_slicer.exe to rebuild the basic map geometry (perfect practice for mapping) cause, you know... decompilers don't do a very great job they like to carve the whole map from a single brush block and is a huge mess.

I couldn't use the textures at first cause I could not simply select it from the browser and then press apply in the texture tool. Instead I had to awkwardly replace the gaben trigger texture with the 1024x1024 ones. Then I could use them normally... weird... I also had to have the whole brush selected as well because how the replace feature worked differently when a single face was selected(don't remember the exact details).

So the math is a 1024x1024 texture applied to 6 sides of a brush is 6 megabytes, which is 3 times over the texture memory limit (~2mb). This is the best I can figure as to why I was getting the compile error MAX_MAP_MIPTEX. Looked up this error and it said that I was using to many textures which exceeded the alotted memory limit. Well that didn't make any sense because I had the minimal amout of brushes to create a working map and not that many textures.
That's when I realized, of course, it had to be the massive texture size I was using.

I didn't want to break them down because I thought it would take to much time (later on I found you can do it really
quickly with photoshop cs3). So I had also read you can pass the command option -texdata 4020 to qcsg.exe to increase the memory limit to ~4mb. When I tried to compile again I got a diferrent error which was: Windows gave the error "Access Denied". Orignally I thought windows didn't like me modifying a tool set to read only or didn't have
Administrative rights, or UAC was causing this, or my configuration paths were somehow wrong.

Come to find out when running an elevated console and compiling my .rmf file directly with qcsg.exe plus the command
option -texdata that qcsg.exe doesnt recognize that command and I later find out that command was for Zoner's version of the compile tools. So naturally decided to use Zoner's tools, but to make a already long story short, the tools made bsp files that GoldSrc Steam Half-Life didn't like because it would crash with a fatal read error.

So I've decided to stick with the tools that came with Hammer Editor. I see it as a challenge and dicipline to make
these maps with the quake compile tools(I'm a bit of purist anyway). The whole point of this post really is to talk about the Access Deinied error because there isn't much information on it at all. So I hope that this gives a little
more light on this error.

Yeah i had a couple of errors and fixed them and it worked. Thanks for the reply. Im happy again.

I deleted some prefabs and put in two different ones. When i compile the map and test it the prefabs i deleted are still there and ones i thought i compiled in are not. Thank you for reading.