|
Czg
#3919 posted by Mike Woodham on 2005/07/17 11:20:05
All done and working. Thanks.
I haven't altered the origin changing as I had already seen that that part was OK.
I had already been down the 'if/then' route but the two main errors were: resetting the counter wrongly, and the missing self.nextthink before the SUB_Remove.
Once again, thanks. Now, back to mapping...
.cnt Warning
#3920 posted by Preach on 2005/07/17 12:19:34
I thought .cnt was a nice safe field for monsters, I was wrong. It's actually used for checking the refire rate in nightmare skill. So it's probably safe to use here once the monster is dead, and won't cause terrible problems if you use it for storing properties like spawnflags(it'll get reset after one pass through the ai system - at most two shots). But don't use it for something that needs to persist throughout the lifetime of the monster, or it'll break in skill 3. A few safer fields for monsters are
.worldtype (only used by the world, a total waste in the original code)
.light_lev and .style (only used for lights, and even then mostly for the compilers)
Nearly any of the player only fields are safe for storing things, although super_damage_finished does actually work on monsters apparently(this field is how long quad damage lasts). Confusingly enough, .count works fine on monsters, as it's only used for triggers.
Entity Fields
#3921 posted by Mike Woodham on 2005/07/17 14:34:30
What are the points against using new entity fields?
As a by-the-way Preach, 'style' is already in use via your teleporting monsters routine.
On The Origin Of Species
#3922 posted by Mike Woodham on 2005/07/19 10:52:56
Well, of models anyway.
Following-on from some previous postings, I still couldn't figure out the origin of the model and how to calculate the bounding box for the editor. In addition, I had noted the some models required to be off-set in the editor to appear correctly in-game, which I find quite annoying.
So, a couple of points have now just sunk in (it's his age doctor, his age), and being the kindly benefactor that I am (as long as money is not involved), I will share with... well, anyone else who couldn't figure it out (unless I am the only one. Mmmm, that would make me totally unique :-)
One, the model's origin is set by the model editor (I am using Qme).
Two, the origin is at 0,0,0 in the editor view
Three, beware (and this is why it took me so long to work it out) there is an Eye Position in the editor that can enable the model to be viewed off-origin but without altering the origin.
Four, the upper and lower box bounds shown in the Model Properties window are correctly shown relative to the origin, regardless of the Eye Position. This is vitally important when placing light sources.
So it boiled down to not realising that there was an Eye Position and that if one had been set, the origin was not as it appeared to be in the Frame Editor window.
All of this means that I can now place my models correctly. Phew!
Preach's Experiments Into Advanced Entity Hacking
#3923 posted by Preach on 2005/07/19 15:42:59
Now, the logic gate thing is very nice and all, it's very flexable and all, but it's a bit of a hack, and the fact that the projectile has to move a distance means you'll never get an instant reaction. So, if you want to know a way to do a simple trick - having a trigger that you can't touch until you fire another trigger to activate it - using the bare minimum of entities, read on.
The switchable trigger starts life as a info_notnull, that most versatile of quake entity. The whole thing hinges on making one that is not a point entity, but a brush entity(in fact, the brush should be the trigger you desire once it's switched on). There may be an easy way to do this if you mess with your config files for the editor, but I did it by hacking the entities with adquedit. The way to do that is to create a point entity info_notnull with the required properties, and a trigger_once with the required size. Then, use adquedit to extract the entities, and open the ents file in notepad.
Then find the trigger_once, and copy the "model" line. Paste said line over the origin for the info_notnull, replacing it completely. Then delete all the lines about the trigger_once, you don't need it.
So, what properties do you have to give the info_notnull? Basically these:
{
"model" "*2"
"touch" "multi_touch"
"use" "InitTrigger"
"target" "door1"
"targetname" "activatetrigger"
"wait" "3"
"classname" "info_notnull"
}
Quick explanations. The model is what we just hacked to make it a touchable thing. The touch is the same touch function as a trigger_multiple - but the info_notnull initially has no size, and so can't be touched, until you fire InitTrigger, in the use slot. The target and targetname are pretty obvious. Wait works the same as normal, set it to -1 to get a trigger_once.
You can also set noise directly here to the wav file you want to play. Bear in mind that it won't get precached by this entity, so you must make sure there's another entity in the map that uses and precaches this sound, even the regular trigger sounds. Most trigger_multiple stuff should just work, except targetting the trigger with another event. Since you have to target it with an event to make it a touchable trigger, targetting it again doesn't do anything.
One more thing to note is that this isn't a toggleable thing. It starts off, you can turn it on, and if you killtarget it you can turn it off again, but that's it. The only solution so far to a proper toggle would be a logic gate, but I'll work on it. There are lots of...interesting hacks you can do with an info_notnull, including a wall mounted ammo dispenser, (kinda reusable) gib fountains without telefrags, teleport flashes, and the classic explosion hack. Maybe I should put a page up about 'em or something.
#3924 posted by Kell on 2005/07/19 16:04:55
Maybe I should put a page up about 'em or something.
I think that would be a very good idea.
Explosion Help
Hello there :)
I'm currently building a map, and I'd like to implement explosions in it. They would be created by a missile launcher with a button, and when this button is pressed, an explosion (that always explose at the same place) happens. I use a func_explosive, but the problem is that, it only explose once and can't explose again even if I push the button again. That's pure logic, but I'd like it to create an explosion everytime I press the button. Is there a way to make reappears a destroyed block, or something else that would simply make an explosion everytime the button is pressed.
Oh and I have another problem. I use the target_earthquake function. It will imitate the explosion effect, but the problem is that it only happen once. It is activated by a button, I press it once, it works, but if I press it again, it doesn't work. Is there any ways to fix this?
Thanks a lot for your help!
Have a nice day
Trigger Trouble
Hello, I am having trouble with triggers in my map, what I want to do is have two trigger_once's and a trigger_teleport be useable as soon as the player grabs the gold key and not before that. What I've done is that I've put a trigger_once brush around the gold key, which has the target 'idiotkey', I've made a trigger_relay with the targetname 'idiotkey' and the target 'longwalk', and the two trigger_once and the trigger_teleport have the targetnames 'longwalk'. All of the trigger_once's fire at any time, even though 'idiotkey' hasn't been triggered, and the trigger_teleport never triggers.
Help, please?
Tested It
#3927 posted by bambuz on 2005/07/23 19:04:27
it seems the trigger_once (or you could put the target in the key directly too) is triggered on the moment you pick the key but not after that. So the teleport works only if you are inside the trigger_teleport brush at the same time you pick the key - i.e. the key is inside the teleport.
That is not what we intended.
How to "enable" or "disable" the trigger_teleport brush is the original main question here - if it's possible at all? Kind of an opposite to killtarget, like "enabletarget".
I Just Explained This...
#3928 posted by Preach on 2005/07/24 04:11:58
The reason the trigger_teleport doesn't trigger is because if you give a teleporter a target, it only teleports things that are in the trigger at the instant it is teleported. That's how you do teleports for monsters, the teleporter isn't permanently switched on, just for the next 0.2 seconds. That value is hard coded into quake.
But, rejoice, there is a way to do it. Read a few posts up(3923) to my bit on how to activate a trigger using a hack based on the info_notnull entity. Following that guide exactly tells you how to make the trigger_once that turn on, make sure to set the wait of the info_notnull to -1.
You can also use the same trick to turn an info_notnull into a teleporter. Follow the same method as before, but instead of setting the touch function of the info_notnull to multi_touch, set it to teleport_touch. You will also have to set the target of the info_notnull to the info_teleport_destination as you would for a normal trigger_teleport.
Oh, one last thing I realised just before I posted, the whole thing won't work, unless you set the teleport trigger's .nextthink to 9999999, basically as large as you can. Of course, in theory somebody could play the map longer than this time, but plenty of other things in the quake engine will break before this time, so don't worry : -).
While I'm posting, there's a slightly easier way to make brush entities with a classname of info_notnull. Just make a new brush entity in your map, make it a trigger_blah(ie. a type of trigger that doesn't exist). Then give it all the fields the info_notnull is meant to have. Finally use adquedit to extract the entity file, and just rename the trigger from trigger_blah to info_notnull. You still need to go through all the hassle of extracting, editing and replacing the entities, but it's less easy to screw up if you're just changing one classname.
CrAzYCoW: What mod are you using for these effects? I'm sure it's a fairly easy fix in the source code, but since I don't know which mod you're using, I can't look at the code. I had a look at doing it with a hack in normal quake, but all I can do is fire player rockets from an info_notnull. I'm guessing you have the rocket already as a brush model or similar?
An Old Problem Revisited
#3929 posted by Preach on 2005/07/24 04:38:21
Phait, you still need the levitating zombie, right? I got off my arse and completed something for a change, here's how you do it.
First, edit the zombie model. Duplicate the last scene, the crucified animation, and make it into a framegroup (right click and select 'Group frames for scene' in QMe). Then save the model.
Open plats.qc, and go to the very bottom. Duplicate the function misc_teleporttrain and rename the copy as misc_zombietrain. Delete the line that reads
self.avelocity = '100 200 300';
replace the lines
precache_model2 ("progs/teleport.mdl");
setmodel (self, "progs/teleport.mdl");
with
precache_model ("progs/zombie.mdl");
setmodel (self, "progs/zombie.mdl");
and finally add
self.frame = 198;
to the bottom of the function. And that's all, just set it up like you would a normal train. It really shouldn't have taken me this long to figure that one out. I'd copied the function for a func_train instead and was modifying that, for some reason the line
self.classname = "train";
causes Bad Things to happen if you use it for a zombietrain. So now it's fixed and works and I got another double-post in this thread.
Awesome
#3930 posted by . on 2005/07/24 04:58:02
I will see how it works, appreciate your help :)
Thanks Preach
#3931 posted by bambuz on 2005/07/24 05:42:35
but we decided yesternight to pursue the spikeshooter & door AND logic gate route for now...
Hmm
#3932 posted by bambuz on 2005/07/24 07:07:08
on another note, couldn't one do that enableable trigger inbuilt into quake.fgd so it works straight in worldcraft?
Probably...
#3933 posted by Preach on 2005/07/24 07:20:59
You probably could, I'm not organised enough to set that up first. The only problem with it is that there is already an info_notnull in the fgd, and it's a point entity, not a trigger. I'm not sure how well worldcraft would cope with two entities with the same name but different properties. You certainly wouldn't want to hardcode that function into the info_notnull, the best thing about them is that they can do all sorts of different things. Which reminds me, back to writing that up...
:)
#3934 posted by bambuz on 2005/07/24 07:24:54
yeah maybe one could differentiate if the other is a point entity and the other a brush, dunno, maybe i'll look into it some year...
Regarding The Entities, Preach
#3935 posted by czg on 2005/07/24 13:44:24
Thanks for the tip about this. I've used it now for a targeted trigger_changelevel by simply setting the .use key to trigger_changelevel, which works because trigger_changelevel() doesn't precache anything.
Worldcraft does NOT like it if you put a definition for both a solid and a point entity with the same classname in the fgd. You'll have to make two entries for it, one being solid and called info_notnull2 or something.
However if you're using aguirre's tools, you can automate the process a bit by setting up a batch file like this:
updateents.bat
@echo off
bspinfo -copyents %1
echo Please go ahead and edit %1.ent
pause
qbsp -onlyents %1.ent
@echo on
And then run it like updateents mymap, edit the generated .ent file in your text editor of choice and then go back to the bat file and "press any key to continue...".
If you've got the knowhow to do it you could probably have a commandline tool to do a regex search on the generated ent file automatically and replace all info_notnull2 with info_notnull. You know, something like grep or the likes.
Actually After Thinking About It For 10 Seconds More
#3936 posted by czg on 2005/07/24 13:47:40
It would perhaps be best if you didn't have any info_notnull entries at all in the fgd file.
WC will not complain if you type in your own classname in the entity properties, and then doesn't care if the entity is solid or not. The only drawback is you won't get the benefit of SmartEdit, but for info_notnulls there are so many different fields to be set on them depending on what you plan to use them for that using SmartEdit would just be a clutter.
The Grep-like Tool
#3937 posted by aguirRe on 2005/07/24 14:51:56
is often called sed (stream-edit) and for the simple entity name replacement, you don't even need regex (which can be a bit tricky to set up).
Preach.. Which Function?
#3938 posted by . on 2005/07/24 19:58:09
and finally add
self.frame = 198;
to the bottom of the function. And that's all...
Which function?
Nevermind
#3939 posted by . on 2005/07/24 20:20:46
I missed the bit about copying the function and renaming it, got it now.
Preach Again...
#3940 posted by . on 2005/07/24 20:30:32
Well, I looked over everything and I'm certain I did things right. You forgot to mention I need to work with the ZOMBIE.MDL by putting it in a progs directory.
So, in the map - the zombie is completely stationary and not in crucified pose. Yet he moans like he does when in that pose. Also, I triggered him and he didn't move to any path_corners I set. I even removed the trigger_once and walked up to him, but nothing happened either.
CrAzYCoW...
#3941 posted by distrans on 2005/07/24 22:14:37
...if you want a hack for multiple explosions using one button then tie sequentially named func_explosions (fe1, fe2 etc.) to trigger_counters with increasing count numbers but the same name.
OK...
#3942 posted by distrans on 2005/07/24 22:23:13
...that might've been a bit confusing.
Make the launch button target a series of trigger_counters named "missile", but give each trigger_counter a higher count value than the last. Now make each trigger_counter target a different func_explosion... to make things easy, get the trigger_counter with count 1 target the func_explosion with the name fe1, trigger_counter with count 2 targets the func_explosion with name fe2 etc.
Moaning
#3943 posted by Preach on 2005/07/25 02:25:38
The misc_zombietrain shouldn't moan at all, unless that's some bit of code you've added. There are no sounds that automatically play with certain animations, and the misc_zombietrain doesn't even precache them, so they'd only be loaded if you had other zombies in the level. Could you make a quick testmap with just a misc_zombietrain and a few path corners, and see if you get the same result?
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|