Cheers for the info. max vis distance sounds interesting but i can't really think of it being useful in my map. 

try this one: http://www.quaketastic.com/upload/files/tools/windows/wvis_20100117.7z

sorry, i didn't check when i posted it. 

nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

That one has a bug, http://www.quaddicted.com/files/tools/wvis_20100119.7z is the right one. 

negke was bugging me about how I keep buggy and outdated files to which I replied that I do and that someone should write a nice guide on http://www.quaddicted.com/tools/map_compilers instead 

i knew the date was wrong (17 instead of 19) but i figured it wasn't anything important. :x 

http://www.quaketastic.com/upload/files/tools/windows/level_editors/wvis_final.zip 

that should probably be moved into /upload/files/tools/windows/misc/ instead of /upload/files/tools/windows/level_editors

that's actually why i posted the wrong one earlier, i wasn't looking in level_editors, just misc. 

i am making a quake 1 map and when i test it using the darkplaces engine, i do not see any problems. i loaded it up in quakespasm engine to test compatibility with other engines and i get this hall of mirrors effect when i walk past a certain point in the map.

i tried to find out if the map has leaked by typing pointfile in the console but it says no pts file could be found. i checked qbsp.log, light.log and vis.log and the files do not mention any leaks. when i fire a rocket at the HOM, it ricochets and eventually the trail of particles appear at the opposite side of the map.

here are two pictures of the bug i am seeing:
http://i.imgur.com/S4oS4h.jpg
http://i.imgur.com/ChU2Dh.jpg
http://imgur.com/a/E1xv0

any tips on how to get rid of this bug? it does not occur when using darkplaces engine to test the map.

i am using the compile tools found at this page:
http://user.tninet.se/~xir870k/
i am using the wvis_final.zip WVis 2.31 version of Vis.exe 

Does your map exceed 4096 units from the origin in any direction? That would explain it, this is a limitation of most quake protocols, exceptions include the darkplaces protocol and the RMQ protocol. 

That's the 4096 effect. Move the whole map until it's inside the 4096/4096, -4096/-4096 square. 

it seems that this is correct, looking in the editor, the HOM is appearing at the 4096 line on the x-axis in the editor. i had started at the origin at started building north from there. moving the entire map down to fit in this 4096 limit has fixed the bug. thank you for helping! 

from necros: the problem is that you only have 16 floats that you can carry across to other maps, 10 of which are already in use. if you wanted to do anything more complex than fire a few triggers off, you're out of luck.
the best you could hope to achieve is to use bit fields on the 6 (7 if you get rid of one parm that's not really needed) to get 6 * 24 = 144 on/off states. and that's incredibly limited.

I've been thinking about this - you could free up some more parms by combining them in a way that doesn't feel too hacky. For example...

QuakeC's floats are 32-bit right? Does that mean you get 7 sig. digits? If so, you can reduce the # of parms needed to store all the info, e.g. Parm4 could store counts for both shells and nails; you need 3 digits for each - e.g. if you had 52 shells and 143 nails, then you could extract this info from the number 143052 (to get the # nails, just divide by 1000 and round down - getting the shell count is also trivial). The other info for cells, rockets, health, armorvalue and whatnot could also be compressed to make full use of the available digits.

Also am i right in thinking parm9 can be ditched? (armor type can be stored in parm1 - items) and so could parm8 - the player's currently held weapon could just use the seventh digit in one of the ammo count parms.

By my estimates this could free up 5 of the currently used parms...

Maybe this is a bit silly i dunno. 

yeah, you get 7 digits. i guess you could even store a third 3 digit number in the decimals?
floor the number, and subtract it from the original, then multiply by 1000.

that's really clever, storing multiple ammunition counts into one parm! :)

and yeah, you can totally get rid of the armor type. (that's what i meant about the parm that's not needed)

you could even get a few more flags by moving temporary items out of the .items flag during parm saving/reading because they end up being zeroed anyway. things like keys and powerups. 

actually you can go full retard with it and only use 2 digits each to store health, shells, rockets and cells, because you can set 00 to mean 100 for both health and shells. (Health is never saved as zero, and shell count is never saved below 25) Also, you can do some silly cheese with flags to discriminate between 99 and 100 for rockets and cells too, I'm sure :}

I'm overthinking this aren't I? :} 

use binary? An unsigned int with a max val of 127 needs 7 bits. So you can store 4 o these in a 32bit float and still have 4 flags. 

of course... all you get is more flags. :P 

By golly, you're right - i can assign a hex code to a float in quakeC to make full use of all those bits right? I forgot i could do that... 

i'm a tard - i'm thinking of literals. Not sure how i'd manipulate the bits of a float in quakec programmatically. 

You best ask Preach about such things. Necros, I thought Kinn was only encoding two values into a 32bit float. With binary encoding, you get four numbers plus four bits. 

i was just commenting on the flags in general.
no matter how many you have, they're still just bit flags.
you can't save monster positions or anything like that, which for me is the real draw of trying to save information. 

 

Well, it's possible, and if you really wanted I could look around for the code because I know somebody else has done the legwork already (probably Frikac). But the basic idea is just to learn everything about how IEEE 754 floats use the 32 bits in a floating point number and then reverse engineer it bit by bit (no pun intended).

So you'd start by reading the sign of the number, which gets you one bit. Then you calculate the size of the exponent which gets you 7 bits*. Using the size of the exponent you can then multiply by an appropriate factor to get a integer stored in float form with 23 bits of value you can read off in the usual qc way.

*The exponent of a IEEE 754 float is actually an 8 bit signed char, but setting it to 128 indicated the special values like infinity and NaN. Consequently you can't encode or decode the mantissa of those floating numbers, so you have to limit yourself to 7 bits. This also luckily allows us to completely avoid the topic of subnormal numbers by sticking in the range 64 to -63. 

Well, it's possible, and if you really wanted I could look around for the code because I know somebody else has done the legwork already (probably Frikac).

Cheers, if it's easy for you to find I wouldn't mind taking a look at it, but I'm far from being at a point where I need it right now.

All I was thinking of doing was storing a load of level state flags that persists across the multiple levels of an episode, and I reckon I could do that easily with the couple of hundred flags I've already got access to via the unused parm variables without needing to compress the already used parms too much, if at all. 

Scrounged that code you wanted out of the Prydon Gate codebase, a mod written by Frikac, although some of the comments suggest LordHavok had a hand in writing this portion of it. So I take no credit for the code, and in fact have never tried to use it. Nonetheless it looks fairly well devised, the functions split the job into digestible chunks, and the comments describe the restrictions.

The extra nice bonus I failed to recall was that this bit of code is already being used for data storage in parms - I only remembered the decoding of floats. Have fun...

http://www.btinternet.com/~chapterhonour/parms.qc