I just had the files in the wrong directory, quark you have to your files in tmpquark. Quark won't compile it without a permission error. So, I use a batch file and still didn't work. I just had to change a bunch of lights at once. Finally worked, now the tough task of creatively lightning this older level. More questions...

Can the q3a tool bspc decompile quake1 maps? Because bsp2map, won't decompile scorn and other levels because of errors. Is mike reed still around? I'd love to give "crawling chaos" and scorn a modern look as an experience in mapping.

Also, I have new texture that comes off the wallpaper I made, if anyone's interested. I have the original PCD file, so I can remove the text.

Finally looking for mappers for ultimate deathmatch mod for quake. Mapping functions will be developed more, if someone is willing to map for it. I'll work with a mapper to develop it's mapping standards. If you can just convert a map DM or spq format, that's good. For now, just looking for interest.

as http://www.planetquake.com/ud/ 

decompilation of maps won't give you much to work with or learn from. you'll just have a really messy .map file. 

Yes, bspc does work, to an extent. You can't exactly recompile from it without errors though (unless the original is really simple). Normally only useful for figuring out entity setups.. or finding secrets n stuff.

About "Crawling Chaos"... it's author is now the admin of this site, so you might want to consider asking him about it. 

Yes, bspc does work, to an extent. You can't exactly recompile from it without errors though (unless the original is really simple). Normally only useful for figuring out entity setups.. or finding secrets n stuff.

About "Crawling Chaos"... it's author is now the admin of this site, so you might want to consider asking him about it. 

I clicked once & didn't refresh or anything... hm. 

Ok, this is an Quake BSP error message people have been getting since time began, but I've never heard a helpful explanation of it.

Basically what happens is that I build something nice, my brushwork seems tidy, it's all on the grid and all convex. All good. Then I compile and I get that bastard message.

I haven't noticed any major problems with the resulting bsps but sometimes it seems to fuck up brushes ever so slightly and causes very troublesome leaks as a result.

Can any of you compiler guys explain this error and/or know a solution to the problem?

I have been using Worldcraft exporting to map then wqbsp 1.65 by Ken Alverston 

I found a chainsaw weapon in the gamers archive,
but it does wierd stuff, specifically, the .mdl
is screwed up in normal glquake and some ports,
It works fine in Telejano but fitzquake makes it appear odd, like some of the vertexes were not where they should be,
any suggestions? 

May I suggest that you take a look at the tools found at http://user.tninet.se/~xir870k ?

There are enhancements, too numerous to mention, to the qbsp/vis/light tools.

As for the CutNodePortals_r warning, AFAIK you can safely ignore it. I've never seen it having any relationship with any real problem. 

which removes error messages, so as far as I know, everything is hunky dory :)

I'll check out your tools. I had actually seen them before and was planning to try them out but hadn't gotten around to it. Does you bsp support worldcraft exported maps? I think WC does something funny with normals and some textures can end up the wrong way around (particularly on 45 degree slanted stuff.) 

the tools together with any editor that can produce vanilla Q1 map files and they also support QuArK ETP format. With ConvMap, you can convert Q2 maps into Q1 if your editor produces that format (e.g. GtkRadiant).

As for the texture axis issue, I think that those who prefer WC+TreeQBSP always use the "-oldaxis" option. Using TxQBSP, there is only one variant and AFAIK, it works as it should with WC.

I personally prefer Tx because it's more flexible and it has all the important features of Tree. Both compilers produce near identical results on any map.

They have opposite default values for watervis though (backwards compatibility), Tree has it default off and Tx default on. Both can be switched either way, of course.

Both also have a multitude of options; run the compilers without parameters and they will print out a brief explanation. The rest is in the readmes.

Let me know if you run into problems. 

I looked at the weapons listing gamers has for Quake QC and there are several chainsaws listed. If you narrow down the file name, I'll be glad to take a look at it and see if I can clean it up for you. It could be a simple matter of turning some normals around. 

ch_saw.zip was the one that I tried,
Mainly because it had source included,
I didn't want to try and decompile something. 

#880 posted by xen [82.32.34.150] on 2003/12/24 21:10:47
>Yes, bspc does work, to an extent. You can't exactly recompile from it without errors though (unless the original is really simple). Normally only useful for figuring out entity setups.. or finding secrets n stuff.

Nope, I decompiled scorn with no trouble. Next, I recompiled with treeqbsp, rvis, and tylite with no problems, worked flawlessly. Just took four hours total with my dino p200.

>About "Crawling Chaos"... it's author is now the admin of this site, so you might want to consider asking him about it.

I sent him an email weeks ago, no responce.

