InsideQC Forums

Posted: **Sun Jan 03, 2010 2:59 pm**

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).

Posted: **Sun Jan 03, 2010 11:08 pm**

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: Select all

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?

Posted: **Mon Jan 04, 2010 12:27 am**

in DP it looks like its checking for avelocity

Code: Select all


	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: Select all


	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;
	}

Posted: **Mon Jan 04, 2010 12:55 am**

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?

Posted: **Mon Jan 04, 2010 1:09 am**

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.

Posted: **Mon Jan 04, 2010 1:27 am**

Urre, hipnotic rotate_object testmap:

http://www.quaketastic.com/upload/files ... iprot1.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 ... prot_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 ... prot_3.zip

Urre: same compiled with hmap2

http://www.quaketastic.com/upload/files ... prot_4.zip

Posted: **Wed Jan 13, 2010 4:07 am**

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.

Posted: **Wed Jan 13, 2010 12:23 pm**

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/ ... 100113.zip

Of course I do not know if it loads in any other engine, but I hope so!

Posted: **Thu Jan 14, 2010 6:46 am**

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

Posted: **Thu Jan 14, 2010 7:18 am**

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.

Posted: **Thu Jan 14, 2010 7:33 am**

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

Posted: **Thu Jan 14, 2010 10:16 pm**

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!

Posted: **Fri Jan 15, 2010 12:20 am**

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.

Posted: **Fri Jan 15, 2010 10:56 am**

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

Posted: **Fri Jan 15, 2010 11:51 am**

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?

InsideQC Forums

Tutorial: Rotating Brush Models for QuakeWorld