thanks
https://db.tt/I9agOnHf 

 

You might consider cross-compiling for Windows and testing the build under Wine, since you seem to understand all of that.

Which would keep you in driver's seat, which is seat anyone wants to be sitting in.

Here is a cross-compiling tutorial for CodeBlocks: http://forums.codeblocks.org/index.php?topic=3343.0

CodeBlocks Cross-compiling Wiki Entry: http://wiki.codeblocks.org/index.php?title=Code::Blocks_and_Cross_Compilers

Video Tutorial on cross-compiling: https://www.youtube.com/watch?v=3-yw-aD8CTI

Then you can make tweaks any time you want and build a Windows binary whenever you like. 

The Quakespasm team may already have a way of cross-compiling up a Windows build. 

Yeah, I'll sort it myself. I was trying to avoid clogging up my system with too many dev apps and libs, but last night I started down that road anyway.

Thanks for the links too. I'll dig a little deeper into it. 

QS has some build_cross_*.sh scripts in the Quake directory, they'll need to be edited depending on your Linux distro/version.

The cross compile scripts I use for windows builds on my jenkins setup are here: https://github.com/ericwa/quakespasm-build-scripts (somewhat specific to my jenkins/ubuntu 14.04 setup. IIRC I started with build_cross_win32.sh and modified it a bit to work on that system.)
Pretty much all I installed with apg-get was the "mingw32" package plus "build-essential". 

https://www.dropbox.com/s/iko14xmbe0gvwwq/Quakespasm-IRC-0.1.zip?dl=0

requires dlls, they're packaged in the source code if you don't have them 

is it possible to add the monster count to the scoreboard of game(s) Return to Castle of Wolfenstein and/or Sin and its MP 

So, i'm looking to have the player collect a key in my map and then later be teleported in front of the door the key is supposed to open.
As part of this sequence, the door opens *jazz hands* for "effect" very slowly, beginning as soon as the player has been teleported. Unfortunately, this means that the player never actually touches the door to remove the key!

Basically, is it possible to either use some kind of entity setup to remove the key from the player without having them touch a door, or is it possible to create an entity that *looks* like a key, but isnt?
Thanks! 

I looked into it, and on the advice of others, decided that it wasn't possible to directly remove the key from the player in vanilla quake.

Instead, I settled for a solution where the player moves over an invisible door that is instantly removed when they touch it. That door takes the key from them at the appropriate time :D 

That can be done by entity hacking: http://www.celephais.net/board/view_thread.php?id=37116&start=377

(It's in there somewhere). 

I want to use the earthquake trigger, but I only need it once.
So I use the killtarget option but it doesn't seem to work that way.
The killtarget is allready used for starting and stopping the earthquake within a given time.

I only need it once, but when I use the killtarget on it, it just goes on triggering the earthquake all the time.

What is going on there? 

Is not being turned off, and it probably works independently of the trigger itself, being a looped function.

Try triggering the earthquake entity again instead of killtargeting it.

Should work, but I don't know what code base you're using. 

I got two codes, one with only an earthquake.qc and the one from DoE. They both seem to act the same.

killtarget is allready in use, and there's no way to calm it.
I thought on trigger_once wait -1 but it fails. 

I remember using a one-off earthquake in FMB-BDG2 and I can see from the map source that I used a trigger_MWquake, which suggests I wrote or adapted some code.

I don't have the source anymore (I have no idea why not as I still have the map files?) but you could decompile the progs in that and have a look for the code I used. 

there should be a trigger_earthquakekill entity. Check the rogue or hipnotic entity fgd's. 

from gtkr def for rogue:

/*QUAKED trigger_earthquake (.5 .5 .5) ?
The Earthquake generator.

Anytime a person is in an active
field, they shake. If the trigger is a
target, it will be OFF until triggered.
It will then toggle between ON and OFF.

weapon - richter scale of movement
(default 40)

weapon - if you give a weapon value of
40, the X and Y displacement
can vary between -20 and +20, a range of 40.
*/

i don't know why modern editors other than radiant don't include the description text. it's very useful! 

Ah, yes, that was the restriction that made it not as useful as I wanted, so I adapted the code to make it switchable only.

/*QUAKED trigger_mwquake (0 1 0) (-8 -8 -8) (8 8 8)
A switchable only earthquake trigger.

Keys:
"delay" - duration of the tremor
"weapon" - richter scale of movement (default 40)

(Funny how I have kept the BspEditor, the entity defs and all my map files, yet not kept the code - this is really puzzling me as I don't usually throw anything out e.g. 10,000 of my own photographs at 24meg each, half of which I will never look at again? I have to get to the bottom of this; I must have some HDDs tucked away somewhere.) 

Can anyone suggest a decent progs.dat decompiler. I realise I wont get my notes included, which may be s stumbling block for me, but I now have a bee in my bonnet about getting to look over the code I wrote.

I have tried frikdec from 2002 but it fails to retrieve all the modules and doesn't do very well with those that it does. 

I tried to understand the earthquake.qc.
I extracted it from the SoA code and found client.qc and defs.qc changed as a earthq.qc.

Only using the earthq.qc is usefull but there are eight parms in use.


void() earthquake_rumble
void() start_earthquake
void() stop_earthquake
void() earthquake_touch
void() earthquake_use
void() trigger_earthquake
void() kill_earthquake
void() trigger_earthquake_kill


What I found is that the trigger_earthquake_kill is in use for the delaying the earthquake.
So when I tried to add a new one to kill the earthquake for ever doesn't work.
OK. So keep out of the area where the trigger_earthquake happens will do, but then I keep tat thunder sound throughout the level. 

When checking vanilla's texture loading code, I found the following line, in both software and GL rendering:

pixels = mt->width*mt->height/64*85;

That is later used to allocate space for the incoming texture. My question: why do we need to take the amount of space needed for a texture, divide it by 64, and then multiply it by 85? What does those numbers even mean?

(Could it be that somebody was trying to cover up for a hard-to-find bug in the engine? Seriously, I have no idea...) 

It's not a bug.

The calculation is the formula for adding the 3 levels of mip textures that software Quake uses to determine the byte size.

main mip1 mip2 mip3
64x64 ... 32x32 ... 16x16 ... 8x8 

assuming count is 16*16 (the minimum allowed):
count + count/4 + count/4/4 + count/4/4/4
256 + 64 + 16 + 4 = 340
giving a ratio of 256:340. simplifying that gives 64:85.

thanks to textures needing to be a multiple of 16, textures are guarenteed to be a multiple of 256 pixels, so dividing by 64 is safe.

this might not be true if you tweak your renderer to misalign the 1:16 lightmap ratio, but this sort of thing would break software rendering.
most gl engines just discard the original extra levels and use only the top-level image, so maybe you just want to nuke that part entirely. 

Embedded mipmaps!

I see what you mean now. In fact, vanilla GL code actually does discard the incoming mipmaps. This happens in GL_Upload8(), which calls GL_Upload32() after copying the texture into a static defined trans[] array (ewww) containing only the bytes of mipmap 0.

Seems like they were in a hurry to deliver the game. What d'ya know? :)