(...and no, this isn't an excuse to tell me to fuck off)

I'd contemplated re-writing the trigger system before, but I wasn't sure how best to do it. The way that makes most sense to me right now, is some sort of "message" system, that goes something like this:

"targetname" is what is being sent the message. The additional targetname entries (if present in the code) give it additional frequencies to be listening to.

"target" is what to send the message to. Again, the additional targets work like additional frequences to be broadcasting on.

And them there's an (as yet) unnamed 3rd field, which is the message to be sent. This could be something like a traditional use/activate signal, a kill signal, a change texture signal (so you can have brush entities that are doing something more useful than just being func_walls change their appearance), or maybe even something else.

This is made more interesting, of course, by being able to send a different signal to each target. Yes, this is still similar to how we have .target and .killtarget now (and yes, this would allow both to be done at the same time, as is the case in Quoth, RMQ, and other mods), but it would be more flexible than that.

The only part I'm not sure on, is if this signal should be a float or a string. And then, of course, you have to define what all of the signals mean for each object. Obviously, there would be a few common ones, but some would need additional things specified. 

yeah, that's an ok system. it's good because it's unified and probably easy to understand from a programming point of view.

i imagine the 'message' could be a simple bit mask where you can select what you want to change to the triggered object. so a single trigger could change, for example, both the func_door texture AND open it or whatever.

but it's just easier to code up helper or script entities instead and more intuitive in an editor (not to mention there's no support for an 'entity message' in any editors). 

mm, my mind apparently skipped a beat and i didn't actually explain myself on that third paragraph. o.0

i say it's easier, but it's also more flexible.
i have script entities that can change an entity's owner, change specific 'target' strings, toggle flags/spawnflags on entities.

toggling a func_walls texture is simple, but how would you put 'change targetname2 on this entity to xxxxx' in a simple one string/integer message. you'd end up with other helpers anyway. 

What is the code that lights the sigil's place marker on the player's GUI as each sigil is collected?

Are the lights just made in order or do the shapes relate to the actual sigil?

I do not get any lights when I use them (and collect them)in my levels - what gives? 

an engine coder could tell you for certain, but in the qc, picking up runes sets a global variable 'serverflags' with bits 1, 2, 4 and 8, corresponding to the appropriate episode.
the runes only work if the UI is set to the default one. hipnotic and rogue game modes turn on their respective UIs which don't check the runes. so if your mod uses one of those UIs or you're using quoth which uses hipnotic UI, then the runes don't show up. 

Yes, if I use standard progs.dat (1.06) then the UI lights up. I am not using a mod but I am using an 'enhanced' progs.dat.

However, I have checked the sigil_touch section in items.qc and it exactly the same as the 1.06 version. I cannot find any other differences related to 'serverflags'.

Strange. Must be something, but I don't know what. 

THIS CODE IS PURE EVIL.

YOU MIGHT FIND IT USEFUL.

BUT DON'T GET FUNNY IDEAS.

So...I was working on the winner of the straw poll, which is the navigation entity stuff. Idea 3 did attract some attention so I might put up an article about naming in QC which would contain the "clever ideas" part of the event system I had in mind, so someone else with time on their hands would be free to do the footwork implementing it. Most of the effort would be in creating useful input and output on the various func_ entities, but at least it's a chance to exercise some creativity.

Anyway, I was trying to create some beautiful code involving callback functions (been reading too much ajax stuff recently) and managed to confuse the compiler enough for it to mistake a string field for a float. As you may or may not know string fields in QC are integer offsets into a big block of strings. So I came up with the following:

float INT_1 = 0.0000000000000000000000000000000000000000000014013;
.string tempstring;

void(.float stringfield) increment_string =
{
��float increment, stringvalue;
��increment = INT_1;
��if(self.stringfield < 0)
����increment = increment * -1;
��stringvalue = self.stringfield;
��do
��{
����stringvalue = stringvalue + increment;
����increment = increment * 2;
��}
��while(stringvalue == self.stringfield);
��
��self.stringfield = stringvalue;
}

void(void(.string floatfield) dispatch, .string fieldtype) strip_fieldtype =
{
��dispatch(fieldtype);
}


//then put the following code somewhere
{
��self.tempstring = self.model;
��while(self.tempstring != "")
��{
����strip_fieldtype (increment_string, tempstring);
����dprint(self.tempstring);
����dprint("\n");
����if(self.tempstring == ".bsp")
����{
������dprint("It's a bsp file!\n");
������break;
����}
��}
}

It's so hacky I don't even want to talk about why it works. 

In time maybe I'll see this as undoing a great blessing but: a correction:

float INT_1 = 0.00000 0000000000000000000 00000000000000 00000014013; but without the spaces. 

increment = INT_1 o.0

mike: i was referring to the command switch you use when launching quake, not the progs. the progs can't change the UI itself, unfortunately. if you put hipnotic progs in the id1 folder, you'll get hipnotic entities, but the UI will be default quake. 

on pathfinding...

if you're gonna implement a brand new system... should just go whole hog and do a star and just let the mapper plop down some nodes. that'd be insanely badass...

i'd totally do it, but i'm too dumb. ^_^ 

I am not sure I understand. No, I am sure I don't understand.

I have two .bat files:

fitzquake085.exe -window -heapsize 40960 +gl_clear 1 -width 1024 -bpp 32

fitzquake085.exe -window -heapsize 40960 +gl_clear 1 -width 1024 -bpp 32 -game mynewprogs +skill 2 +map This_FMB_1_8c