I'm going to add eye candy to scorn and more rooms for the mapping experience... I'm not used to mapping in 3d, so this is a pain. For now, i'm re-lighting elmdm5(elmmagi series dm maps). I keep getting disoriented and changing the wrong lights, using the 3D window and normal xy and xz windows. Any tips?

as 

I used the Zerst�rer chainsaw in OUM, mentioned that it came from that mod. That seems to have saved me from being assailed by Psycho Copyright Lawyers From Hell.

There was another chainsaw mod I saw where you could climb walls with it, but I didn't use that since it wasn't as good looking. 'Sides, climbing walls would've scrozzled the levels. 

That came out wrong. When you view the 3D window in quark. The light entity shown has no depth perception. They look the same size no matter how far or how close you are to them. I'm having to look at all three window at once to find the right location to the light. I keep missing the target and changing the wrong light. Any tips as to how to nav better?

as 

I sent him an email weeks ago, no responce.

Uh, I hardly think that December 23rd qualifies as "weeks ago." Anyway, be patient and you'll get a reply. 

In the fast paced mapping world, days are weeks and every second counts! 

...nice colour scampie 

I just got back from me mum's birthday dinner. I'm going to work on it tonight. No biggie. Model making (and correcting) and texturing I consider fun. Animation, however, makes me cry like a wee little girl.

FC, that is a good sign, indeed. Perhaps, the fellows who made Zer~ no longer have a bulldog lawyer on retainer to sniff us rebellious, retrobate modders out for our pernicious tomfoolery. 

thanks, thought it was time for a change. 

I was rebuilding the model from scratch, rebuilding each frame as a seperate asc just to ensure no incapatabilaties between them (though I have a feeling the problem may be in the qc compatabilaty , I had the same problem with Fitz that you reported). The skin is in a non standard size for plain modelgen, and it would be no problem in QpenQuartz but I no longer maintain Linux or Cygwin on my system and the OpenQuartz utilities need the libpng.2.1.dll to function. Anyone know of an easier solution than extracting the .dll from a Cygwin build? 

Just to save time I built the mdl file with a nuetral skin and with the original id tools, and the same problems persist.

I checked out the .qc files to see if it was worth recompiling them (the file dates april 97 which makes me assume the progs.dat is out of date) but there are some problems in the naming convention. It is used as a replacement for the axe, and it keeps the IT_Axe naming convention in the player.qc file, but renames the mdl file v_axe, and in the weapons.qc the functionality for it is labeled fire_axe.
Mind, if the original programmer kept this consistent, it is not a problem in and of its self, but I have not spotted the necessary linkage between the model, postional name, and weapon function that would have to be there to make it function normally.

I'm just going to go ahead and recompile it as is and see what happens. 

#892 posted by metlslime [216.190.2.43] on
"Uh, I hardly think that December 23rd qualifies as "weeks ago." Anyway, be patient and you'll get a reply."

Actually, i'v sent a few over the last few years that I recall, Might have been bad adresses and/or got lost in cyberspace. Too bad you missed my raves about that level.

as 

The source code for that chain saw is good code. All the functionality connects as it should, and the gib spray code the programmer added is pretty sweet. The fact he was doing arm positioning back in early 1997 is impressive.

I recompiled it adding the player.qc file and weapons.qc to a clean version of v106qc, and these are the results using both the mdl that came with it, and my rebuild:

Unmodified (software) Quake -- It works
Telejano -- It works
Dark Places -- It works
Tenebrae -- It works
FitzQuake -- Chokes on it like something obscene
GLQuake -- boinked beyond belief

The only other one I would bother to look into is Tomaz Clean Source; the executables derived from it work so it should as well.
It is just a peculiarity of the way GLQuake reads model files. I believe a solution to this problem was posted over at QuakeC Extreme (http://qcx.telefragged.com) so I'll check into that sometime.

There are two other possibilaties -- include an executable with your project. I would personally ask Tei if its okay, he is pretty flexible, or, use FC's OUM as a source. Abuse his generosity for all it is worth. Take his turrent code while you are at it </;-)

Personally I like that chain saw source code you brought to my attention. The next step I'm going to take with it is to borrow my neighbor's Black'n'Decker and make a high polyversion for my darkplaces mod. 

One thing you might wanna try if it's looking all messed up in glquake, but working in other engines, is the mesh files(assuming you haven't already).

Glquake builds mesh files of quake models once, and saves them in moddir/glquake(and/or id1/glquake). Most modern engines no longer do this, as it causes problems if you change the model or load a different model with the same name. Instead they build the meshes from scratch each time you run it, as it's fairly fast.

So, I'd recommend deleting your glquake folders in both id1 and the mod directory. It is important to delete the id1 copy, as mods will look for meshes in there, even if the mod changes the model that mesh corresponds to. Don't worry about deleting anything important, all this stuff will be rebuilt automatically.