That it likes to crash at certain times, so I ended up saving before doing anything I know is risky. I also save compulsively and rarely get crashes.

The one you mention, than, seems to be the compiler crash. It always happens with a bigger than small map build or two. It's not a problem since it's shutting down anyhow, but annoying when it doesn't remember last map worked on on reopen.

Orl - I thought you used QuArK? 

Why did you think I used Quark?

Ever since day one of mapping, I have always used Worldcraft 1.1a. And sometimes 1.6.

And 1.1a can crash much more frequently than 1.6, if your not careful. 

;)

Always use 1.6a, tried the 3.3 conversion but it needs some stuff ironed out - the wad limitations mainly. 

I have my reasons for using 1.1a than 1.6.

And yes, I did try the 3.3 conversion, and after a minute I immediately lost my mapping erection. 

Also, an implant can help with the other problem. 

... certainly not related to hardware. I'm up to date with all that :) But here are my reasons why I prefer 1.1a to 1.6

1. Zooming. In 1.1a the zoom value is about .06 for each zoom in, whereas in 1.6 the zoom value is .50 and this frustrates me, because either its too close, or its to far away. At least in 1.1a, there are much more zooming values and I can map comfortably.

2. Slowness. 1.6's 3d view runs much slower compared to 1.1a. Even if it's the same exact map, 1.6 renders it much more slowly than 1.1a, thus making texture alignments a real pain in the ass, and I'm forced to use visgroups, which you don't need in 1.1a because it never slows down. And another weird thing. The wireframe 3d mode in 1.6 renders MUCH slower than textured or solid mode. But in 1.1a, Wireframe mode renders much faster than textured or solid. Whats up with that?

3. Selection handles. I hate these things. They not only distract me from the actual brushes themselves, but they sometimes get in the way of other items, normally entities. Thank god 1.1a doesn't have them.

I may have a few smaller gripes about 1.6, but these are the real main issues. However, I do have positive things to say about 1.6

1. No file size limit. 1.1a has a .map file size limit of about 1800kb. 1.6, as far has I know, has no limit.

2. Better shearing manipulation than 1.1a.

Thats about it really. All those extra features in 1.6 I do not use. Anything 1.6 can do, 1.1a can do as well, to a degree. And there you have it. 

I had no luck fixing the leak myself, so i sent it off to AguirRe. He said that he really couldn't do much, as it seem that my curves were not exactly snapped to the vertices, so it was causing the compiler all sorts of headaches. So i thought that perhaps if i scaled up the size of the pipe, that would make it large enough to have all of the vertices lie on the grid. I rebuilt, and tested, and was met with failure. Several times, to the point of my girlfriend imploring me to stop working on it.

(I didn't)

Well, since this wasn't working, i rebuilt the pipe example in CZG's tutorial, which obviously compiled without incident. I compared this to my failed ventures, to see what was different. I'm pretty sure i've isolated the issue.

In order for curved pipes to compile properly, it would appear that:

The diameter of the outer region of the pipe must be equal to the radius on the inner section of the pipe.

On the pipes i was trying to make, the above ration was not used, leading to a leak every single time.

I'm guessing that if the ratio stays the same, it betters the scalibility of the pipe, so when it's stretched in strange and unusual fashion, it causes for vertices to be formed off-grid. Or something.

Does this sound cogent? 

You have to think in base 2 (8 for doing the stretching). Basicly everything in games works on power of two and is sqaure. The textures in Quake that are rectangular slow down the engine because it basicly converts them to square before drawing.

The wedge used for the pipe bending is 2x4 to the grid, which means all subsequent structures are based off that ratio, if it's different or off-grid then it won't work, like you say, lots of holes and warped shapes.

Hopefully that makes sense, but usually you just have to sit there in editor and mess with it until it clicks. 

The textures in Quake that are rectangular slow down the engine because it basicly converts them to square before drawing.

Okay, this isn't really true. Video cards (except some of the newest ones) can only handle texture dimensions that are powers of two, but they don't have to be square -- a 64x128 texture is just fine, for example.

Second, non-power-of-two textures don't slow the engine down except perhaps for a few nanoseconds at load time when the engine resamples them to a power-of-two so that the video card will accept it. But there is no performance hit during play. 

Although I did mean power of 2 textures that are rectangular.

The problem with non power of 2 on modern cards is that a default colour is generally inserted to fill in the space and make them power of 2. Which can cause some strange visual effects, like a load of black lines marching down a wall or pixellated artefacts on eg. a fontsheet. 

is that really true? I would think that sort of artifact would result from bad resampling done by the application.

I assumed that the cards that truly support it (using ARB_texture_non_power_of_two in OpenGL for example) would support it seamlessly and without artifacts -- otherwise, what's the point?

However, I have not personally seen it in action. 

A fontsheet is typically 1024x2 and we spent nearly a week trying to sort one out, convinced it was an art problem but unable to find it. Turned out nobody thought to check the dimensions. Random letters had a one pixel almost invisible line along one edge, but depending on the tv / where the text was on the screen it could be invisible.

We weren't building for PC but it's the same kettle of fish. Turned out the image template was saved in 1023x1024, thanks to some option of the fontsheet exporter. These are the basic kind of things that are overlooked for platforms, like full .png support etc. 

what platform? are you sure the hardware really supported it and there wasn't some code in the API that silently resampled it at load time?

I confess to know basically nothing about console development, except that PS2 devkits are really noisy. 

;) 

