setorigin freezes the whole game.help
Moderator: InsideQC Admins
10 posts
• Page 1 of 1
setorigin freezes the whole game.help
Hello,
I have very strange problem with my qcc modification.
When I use setorigin function SOMETIMES the whole game freezes.
It's not important what my code does, I'm just interested if anybody
knows something about this problem.
What I'm doing wrong? Is there any trick, which I don't know?
Should be the qcc code be able to make the engine freeze (I mean hard freeze -
I have to kill game with SIGKILL on linux, or reboot computer in windows)
I use v101qc code, id's qcc compiler, original quake source with sdl video handler (also winquake was tested with same effect).
Thank you all for any followups.
I have very strange problem with my qcc modification.
When I use setorigin function SOMETIMES the whole game freezes.
It's not important what my code does, I'm just interested if anybody
knows something about this problem.
What I'm doing wrong? Is there any trick, which I don't know?
Should be the qcc code be able to make the engine freeze (I mean hard freeze -
I have to kill game with SIGKILL on linux, or reboot computer in windows)
I use v101qc code, id's qcc compiler, original quake source with sdl video handler (also winquake was tested with same effect).
Thank you all for any followups.
- robert_siska
- Posts: 4
- Joined: Mon Sep 01, 2008 12:07 pm
Yech. Don't use the id qcc compiler, use something better like FrikQCC or FTEQCC. Also, you should not be using v101qc when there's v106qc.
-

