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. ;) 

The multiple packs pending are going to be awkward to arrange properly, so this is a great idea. It has other side bonuses as well - quicksaves, screenshots and demos (etc.) will be kept seperate, allowing clean folders without conflicting junk confusing what's where.

Warp enters final beta in seven days since I've got plenty of time to work on it atm; having this feature will allow me to avoid stepping on anyone's toes or mangling the end-user's Qouth folder.

Good idea! 

I thought about that too, but then you'd lose the custom connection with hipnotic behaviour, which means you'd have to specify that as well.

More important, this is a really simple extension and it's not like there are dozens of major Q1 mods ... This is basically the first SP mod after Nehahra that needs this treatment.

As for DP, AFAIK it already uses precisely this syntax probably more than any other engine for all its supported mods; nehahra, transfusion etc.

Simplicity might also be imperative to getting metl to put it in Fitz soon ... ;) 

So, this is something i've thought about before.

The way -game works is it adds a few extra paths onto the list of searchpaths for loading a file. For example, if you are playing rubicon2, then quake would try to load each file from locations in the following order:

rubicon2/pak0.pak
rubicon2/ (unpacked files)
id1/pak1.pak
id1/pak0.pak
id1/ (unpacked files)

There's no reason you couldn't add more -game commands on the command line and have them added to the searchpath list (after increasing the array size so it doesn't overflow.) Paths at the top of the list would always override paths further down the list.

I would prefer to mimic darkplaces syntax (-game quoth -game mymod) for the sake of standards, rather than "-quoth" which would be inconsistent with DP and would provide less general functionality (since it only works with quoth.) But I understand that you'd still need -hipnotic.... hmm.

In the case of fitzquake, since you can dynamically change moddirs using a "game" command in the console, I would have to modify the command to take more arguments... "game quoth mymod" for example.

One weird thing about -hipnotic and -rogue is that they do more than affect the searchpath list, they also change some things in the HUD. Fitzquake currently can't turn that stuff on or off in the console, unfortunately. It's something I should look into. 

I can see how -quoth makes the task simpler from a coding standpoint, so maybe your idea is the right one :) 

ever was a standard in handling add-ons to add-ons, it *is* the -hipnotic, -rogue, -nehahra syntax. All engines work like this and should therefore be able to add this option without problems.

My proposal is a simple and neat solution to a growing problem. Once you start generalizing it, it'll just be more convoluted and less coders will be interested in adopting it.

A few simple lines in a few source files, that's it. In my engines, it's actually only two files and the header file is optional since the var is only used in common.c.

It should also be noted that a Quoth mod that's distributed in this way, will not shut out all other engines that don't support it. The player will then just have to re-arrange the pak files in the main Quoth dir instead, and this is something they'd have to do anyway.

The only drawback I've seen so far is that someone (like me) that regularly swaps engines while testing mods, will have to make some arrangements when using engines that don't support the -quoth option.

But I think I'd rather have that, than the pak file mess in the Quoth dir that I have now. 

i meant standard in the sense that the only engine that can currently load quoth + another mod is darkplaces, so if we copy that then all engines do it the same way.

However, I support your plan for its simplicity. You could probably convince lordhavoc to implement it in DP as well, since he often adds things to DP that are motivated by the needs of specific mod projects. 

of course the question of Quoth2, should it be put in the main Quoth dir or should it always be included in newer Quoth mods?

The former is the most space-saving alternative, but it basically requires that Quoth2 is completely backwards compatible in order not to break existing Quoth1 mods. Also, it requires that any further Quoth core development has the same characteristics.

The latter requires more duplicated files in newer mod distributions, but OTOH it'll not break anything and is the preferred route if Quoth is going to be further developed. There's a lot more freedom in this alternative.

Naturally, both routes will quickly become a seriously complex mess if new Quoth mods are placed in the main Quoth dir (which is the current situation).

There are of course more alternatives; e.g. to rename the existing Quoth dir to quoth_old and put together a new Quoth dir that essentially is Quoth2, which then can be used as the base with the -quoth option. Or add yet another engine option -quoth2 that automatically will include both dirs in correct order.

But all this is probably stretching it too far, this is not a proposal to solve any and all potential problems in the bright future when there are dozens of new Q1 mods in various versions being released each month ... 

The way I handle multiple pak files is with symlinks.

I name my extension pak "plaguespak.pak" and make a symlink like this:

ln -s plaguespak.pak pak(number).pak

That way I always know what is inside a pak file.

It's the same with progs. dat and (Q2) gamei386.so files; I have a progs.dat.qdq linked to progs.dat, a gamei386.lazarus.so linked to gamei386.so etc. The expansion pak retains a meaningful name _and_ the engine thinks everything is OK.

In my mod directories (like BB, hipnotic etc) I have the corresponding speedrun demos; I just dumped the paks in there, named them nhrun.pak and linked them to pak(number).pak. So I can easily watch a NH run of the map I'm on without changing gamedir or using complicated command line switches.

I guess that's expecting too much from the average windows user though :-/ afaik symlinks are practically unknown in that culture. 

I don't know what the hell you're talking about ;)

Now for wikipedia . . . 

No problem. At least you didn't ask if I was taking drugs.

A symlink is practically something that looks like a file, has a name like a file, but in reality only links to a file.

You can have a file called pak0.pak whose single purpose is to link to another file. If your Quake engine calls for pak0.pak, the symlink pops up and says "Hey! That's me!" and in reality only redirects the Quake engine to "quoth.pak" or whatever (any path really.)

Thus your Quoth pak can keep a name that means something instead of being renamed to pak0.pak (where you quickly forget what the hel is inside it.) Pretty neat feature.

When you combine this with shell scripts, you can do all kinds of stuff with files (create a symlink before you start your program, delete the symlink on shutdown, automatically... anything. You can redirect binaries to a number of different config files etc.)

For example, I have extra X11 config files for games in fullscreen mode. The game gets their own X server, their own config... and afterwards, everything looks like normal again. (X11 is Linux' windowing system.) The benefit is that nothing else uses that instance of X11, so the game runs faster/better. Symlinks are used to redirect the X11 program to non-default config files.

yadda yadda :-) it's practical for PAK file housekeeping purposes, that's all.

I also use symlinks to my Quake config in my mod folders.