Read a bit about the 220 map format, and if I understand correctly, you can't really convert it to standard map format without loss of information. The texture axes stored in the map file cannot be reproduced in Quake because Quake uses a combination of two axes of the world coordinate system for the textures (hence the limits to texture rotation lock in standard Quake). Or do the extended compilers that come with the Quake adapter for WC 3.3 do some extra magic here? 

WC can export to .map. Are there differences between the Arcanum .rmf and the .map sources apart from the junk Hammer inserts? Which format corresponds to the bsps? 

"that seems pretty much impossible, I can't imagine how that could happen, fuck. In a month when I'm back I'll find the vised ones if anyone still cares I guess."

ReRelease it for QuakeExpo :D 

arc5: xvyyrq fbzr mbzovrf naq fpentf, "1 zber gb tb" ohg gurer vf abguvat ncneg sebz Fuhool (jub V'ir gevrq gb xvyy). Jung abj? 

If you don't find anything, there may be a spawning issue. 

You make the map in .rmf, then you export it to .map, then you compile the .map using txqbsp or any other compiler which has support for valve 220 texture format. If you want to edit the source you have to edit it in .rmf (because if you load the .map file into an editor many of the textures will become mis-aligned. But if you just want to re-compile then you should be able to just use the .map files included in to source. 

That's cool, so the textures do not get misaligned if you compile the map with a compatible compiler, then play in Quake? In other words, no oddly stretched textures on faces that are not on the coordinate planes anymore? 

tbh Valve 220 format needs to die, it causes unnecessary problems with the workflow when cooperating / teamworking etc.

Just my opinion. Quake is messy enough already. 

I'm still wondering whether it actually fixes the texture alignment / stretching problems in Quake or not. 

Without it texture lock wouldn't work and it would take a lot longer for (me) to make maps. 

 

about the doomishness that Negke noted - I felt that way too. It was a good feeling.

Also, though I found it initially frustrating, I really like the 1st map, and I feel like it's getting weirdly picked apart. I mean, look at that second screenshot - I'd be proud if I had made that area. And the part with the blood was awesome!
Other than being way to hard in the beginning, I feel like Arc1 is a very nice 'little' map. 

You mean texture lock would not work without Valve 220, right? Just to make that clear. So the texture coordinates that compilers (which understand Valve 220) generate using the texture axes stored in a 220 map file are perfectly fine for stock Quake?

I'm asking because (TADA) I'm working on an level editor for OS X and I'm wondering whether I should support Valve 220. And if the above is true, it looks as if I should. 

from my brief time working in HL2, i recall the hammer 3.3 texture alignment was more accurate in some ways. you could rotate a face by strange angles (3, 86) etc, and the textures would never move. there were also texture alignment helpers that were not present in quake editors. for example, you could align a texture across multiple faces that were not on parallel planes.

otoh, this could just be down to poor coding on quake editors? i have no idea how tex alignment works but it seemed like the quaternion thing gave extra info that helped do complex tex alignment. 

It may be possible in standard Quake map format, I'll have to investigate, but my feeling says it isn't.

And there are no quaternions in 220. The map format allows you (or the editor) to specify arbitrare texture axes. In standard Quake, it always uses the two coordinate axes that have the largest angle to the face normal. Textures are then parallel projected onto the faces, which also leads to the skewed textures you see on faces that are not parallel to the coordinate planes. 

what standard QBSP does. It generates texture coordinates from that, so it might be possible that extended compilers allow proper texture application without a change to the engine. This alone would be a big improvement. 

And there are no quaternions in 220

oh ok, i just saw [0 0 1 0] in the .map file and assumed it was that. 

So did I at first, but it's the offset plus the coordinate axis for X / Y. 

I dont really know the inner workings of it, or whether or not it is possible to make a completely accurate texture lock without it, I just know that the texture lock in Worldcraft 3.3 and 3.5 works better than any other i've used. But if you made an editor which could load a '220 map and than save it into a standard .map format so that you could then load that .map file into any other editor - that would be very useful :) 

The map would look different after conversion. The textures would be skewed. If that would not be a problem, you can simply do the conversion by hand by converting "[o x y z]" to "o" I think. 

...doesn't even begin to describe this map pack. While the first map may have been the weakest, it was still fun and clever. The rain looked a bit odd yes, but it convinced me it was rain and I just went with it. But what I liked most about the arc1 was its haunting atmosphere. The music wasn't a bother to me either, it added to the creepiness.

The next four maps, as I said, astounding. The gameplay, the lighting, the brushwork, the textures, everything was stupendous. Its hard to, because of the fast run and gun gameplay, but you really have to stop and admire all the details and interconnectivity of the maps. Some of the best I've ever seen in Quake.

This pack is no doubt a perfect 10 in my book. Congrats on a job well done :) 

Cool brushwork and layout (except those trees). Much too cramped in some places.

I turned the volume down all the way because the music was just too nihilistic to me and there was no way to switch it off ingame. Then I turned the brightness all the way up. That's when I noticed the cool brushwork. I also turned on godmode - on easy :-/

If you make it mandatory to "kill all monsters" in order to proceed, please tell the player so.

If the player presses a button, please tell them what that button did.

The exit was sort of hidden.

-> Too dark, Easy too hard, zombies/axe sucked, music not optional, not always clear where to go next / what to do next.

-> Nice brushwork and layout. Could have been highlighted better by more light.

Streams of blood: A real blood sacrifice is pretty unspectacular compared to this. :-^

-> Drake: Didn't like ported Hexen 2 monsters (use new skins at least). Found the staff a little goofy. Shotgun could have a new sound instead of what people are used to as the SSG sound (it's confusing). Axe should instagib zombies. Beheading was cool. 

Also, it would have been good to combine the start map and the first proper map of the pack, to avoid the loading screen in between. A start map only really makes sense when you have different branches. 

The music can be turned of with impulse 117. I agree the new shotgun sounds are bad (ssg sounds weak).

Since the release is going to be updated with the fullvised maps, maybe a few other changes could be made as well? Eg. counter message in arc1, a megahealth for the zombies on all difficulty levels, maybe even monsterjump them off the coffins; NO_INTERMISSION on the arcstart changelevel! And whatever else was mentioned in this thread.. 

No, a start map also makes sense if you can select the difficulty. That's the sole purpose.