One beastie I'm working with at the moment has a bounding box as big as the doggie but a model that is quite low to the ground. The player can actually jump over the thing. So, does collision detection work differently model:model and model:world? 

...I'm using fitz80 (with a custom progs) and when I'm in -developer 1 and have the SNG, if I shoot a brush object I get a message telling me what it is (worldspawn, func_wall etc.). Is this a feature of fitz80 I've never noticed or the result of ineraction with the progs? 

The bounding box of the model is only used for the engine to determine when it needs to render it. But the hitbox set by the QC with setsize() is used for collsion between player and monster, for instance. So if the height is set low enough you can indeed jump on them.

And that SNG message was a dev thing I put in to try and fix a bug, it'll be removed in the next version. 

Hi,

Having some problems getting a lwo to convert into a map or bsp? Any recommended tools or utils? A lot have disappeared over the years, anyone got any on a dusty harddrive. Many thanks.

iain.price@hotmail.co.uk 

...you are the bomb, as usual.

I definitely won't be binning that progs version :). It's annoying when one is "playing" in developer mode, but might be extremely useful when one is debugging a level. 

...I'm using fitz80 (with a custom progs) and when I'm in -developer 1 and have the SNG, if I shoot a brush object I get a message telling me what it is (worldspawn, func_wall etc.). Is this a feature of fitz80 I've never noticed or the result of ineraction with the progs?

huh... must be the progs :) 

Checking your post to make sure it isn't broken? Or ever returning to the thread?

That stuff's tough... 

That should have been in the Jobs thread.

(Posting in the right thread? That shit's damn-near impossible.) 

There are several Quoth add-ons being developed and the current situation is that all have to co-exist in the main Quoth directory. This is cumbersome and highly error-prone both for developers and players as pak files must be arranged/renamed to avoid conflicts. When more paks are added, the situation will deteriorate pretty quickly.

I'll probably add a new engine option -quoth to solve this problem in the same manner as other major Q1 mods; hipnotic, rogue and nehahra. This option will make it possible for each new Quoth mod to have its own directory and still load things from the main Quoth dir. So instead of having a command line

-hipnotic -game quoth

you'll have e.g.

-quoth -game warp

(if the mod is called warp) and instead of having conflicting pak files all in the Quoth dir, you'll just have the overriding ones in your own mod dir, beginning with pak0.pak and upwards as usual. Engine resource search order is then current dir (the mod dir), quoth and finally id1.

The -quoth option will automatically set the -hipnotic behaviour for the engine (basically the status bar), but will not add the hipnotic dir in the search order, i.e. it will not require anything from hipnotic paks. AFAIK, this is how Quoth wants it; it doesn't require hipnotic to be installed to work.

The engine code to add this behaviour is simple, just a few lines in a few source files and it follows the same manner as all other major Q1 mods. I'm testing it right now and it seems promising.

Any comments to this? Have I missed something? 

while i think that's a really cool idea, wouldn't it be better to have a way so you could load any mod like that? ie: quake -base quoth -game warp so that it could work with any other mod out there where people would make new mods for it. 

LordHavoc recently modified -game in Darkplaces in a very interesting way.
Usually you want to put replacement content in either id1/ or another directory such as pretty/ inside your quake directory, in DarkPlaces you can run multiple -game options at once (such as -game ctf -game pretty -game dpmod to have texture overrides from pretty, maps from ctf, and gameplay from dpmod) or multiple gamedirs specified with the gamedir console command (gamedir ctf pretty dpmod).
I wonder though what priority there is. Looks like the last -game overrides the previous. "-game first second third" would be more logical on a first glance for me where first is the "master" (overrides all previous). Dunno.

"-base quoth -game whatever" looks nice to me. One should not want to use more than 2 mods at the same time anyways (normally). It would be a bit nicer if something was changed in .pak usage. Like getting rid of the pak0, pak1, pak2 and allowing any name for them (maybe even proceed to .pk3 or just .zip/.7z/something). Maybe choose the paks with 1..., 2... in their name to be first, second priority.
Just brainstorming. ;)