Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Tutorial: Rotating Brush Models for QuakeWorld Goto page Previous 1, 2, 3, 4, 5, 6 Next

| Inside3d Forums Forum Index -> Programming Tutorials

View previous topic :: View next topic
Author | Message
--- | ---
avirox Joined: 16 Aug 2006 Posts: 109 |

Posted: Sun Jan 03, 2010 2:59 pm Post subject: |

Just utilize SUB_CalcAngleMove() tbh. I don't know why id left it in the QC code since it's really not of much use without rotating brush support (except maybe on regular models).

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Sun Jan 03, 2010 11:08 pm Post subject: |

avirox: I have no idea how to use SUB_CalcAngleMove. I just want a func_rotating which I can put in my map, and which makes a bmodel spin, hopefully in DP and FTE and later, other engines, too. I'm a mapper ffs. The idea is to avoid the hipnotic crap. I don't want rotating lifts made from 144 entities anymore, please. Let's kill func_movewall.
Any idea why this

Code:
void() func_rotating = { self.solid = SOLID_BSP; self.movetype = MOVETYPE_PUSH; setorigin (self, self.origin);
setmodel (self, self.model);
self.classname = "func_rotating";
setsize (self, self.mins, self.maxs);
if (!self.speed)
self.speed = 100;
if (self.spawnflags & 2) // reverse direction
self.speed = 0 - self.speed;
if (self.spawnflags & 64) // not solid
self.solid = SOLID_NOT;
if (self.spawnflags & 4)
{
self.avelocity_z = self.speed;
self.avelocity_x = 0;
self.avelocity_y = 0;
}
else if (self.spawnflags & 8)
{
self.avelocity_z = 0;
self.avelocity_x = self.speed;
self.avelocity_y = 0;
}
else
{
self.avelocity_z = 0;
self.avelocity_x = 0;
self.avelocity_y = self.speed;
}
self.think = SUB_Null;
self.nextthink = self.ltime + 9999999;
};

works in Darkplaces, but not in FTE?
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Mon Jan 04, 2010 12:27 am Post subject: |

in DP it looks like its checking for avelocity

Code:
rotated = VectorLength2(pusher->fields.server->angles) + VectorLength2(pusher->fields.server->avelocity) > 0; ... if (rotated) { vec3_t org2;
VectorSubtract (check->fields.server->origin, pusher->fields.server->origin, org);
org2[0] = DotProduct (org, forward);
org2[1] = DotProduct (org, left);
org2[2] = DotProduct (org, up);
VectorSubtract (org2, org, move);
VectorAdd (move, move1, move);
}

in fte the ent must have both avelocity and velocity set.

Code:
if (!pusher->v->velocity[0] && !pusher->v->velocity[1] && !pusher->v->velocity[2] && !pusher->v->avelocity[0] && !pusher->v->avelocity[1] && !pusher->v->avelocity[2]) { pusher->v->ltime += movetime; return;
}

Back to top |

avirox Joined: 16 Aug 2006 Posts: 109 |

Posted: Mon Jan 04, 2010 12:55 am Post subject: |

I have entities in QuakeLife which do either one or the other and work just fine in FTE. I'd have to look at your map and code to debug this. Also, how recent is your build of FTE?

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Jan 04, 2010 1:09 am Post subject: |

r00k wrote:
in fte the ent must have both avelocity and velocity set.

The code you pasted is a short cut if both velocity and avelocity are clear, in which case its not moving and the ltime can progress normally without any movement. There is no bug in the code that you pasted.
_________________
What's a signature?

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Mon Jan 04, 2010 1:27 am Post subject: |

Urre, hipnotic rotate_object testmap: http://www.quaketastic.com/upload/files/single_player/maps/hiprot1.zip xavior: a very recent nightly or svn, I forget. Urre: hipnotic testmap with ONLY rotate_object and info_rotate http://www.quaketastic.com/upload/files/single_player/maps/hiprot_2.zip
Urre: same with rotate_object not near 0 0 0 and info_rotate in the center of it (compiled with treeqbsp Linux)
http://www.quaketastic.com/upload/files/single_player/maps/hiprot_3.zip
Urre: same compiled with hmap2
http://www.quaketastic.com/upload/files/single_player/maps/hiprot_4.zip
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Wed Jan 13, 2010 4:07 am Post subject: |