Dr. Shadowborg - InsideQC Staff
- Posts: 1110
- Joined: Sat Oct 16, 2004 3:34 pm
If I remember correctly, if you remove items in a touch function, you can trigger some nasty effects such as this.
I believe the same is possible with setorigin/setmodel in touch functions too, although I don't personally remember ever seeing this particular symptom I still believe its possible.
Inside touch functions, the engine walks a linked list of objects inside a node. By moving/removing entities around/from the world, you change this linked list as its being iterrated over, moving entities to the start or removing them entirely. This is the reason for the SUB_Remove function.
If possible, make the touch function trigger a touch function, and move it there.
I think setorigin is fine in touch functions so long as you don't move it more than once per 'other' in a single server frame (that is, you should make sure it will actually move).
I believe the same is possible with setorigin/setmodel in touch functions too, although I don't personally remember ever seeing this particular symptom I still believe its possible.
Inside touch functions, the engine walks a linked list of objects inside a node. By moving/removing entities around/from the world, you change this linked list as its being iterrated over, moving entities to the start or removing them entirely. This is the reason for the SUB_Remove function.
If possible, make the touch function trigger a touch function, and move it there.
I think setorigin is fine in touch functions so long as you don't move it more than once per 'other' in a single server frame (that is, you should make sure it will actually move).
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Here's the function, that causes problem.
When 'other' is player, it works everytime.
When 'other' is e.g. item_health, or some weapon it works too.
But when 'other' is e.g. shellbox, rockets, the game engine gets freeze.
It sounds crazy, but that is how it appears to work.
When e.g. shellbox touch the teleporter, the function does not even start. (Because even bprint commands on the top of function won't run)
I upgraded to v106qc and tried proqcc compiler, but with no effect.
If you think you could help me, I'll send you the complete working mod with sources. Just let me know vie email.
Please don't send me advices like 'use DarkPlaces'. I think it is qc source problem, although the very strange effect, that game freezes and not just falls into the quake-console.
THANK YOU. I'm really desperate.
Btw: this mod is called portal gun and appends handheld portal device into quake (Wikipedia: Portal Gun). I think it has future. If you'll help me, you'll be one of the authors!
Function:
When 'other' is player, it works everytime.
When 'other' is e.g. item_health, or some weapon it works too.
But when 'other' is e.g. shellbox, rockets, the game engine gets freeze.
It sounds crazy, but that is how it appears to work.
When e.g. shellbox touch the teleporter, the function does not even start. (Because even bprint commands on the top of function won't run)
I upgraded to v106qc and tried proqcc compiler, but with no effect.
If you think you could help me, I'll send you the complete working mod with sources. Just let me know vie email.
Please don't send me advices like 'use DarkPlaces'. I think it is qc source problem, although the very strange effect, that game freezes and not just falls into the quake-console.
THANK YOU. I'm really desperate.
Btw: this mod is called portal gun and appends handheld portal device into quake (Wikipedia: Portal Gun). I think it has future. If you'll help me, you'll be one of the authors!
Function:
- Code: Select all
void() TeleporterTouch = {
local float vel;
local vector org;
local vector oldvel;
bprint("touched by ");
bprint(other.classname);
bprint("\n");
if (self.frags>time) return;
if (target_exist==1) {
bprint("Let's beam ");
bprint(other.classname);
bprint("\n");
vel=vlen(other.velocity) + KICK;
oldvel = other.velocity;
other.velocity = '0 0 0';
org=target_clip_player(target_entity);
bprint("debug1\n");
setorigin(other,org);
self.frags = time + REFIRE;
target_entity.frags = time + REFIRE;
other.fixangle = 1;
other.velocity = vel * target_entity.punchangle * BUFFER;
if ((other.velocity_x == 0) && (other.velocity_y == 0)) {
other.velocity_x = oldvel_x / 2;
other.velocity_y = oldvel_y / 2;
}
other.angles_x = 0;
other.angles_y = vectoyaw(other.velocity);
other.angles_z = 0;
other.v_angle_z = 0;
other.flags = other.flags - other.flags & FL_ONGROUND;
}
};
- robert_siska
- Posts: 4
- Joined: Mon Sep 01, 2008 12:07 pm
The game freezing isn't due to your choice of qcc (worst case is a runaway loop error dumping you to the console). For a qcc to generate a progs so broken that it results in an infinite loop would be such a major bug of the qcc that it would be spotted and fixed fast.
Do you have the time and patience to add debug prints to the engine?
If you don't, then just change your bprints to dprints and set developer 1. This will mean your bprints are actually visible in the case of an infinite loop involving qc code. However its not guaranteed to be looping through qc code constantly.
If you can modify and compile the engine, go into world.c and find the function SV_TouchLinks.
There's a loop something like this:
for (l = node->trigger_edicts.next ; l != &node->trigger_edicts ; l = next)
Inside that loop, there's an touch==ent check.
Just before that check, can you add:
printf("touch: %s - %s\n", pr_strings+ent->v.classname, pr_strings+touch->v.classname);
And then run it in such a way that you actually see the stdout. Linux rules.
Oh, add a printf above the loop too, just print "checking touches\n" or something, and possibly add one after the loop too if you feel a need.
Anyway, I think the cause is that loop, combined with setorigin unlinking the entity and relinking it, leading to the entity appearing in the list twice (thus pointing back to itself eventually, perpetuating the loop).
Its probably due to the next = l->next; bit, but that's almost required to fix setorigin(self, blah) in touch functions (which is more common).
If you don't have the time and patience to compile your own engine based on the released source code, the FTE, DarkPlaces, and I think FuhQuake (to name a few) have this fixed.
I guess ultimatly the solution is to not call setorigin in touch functions (on anything other than self) if you want to be able to use unfixed engines.
And yes, I know teleporters teleport 'other' inside their touch function too. I guess they just teleport entities far enough... Or something.
You know... I have no idea. Just use gdb or something and break it when it freeze.
Do you have the time and patience to add debug prints to the engine?
If you don't, then just change your bprints to dprints and set developer 1. This will mean your bprints are actually visible in the case of an infinite loop involving qc code. However its not guaranteed to be looping through qc code constantly.
If you can modify and compile the engine, go into world.c and find the function SV_TouchLinks.
There's a loop something like this:
for (l = node->trigger_edicts.next ; l != &node->trigger_edicts ; l = next)
Inside that loop, there's an touch==ent check.
Just before that check, can you add:
printf("touch: %s - %s\n", pr_strings+ent->v.classname, pr_strings+touch->v.classname);
And then run it in such a way that you actually see the stdout. Linux rules.
Oh, add a printf above the loop too, just print "checking touches\n" or something, and possibly add one after the loop too if you feel a need.
Anyway, I think the cause is that loop, combined with setorigin unlinking the entity and relinking it, leading to the entity appearing in the list twice (thus pointing back to itself eventually, perpetuating the loop).
Its probably due to the next = l->next; bit, but that's almost required to fix setorigin(self, blah) in touch functions (which is more common).
If you don't have the time and patience to compile your own engine based on the released source code, the FTE, DarkPlaces, and I think FuhQuake (to name a few) have this fixed.
I guess ultimatly the solution is to not call setorigin in touch functions (on anything other than self) if you want to be able to use unfixed engines.
And yes, I know teleporters teleport 'other' inside their touch function too. I guess they just teleport entities far enough... Or something.
You know... I have no idea. Just use gdb or something and break it when it freeze.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Hello.
I use SDLquake from www.libsdl.org/projects/quake/ and I already modified sources, because net_* files are not working. So I can add debug messages into source, but I want my mod to be working on all engines! I think modifying engine is useless - I want my mod by compatibile.
Also, I think that qcc IS capable of teleporting entities, it's just badly written qcc code of mine.
I better like the idea of not using setorigin in touch functions, but I don't know how to do it differently. I tried to make SUB_Setorigin (I defined it in subs.qc - same as SUB_Remove), but with no effect.
Any ideas how to do it?
I'm not, for example, using the ent.teleport_time, because I don't know what is it for. And I never read about those linked lists, and how they work.
So, if you know any references, let me know, please.
Thank you! You ARE helping me!
I use SDLquake from www.libsdl.org/projects/quake/ and I already modified sources, because net_* files are not working. So I can add debug messages into source, but I want my mod to be working on all engines! I think modifying engine is useless - I want my mod by compatibile.
Also, I think that qcc IS capable of teleporting entities, it's just badly written qcc code of mine.
I better like the idea of not using setorigin in touch functions, but I don't know how to do it differently. I tried to make SUB_Setorigin (I defined it in subs.qc - same as SUB_Remove), but with no effect.
Any ideas how to do it?
I'm not, for example, using the ent.teleport_time, because I don't know what is it for. And I never read about those linked lists, and how they work.
So, if you know any references, let me know, please.
Thank you! You ARE helping me!
- robert_siska
- Posts: 4
- Joined: Mon Sep 01, 2008 12:07 pm
Looking at that code made my head hurt.
You could always do the trick items do i.e.:
oself = self;
self = other;
Do all the stuff you need to do, then switch back using:
self = oself;
Upon research into how the portal gun is supposed to work (based on descriptions) I'd classify this as a master grade task.
You could always do the trick items do i.e.:
oself = self;
self = other;
Do all the stuff you need to do, then switch back using:
self = oself;
Upon research into how the portal gun is supposed to work (based on descriptions) I'd classify this as a master grade task.
-

Dr. Shadowborg - InsideQC Staff
- Posts: 1110
- Joined: Sat Oct 16, 2004 3:34 pm
Instead of setorigin(other,org), I used:
where
- Code: Select all
other.origin = org;
other.nextthink1 = other.nextthink;
other.nextthink = time + 0.1;
other.think1 = other.think;
other.think = SUB_teleport;
where
- Code: Select all
void() SUB_teleport = {
setorigin(self,self.origin);
self.nextthink = self.nextthink1;
self.think = self.think1;
};
Last edited by robert_siska on Thu Sep 11, 2008 2:31 pm, edited 1 time in total.
- robert_siska
- Posts: 4
- Joined: Mon Sep 01, 2008 12:07 pm
robert_siska wrote:To: Dr. Shadowborg
Well, nobody is perfect, except you of course.
Hardly. I'm just saying that this isn't exactly the easiest task to undertake...
*shrugs*
Anyhow, hope you manage to get it working.
-

Dr. Shadowborg - InsideQC Staff
- Posts: 1110
- Joined: Sat Oct 16, 2004 3:34 pm
10 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