The first runs the iD1 folder and this has no qconsole file and the same config file as the mynewprogs folder. The mynewprogs folder does not have a qconsole file either.

As far as I can see the only difference in the two folders is the progs.dat. Yet the first bat file game shows the runes lights as you pick them up but the other bat file game doesn't.

It does not actually affect the gameplay but as you need all four runes to create a certain effect, it would be useful for the player to able to see what he has already picked up instead of having to remember.

Any hints as to what could cause mynewprogs to apply different UI settings? 

So do you have .float items2 defined somewhere in your code? If it is defined anywhere then the serverflags info is not sent to the client - to save bandwidth that info is replaced by the items2 info instead. 

Funny you should say that. Yes, I do have .float items2 as I have the drole and vermis from Quoth.

//quoth -- items
.float items2; // bit flags for new items -- ran out of room on items...

I am not sure why they ran out room; perhaps I'll experiment with changing it to 'items' and see what breaks. 

As 32, 64, 128, and 256. If you're using .items2 for your own nefarious purposes, then leave those four bits for the runes. 

sigil_touch() will need to be adjusted for this to work. The line

serverflags = serverflags | (self.spawnflags & 15);


should be followed by

other.items2 = other.items2 | ((self.spawnflags & 15) * 32);

This won't send the update to all players, but that's only relevant in coop. Also, impulse 13 won't update the hud properly, but a similar line will work in the function that handles it. 

thanks fakepreach and lardarse for clearing that up! i had no idea .items2 had any bearing on serverflags!

mike, since you're only using the drole, you could do a quick find/replace and just change 'items2' to something like 'drolevar'.
that way you can just leave the old serverflags variable alone. 

As I am not using any Quoth items, I can do away with the code relating to items2 without any detriment. It's just a couple of If/Then statements which don't apply anyway.

Onwards and upwards... 

don't forget to tone down the drole damage a lot. ^_^; 

"Do you expect me to talk?"

"No, Mr Bond. I expect you to die!" 

so, going in the opposite direction, it's possible to make monsters with smaller bbox sizes, however you need to offset them by whatever amount smaller than 6 that you used.

now that you're down frowning in perplexity at that terrible sentence, this is what i mean:
say you made a skinny monster, '-6 -6 -24' to '6 6 40'
you need to setorigin(self, '-10 -10 0') the monster or, if you place it close to walls, it will get stuck (even though, when you turn r_showbboxes on, the bbox clearly is not in any wall).

but other than that, it seems to work fine, really lets monsters bunch up. would have worked good for the voreling had i known about it back then. 

not only was that sentence awful, but there's a typo too.

by whatever amount smaller than 16 that you used.  

I did this with Floyd, didn't do the setorigin trick but instead made the in-editor box full shambler size so there's no risk of placing it in a wall. 

I'm still perplexed in making the Doomguy crouch.
Didn't want to start it over afraid of being a fool.

But the trick me was told to lower the bouncingbox so bullits would fly over it, and then raise the model again.
I don't understand. Then it would sink in the ground, but raising it would raise the bouncing box too? 

i'm not sure if we've covered this but when do touch functions get run when monsters are involved via movetogoal/walkmove?

are they run at the moment movetogoal is called?

ie:

void() someTouchFunction =
{
other.happy = 0
}

void() ai_run =
{
self.happy = 1
movetogoal(1)
if (self.happy)
cheer
}

so in this retarded example, while the ai_run function will make the monster happy, it will run a touch function right after movetogoal so that the if statement will fail?

i've been observing some screwed up behaviour and i'm trying to track it down... 

Yeah, the touch functions are respected there - only pitfall to bear in mind is that if the move fails because the monster is blocked, then they don't move at all and so the monster doesn't touch.

So that doesn't really help you track down your problem, and it sounds like you've got a pretty solid minimal test there. So I'm just gonna take a peek at somet-
OH MY!

Oh dear.

Very long standing bug in quake coming right up...

PF_walkmove, the non-navigational monster moving code, has the following code in it, which I remember noting down for possible use with that JS quake engine idea

// save program state, because SV_movestep may call other progs
oldf = pr_xfunction;
oldself = pr_global_struct->self;

G_FLOAT(OFS_RETURN) = SV_movestep(ent, move, true);

// restore program state
pr_xfunction = oldf;
pr_global_struct->self = oldself;


Firstly a quick note, "PF" in front of a function in the quake source means that it's a "progs function" - a light wrapper around some C code called as a QC builtin. The snippit I quoted then calls SV_movestep - the real heavyweight movement function which other parts of the engine also use.

Around that call we have some clearly documented code which stores the current QC execution state and restores it after the call. This firstly tells us that touch functions are a possibility they have programmed for, and secondly eliminates a possible source of the buggy behaviour - that after calling the touch control never returns to the QC.

Except your QC doesn't use walkmove, it uses movetogoal. I went looking for PF_movetogoal and was surprised to find it missing. It turns out that the QC builtin in this case directly calls SV_movetogoal instead, and I'm sure some of you are ahead of the puchline here - it doesn't save the QC state.

I haven't gone away to do follow up QC tests, but worst case I can imagine is that none of the remaining QC in your function ever gets run if a touch function is encountered, and best case is that it's just self that gets obliterated. In the former case you are basically stuck with using walkmove instead. In the latter you can put the traditional

local entity oself;
oself = self;
movetogoal(1)
self = oself;

But yeah, genuine nasty bug there I think. Let me know whether it is that worst case scenario situation or what, I'd like to know...