goldenboy: any chance you could do a couple of more test cases? Namely, another compiler which is not hmap2 and treeqbsp perhaps preferrably good ol' hipqbsp which featured rotatings originally, as well as a test case using treeqbsp where the rotate_object is a func_wall instead?
LH bughunted a bit for me, and came to the conclusion that hiprot_3 has a broken bsp tree (why? We don't know, possibly due to broken rotating support?), and hiprot_4 does not crash but does not feature a solid rotating brush, which LH suspects is due to the compiler. He saw nothing wrong with the .map file, so that shouldn't be it.
_________________
Look out for Twigboy

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Wed Jan 13, 2010 12:23 pm Post subject: |

Urre wrote:
goldenboy: any chance you could do a couple of more test cases? Namely, another compiler which is not hmap2 and treeqbsp perhaps preferrably good ol' hipqbsp which featured rotatings originally, as well as a test case using treeqbsp where the rotate_object is a func_wall instead?
LH bughunted a bit for me, and came to the conclusion that hiprot_3 has a broken bsp tree (why? We don't know, possibly due to broken rotating support?), and hiprot_4 does not crash but does not feature a solid rotating brush, which LH suspects is due to the compiler. He saw nothing wrong with the .map file, so that shouldn't be it.

Fixed hmap2, it now builds the map perfectly, posted new version on the DP news, but here's a direct link: http://icculus.org/twilight/darkplaces/files/hmap2build20100113.zip
Of course I do not know if it loads in any other engine, but I hope so!

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Thu Jan 14, 2010 6:46 am Post subject: |

Thanks! This is awesome news! Care to share what you did, so other compiler devs can fix their compilers? _________________ Look out for Twigboy

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Thu Jan 14, 2010 7:18 am Post subject: |

Urre wrote:
Thanks! This is awesome news! Care to share what you did, so other compiler devs can fix their compilers?

due to the different structure of hmap2 I doubt it existed in other compilers.
But here's the bug explanation: the function ExpandBrush (used when building collision hulls for player and shambler sizes) needs world coordinates on the brush_mins and brush_maxs variables, but CreateFacesFromBrush was producing local coordinates for these variables because it was applying the origin offset in this function, this produced bad planes being added that clipped away the brush to nothing, producing no clip nodes for the brush, and hence crashes/bad behavior on the submodel affected.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Thu Jan 14, 2010 7:33 am Post subject: |

Some form of bug must exist in the other compilers as well, seeing as they don't consistently produce collideable brushes either. curig2.bsp from Prydon Gate has rotateable doors for example, but collision on them in DP is unreliable. Only the first door can be collided with, in the sense that it stops rotating when it hits you, but I can walk through it, but the rest don't even stop rotating as they hit me. Judging from you being able to successfully compile gb's test map with a fix in your compiler, I'd have to say it's a problem in all existing compilers. Considering hipnotic never meant for the brushes to be compileable in the engine, they might not have bothered to make sure the compiler does this either.
Someone should try convincing compiler devs to fix their compilers
_________________
Look out for Twigboy

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 14, 2010 10:16 pm Post subject: |

So there is finally a q1 map compiler that supports origin brushes?

DarkPlaces news page wrote:
http://icculus.org/twilight/darkplaces/ New hmap2 (q1bsp compiler) release with the following changes: Fixed rotating door compilation, it was generating corrupt hull data for player and shambler collisions, now works perfectly. (To see this in action in your own q1 maps, try making a "func_wall" entity and setting the "origin" key to the center of rotation you want, then set "nextthink" "999999999" and "avelocity" "0 90 0" to see it spin 90 degrees per second on yaw and push you around)

Sounds great!
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Fri Jan 15, 2010 12:20 am Post subject: |

Baker wrote:
So there is finally a q1 map compiler that supports origin brushes?

Nope.
You must understand that the origin brush is not the magic we're after. The feature has always existed in Quake map compilers, ever since hipqbsp was released, just collision seems to be broken. The origin feature was already there. Origin brushes mean nothing.
LH's tool seems to support specifying an origin manually for the entity, which is cool, but the old way of doing it was having a rotate_object as the door or whatever you wanted to have, then make it target an entity to get the origin. The targeted entity can be anything, info_null is a good one, as it gets removed on load, since it's not needed after compiling the map.
_________________
Look out for Twigboy

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Fri Jan 15, 2010 10:56 am Post subject: |

By the way, sorry for acting like an ass about this on IRC earlier, goldenboy and avirox _________________ Look out for Twigboy

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Fri Jan 15, 2010 11:51 am Post subject: |

Urre, even though I understand that origin brushes are not strictly needed since you can use a point entity in their place, origin brushes are still good to have because level designers are used to them. I don't see the problem with supporting them, really. Yes, I have understood now that they are not necessary. You have demonstrated that. I consider them user friendly though because they're the standard way to create rotating brushes for modern games.
Don't shoot me, please. I believe I have a point.
edit: To make myself clear, I think the question if you get the origin from a point entity, or from an origin brush, is entirely academic.
Origin brushes are just the established way to do it since Half-Life.
edit 2: We will need to fix treeqbsp / txqbsp so it properly compiles these things, too. Map compiler standard?
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Programming Tutorials | All times are GMT Goto page Previous 1, 2, 3, 4, 5, 6 Next
Page 2 of 6

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group