Preaxch Delivers
#465 posted by Qmaster on 2017/05/03 05:15:41
He's the best.
Custom Bmodel-type Entity
#466 posted by negke on 2017/05/29 17:05:31
Another noobish question that I feel has either been answered before and I'm too dumb to find or can't remember.
I know how to create custom stuff based off other entities using their model/modelindex values, but how do I make an info_notnull brush entity appear in the first place - visibly, that is. A function to get it started on the actual bmodel, like InitTrigger for trigger volumes.
Thought I could make a simple nonsolid prop that's doing something or nothing depending on the touch function. Problem is nothing shows up in game.
I Believe
#467 posted by Qmaster on 2017/05/30 00:31:18
You need to use a func_illusionary hack.
Displaying A Model
#468 posted by Preach on 2017/06/02 00:39:17
func_illusionary has the problem that it makes the entity static straight after, so you can't make it interactive.
Probably the best thing to do is to use
http://celephais.net/board/view_thread.php?id=37116&start=36&end=36
to create a visible entity. If the "model" key added to your brush entity by the compiler is "*1", you need to use modelindex 2 (0 is no model and 1 is the world, 2 is the first "free choice" slot).
You'll probably need to handle any interaction in separate entities (e.g. killtarget this entity) - InitTrigger interferes with this trick, likely because it calls setmodel.
#469 posted by negke on 2017/06/02 17:24:39
What I mean is having a brush-based info_notnull show up in game like a normal entity would - instead of 'visually cloning' an existing entity in a point info_notnull. All in one edict if that's possible. It appears a brush info_notnull strips itself of its own model/modelindex properties unless if used as a trigger volume (the model=bbox part in this case).
Trigger Volume
#470 posted by Preach on 2017/06/02 18:45:03
The trick does work with a single brush-based entity (referencing the modelindex of its own model). It is - like you suggest - when you turn it into a trigger that things go wrong, because the trigger is trying to do its own thing with the model code which interferes with the modelindex hack. If you didn't want a trigger, you'd probably be OK.
#471 posted by negke on 2017/06/02 19:09:25
To avoid a possible misunderstanding: I'm not using any trigger stuff, just mentioned it as an example.
I can't seem to get it working as a visible entity just like that, even if I make the info_notnull reference its own modelindex (unless I'm doing something fundamentally wrong and can't see it). That's why I thought perhaps there was some neat think function to run (in a similar way that InitTrigger that makes the bbox appear); sort of like "think" "func_wall", for instance, but without the hardcoded behavior this would add.
The weird thing is, I'm under the impression that for a while I had some floor bits show up just being brush info_notnull without any extra fields, but at some point during development this ceased to work. IIRC, anyway...
Brush Based Entities
#472 posted by Preach on 2017/06/03 22:50:17
If you add a brush entity with classname "info_notnull" it gets translated by the compiler something into this:
{
"classname" "info_notnull"
"model" "*1"
}
What may vary is the number after the * in the model key. What you want to do is add keys to that brush entity so it ends up like this after compilation
{
"modelindex" "2"
"mdl" "progs/player.mdl"
"think" "SUB_regen"
"nextthink" "0.1"
"classname" "info_notnull"
"model" "*1"
}
The tricky part is that you need that modelindex key to be 1 larger than whatever number the compiler decides to put into the model key. The numbers are given out in order by the compiler but if you delete other entities or do something to reorder them in the .map file it may change.
If you do all of that, you should get a visible entity which is only different from a func_illusionary because it is non-static and so can be killtargeted or given a use function. You can probably move SUB_regen into the classname slot and use a different think function as well. However, bear in mind that many other hacks (like the aforementioned trigger stuff) does break this hack, it's pretty fragile.
Timed Power-ups
#473 posted by Orl on 2017/06/04 02:42:57
We know its possible to make any item respawn, but is it possible to make power-ups last longer or shorter than the usual 30 seconds? For example a biosuit that lasts a minute, or a quad damage that's only 20 seconds. Can this be accomplished?
Thanks Preach
#474 posted by negke on 2017/06/05 10:07:53
Finally got it to work. Apparently the "mdl" field is crucial whereas "model" doesn't have to be specified in this case. This is different than with point-based cloning which got me confused. In game, whatever is referenced in "mdl" is copied over to "model" as well, so I set it to "*1" (or rather the respective number of the model) instead of player.mdl; either seems to work as long as the modelindex is correct. However, the hack also required me to set "mins" and "maxs" for the entity to be drawn. The "think" function, on the other hand, seems only necessary if the entity is supposed to be used further, e.g. for a touch action.
Playing around with mins/max/size/origin made me curious as to whether it's possible to customizable trigger sizes from point entities like in Quoth...
Orl: I briefly tried it a couple of years ago. If it is possible, then at least it has to be more complicated than simply calling "powerup_touch". You can replicate the visual effects like that, but not the actual powers.
#475 posted by R00k on 2017/06/07 21:03:53
@orl, yes increase the nextthink to respawn,
```
if ((self.classname == "item_artifact_invulnerability") ||
(self.classname == "item_artifact_invisibility"))
self.nextthink = time + 60*5;
else
self.nextthink = time + 60;
```
and for each pwoer up theres a *_finished timer
this is in items.qc
@R00k
#476 posted by Baker on 2017/06/07 23:34:02
Thread title "Teaching Old Progs.Dat New Tricks" means needs to work with original progs.dat, typically via entity/think/field abuse.
It's a shame you don't play single player maps, some like negke manage to do seemingly impossible things in maps that work in original Quake.
Is there a way to place a static corpse in vanilla quake? Like a 3D model of a killed grunt or something? Is there a way to add custom entities? if so is there a place that has models of dead grunts or enemies?
Thanks
#478 posted by Baker on 2017/07/19 12:10:36
You can do a corpse in a map. Do a func_illusionary and set the model (like progs/player.mdl")and frame number (like 169).
In vanilla quake there is no way to add custom entities.
Interesting, thanks. I'll have a play around :)
So i create a brush entity, set it as func_illusionary, and then add the keys "model" and "frame" ?
Like this?
http://imgur.com/7bNARAr
#481 posted by Baker on 2017/07/19 13:09:57
Create a point entity, set the type to func_illusionary and yes change the "model" and "frame" (it *may* be "mdl" if "model" doesn't work).
Like if you were creating a monster.
#482 posted by Baker on 2017/07/19 13:13:16
(There are differences between TrenchBroom and Jackhammer. In Jackhammer, you create a point entity and change the entity type. I would assume you can do that in TrenchBroom, but couldn't swear to it.)
Ah yep it works! great. Is there a place that shows the various model names? like gibs for example?
#484 posted by Baker on 2017/07/19 13:21:18
Open up pak1.pak in Pakscape 0.11 and look in the progs folder. To find out frames, you would have use QME to look at the different model frames.
https://www.quaddicted.com/files/tools/qme31.zip
Without opening a model in QME, it's gonna be hard to pick the frames for most models as all the monsters have dozens of frames.
You also may want to set "angle".
amazing thanks, that should give me everything I need to make some nice corpses...
I tried setting angle as -1 and rotating the entity but it doesn't seem to change the angle it appears at. Say I want the player model to appear lying on its back facing upwards - shouldn't angle -1 do this?
Also it seems like some models work and others dont. The soldier.mdl doesn't seem to work at all and the map wont compile.
Could this be something to do with quakespasm having less models in its pak0.pak and having them in a pak1.pak instead?
It seems to have the paks reversed compared the original quake paks
It Has To Be Precached
#487 posted by Qmaster on 2017/07/19 13:54:48
Include at least one monster_army in your map.
Set yaw like normal to rotate the corpse.
-1 won't do anything since that is a special case for doors. Set the frame correctly and the model will be in one of its lying poses. You may want to check out the qc files to see which frames are death poses.
ok cool, thanks. I tried adding a monster_army but now I seem to be having a problem of the entities disappearing when I select something else. Using TB2. None of the entities I've created are visible (I tried show all in the view) and the map is still failing to compile and citing lack of precache)
Here's the map file:
http://www.mediafire.com/file/hqd3m3bwq3qe61n/Outpost17.map
as soon as I deselect the func_illusionary entities they seem to disappear...
#489 posted by Baker on 2017/07/19 14:18:38
"angle" is typically 0-359 like degrees for non-door/non-platform entities and operates as yaw (like pitch/yaw/roll, the 3 different x-y-z axis in Quake).
|