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 

that's bloody top shelf. Cheers mate :} 

has anyone tried using triangular pyramids instead of triangular prisms for trisouping?
allows a lot more freedom (almost like working with individual faces!) at the expense of a bit more work.

...or does everyone use pyramids now? 

Most people use pyramids now. Just banging some terrain together only needs triangles, but they tend to produce bugs.

Of course, there's always: http://nemesis.thewavelength.net/index.php?p=8 

Most people use pyramids now

this sounds messy - do you have any links to examples? 

Not really - and yeah, it can potentially be a mess.

I can post a couple of test maps later on if you like. 

i shouldn't bother unless you've already made something - i doubt i can be swayed from the path... 

yes, it's quite messy in the viewports. 

We've got a test folder full of odds and sods, there's definitely at least one or two examples in there.

Can't check from the office though. 

So. what are all the cool kids using these days to turn a Maya animation into a Quake .mdl? 

just found the modelling help thread.

Lunaran to the rescue it would seem :} 

If Noesis is mentioned on there:

http://oasis.xentax.com/index.php?content=downloads

Which is a multi-multi format that also supports Quake stuffs. Could be a decent alternative. 

More options can't be a bad thing, right? My current favoured method is to export to MD3 files, and then compile them into Q1 format using md3tomdl. I like calling it compiling because it suggests the same kind of workflow as iteratively tweaking/compiling/testing a map. It also makes the process sound irreversible, so that you always keep the model editable in a more suitable format. Like keeping your master recordings in wav files rather than converting them from and to mp3 each time you want to remix...