#106 posted by JneeraZ on 2008/10/05 23:45:03
"You can observe a side effect in fitzquake if you turn r_showbboxes on; a removed entity creates a bbox of that entity's size at the origin. "
Hahaha, so THAT'S what that is. I wondered what that box at the origin of the world was. Thanks! I thought my code was doing something wacky...
Jesus
#107 posted by necros on 2008/10/06 01:03:51
9_9
Mind Melting Code
#108 posted by Preach on 2008/10/09 15:54:07
Ok, I dug out the monster I wrote a few months back, here's some code which actually tracks all of your removed entities in a linked list. The file is pretty thoroughly commented, with a big block of text at the start describing how you might use it, and how to integrate it into a standard qc source.
http://www.btinternet.com/~chapterhonour/chaintrack.qc
The main application is a new field on entities you can read called .reused. Positive/zero values of .reused mean the entity is currently spawned, negative values mean it's currently removed. The absolute value of .reused gives you the number of times the entity has been removed previously. This gives you an index you can compare to see if a stored entity differs in number of removals from the value it used to have - i.e. it has been removed and restored.
I've tested it with fitz, bjp and dp, and it seems to function correctly in all 3. If anyone wants to know how it works, I can post that up too...
Custents
#109 posted by madfox on 2008/10/10 08:07:10
I was trying to add some doombirds to my map, and couldn't find the right movement for the thing. If I use a func_train it worked, only the sight of a plane flying backwards is a little queer.
So I took the custents and saw the map with the falling wall. It has a four way movement train that uses func_rotate. I integrated the doombird in it and it worked out fine again.
One thing I can't get is
why can I jump on the func_train in custents,
and why do I drop through it in my own version?
I'm Guessing
#110 posted by necros on 2008/10/10 09:23:20
you mean func_rotate_train and not func_train?
in which case, you need the oft-posted czg rotation tutorial which, ironicall, i don't have the link to. :P
Append
#111 posted by necros on 2008/10/10 09:24:17
that's to say, the tutorial explains how to get collision on your rotaters. it's kind of wierd and annoying.
Thanks
#112 posted by madfox on 2008/10/10 10:00:53
necros, the turning goes al right.
it is just that funny behaviour that when I play the map falendoor of custents I can stand on the func_train and I rotate in eyesight.
when I transponse the map coordinates of that func_rotate_train to my own the train isn't solid anymore. (?!)
Oops
#113 posted by madfox on 2008/10/10 21:18:46
forgot to include func_movewall. Now it's solid.
There's an odd point where the func_rotate suddenly behaves like a counter-turn in the opposite. Can't fly the thing without Doom patents.
Just
#114 posted by ijed on 2008/10/10 22:27:29
To throw a spanner in the works -
Would it be possible to have the plane as a model, with all it's takeoff animation (turning etc.) done in Qme?
Or would the size of the animation break the model - look in the wrong direction and the game assumes you can't see it because it's in a different visleaf.
There's Something Worse That What You Mentioned
#115 posted by necros on 2008/10/10 22:40:10
about doing it that way.
the way that vertex coordinate info is stored is completely relative.
this means that no matter how big or small your model is, the only thing important is how far from the origin all the vertices are.
this has an impact on the resolution of the model.
in quake, you could make a miniscule model of a bolt and it'll look completely fine.
but if you made a huge wall with the same bolt in the middle, the bolt would be messed up.
this is because the huge wall caused the scale of the vertex 'snap' to be larger.
if you made a plane model that was fully animated to fly around in, say an area of 1024x1024, your plane's vertices would probably be so low resolution as to not even be able to make out what it was.
as an example, look at the amount of vertex dancing on the vermis model. compare it to something like the fish model (which hardly moves) to get a good idea of how it impacts vertex position.
Another Way To Look At It.
#116 posted by necros on 2008/10/10 22:42:33
imagine that a vertex in a model can only be on a grid of 256x256 units. it can rest on any even number from 0 to 255.
but that this grid can be stretched in all directions.
so if your model was 1024 units tall, it's vertices could, internally, only snap to a 256 tall grid.
that is to say that in the game world, the model's vertices would fit on every 4 grid units, instead of every 1.
#117 posted by JneeraZ on 2008/10/11 01:25:55
Ahh right. I was going to call you out on that resolution thing but then I remembered Carmack's 256x256x256 cube compression stuff. Yes, quite the ugly issue.
Ijed
#118 posted by madfox on 2008/10/11 03:21:41
this is aa far as I have come with the the doombird and custents.
Coding a mechtech is somewhat harder, but would be better.
http://members.home.nl/gimli/dbird.dz
Ha!
#119 posted by ijed on 2008/10/11 15:06:11
That's pretty fun. The collision seems to go a bit nuts and just do its own thing, but even so.
Maybe some Qc to add grenade style smoke to the jets?
As To The Model Thing
#120 posted by ijed on 2008/10/11 19:01:42
So to do it with a model would require a func_modeltrain of some sort then, so it wouldn't just dissolve into a mess.
That explains why all the monsters seem to have Parkinsons in their idle animations though.
#121 posted by JneeraZ on 2008/10/11 20:15:10
The larger ones anyway. The Shambler has way more error in his verts than, say, a soldier. The rest of the jittering comes from the fact that, I believe, Quake only supports integer locations for vertices.
I'm
#122 posted by ijed on 2008/10/11 20:37:40
Used to engine side vertex interpolation so don't usually notice it so much, except when looking at the models in raw state, as it were.
Swung
#123 posted by madfox on 2008/10/11 21:27:50
custents support the func_rotation and the func_rotate_train.
I'm trying to understand these options to get a better flyer.
that strange swing don't seem related to the func triggers.
Haven't found out where it comes from.
Reason that in custents a part of the func_rotate is hided.
Armor
#124 posted by madfox on 2008/10/14 10:35:53
I succeeded to create a health bowl and give it a health strength , by adding a health function in the qc.
I thought giving it armor points would be that easy. But it isn't.
There are only three IT_ARMOR types.
By substituring one I get my extra powerup object of ten armor points.
But not as alike the health paks I can only take one at the time,
the rest stays non solid as if I have taken a full armor .
To Clarify
#125 posted by Preach on 2008/10/14 12:49:50
I want to check what you're trying to do here. You would like an item which gives a boost of, 10 points of armour to a player who picks it up. So far, you've managed to make an item which gives the player 10 points of armour if they pick one up, but then subsequent ones will only top the player back up to 10, and if they are already at 10, then it doesn't increase.
To me, that sounds exactly like what would happen if you rewrote the green armour to have 10 armour points rather that 100. Have I read your aim and current result right?
Yes
#126 posted by madfox on 2008/10/14 12:59:29
I trie to reproduce the armor powerup with skulls, like in Doom
Items
#127 posted by madfox on 2008/10/14 13:05:41
I was rewriting in the items.qc
+---------------------------------------------+
void() armor_touch =
{
local float type, value, bit;
if (other.health <= 0)
return;
if (other.classname != "player")
return;
if (self.classname == "item_armor1")
{
type = 0.3;
value = 100;
bit = IT_ARMOR1;
}
if (self.classname == "item_armor2")
{
type = 0.6;
value = 150;
bit = IT_ARMOR2;
}
if (self.classname == "item_armorInv")
{
type = 0.8;
value = 200;
bit = IT_ARMOR3;
}
if (self.classname == "item_skull")
{
type = 0.1;
value = 10;
bit = IT_ARMOR1;
}
if (other.armortype*other.armorvalue >= type*value)
return;
+-------------------------------------------+
};
void() item_skull =
{
self.touch = armor_touch;
precache_model ("maps/skull.bsp");
setmodel (self, "maps/skull.bsp");
self.skin = 0;
setsize (self, '-16 -16 0', '16 16 56');
StartItem ();
};
+---------------------------------------------+
It's The Last 2 Lines
#128 posted by Lunaran on 2008/10/14 15:35:18
they skip the pickup entirely if the armor you're touching is weaker than what you have. you need to add a special exception there for skulls that add 10 armor and keep the preexisting armortype.
Additionally
#129 posted by Lardarse on 2008/10/14 15:52:25
You should check for the player having no armor, and if this is the case, set their armortype to green (0.3 and IT_ARMOR1)
You may also want to set a limit for both health and armor shards. Probably at 250 or soemthing like that. I don;t know if the 3 numbers at the bottom are limited to 8 bits, but even if they're not, you might want to not let them get out of hand...
Addition
#130 posted by Preach on 2008/10/14 17:54:08
There's another problem with this code, which is the way armour and health packs differ in increasing stats. A health pack adds on a certain amount of health to the amount you started with. Armour always sets the value to the same amount, regardless of how much you had, it's not adding anything on. Code like "add on 150 points to his armour, but then if the total is more than 150, cap it there" would be redundant.
So you're going to have to write something more complicated.
|