Give the path_corner you want it to stop at a wait value of -1 (unlike most entities of this kind, not all negative numbers will suffice, -1 is the only value which will work). Then retrigger the func_train with it's original targetname. 

Ok, I'm a little further along with my func_rotate_train testmap, for now I'm just slightly separating the waypoints in space so the bug I described is not an issue. I've run into the problem you describe, that things rotate the "long way round".

Now, I don't think that this is a bug as such. The entity should not be required to take the shortest rotation, because sometimes the long way might be the desirable path, and there's no need to require multiple path_rotates for that. What you need to do is add/subtract 360 degrees to the offending target angle.

As an example, you might have three path_corners with angles:
'90 0 0'
'180 0 0'
'270 0 0'
and you want to make the fourth
'0 0 0' to get it facing the way it began. But if you do that then it will turn the long way round. So then you try
'360 0 0'
and it works.

Until you try to make it a loop, rather than a single motion. Then you run into the same problem between the '360 0 0' and the '90 0 0' path_corner. This is a bit more of a problem, but I have devised a way to make it work...

download http://www.btinternet.com/~chapterhonour/hiprot1.map

The essential trick of the map is that from rampath4-rampath6 the rotation is not controlled by the "angles" key, but instead by the "rotate" key, which sets a rotation rate. It does this at the corner where usually the rotation would reach the 360 degree mark. The "rotate" key handles this point more elegantly than the "angles" method does.

Spawnflag 32 is used so that "speed" specifies a 0.1 second travetime rather than 0.1 unit speed travel. This is combined with setting rotate to '0 200 0', to ensure 20 degrees are rotated on each of those segments, enough to put the rotation back into the positive quadrant. If you look closely this actually constitutes a speed-up on that corner, further tweaking of the values could control that. 

thanks for your reply, Preach!
I've been working on the custents and it seems there's a way to get rid of this strange counter clock effekt.
For sofar the doombird turns wrong the first time, everthen it just goes right?!

I'm not familiar with this strange outcome, but it seems a practical way of going.

http://members.home.nl/gimli/dmbird.7z

Drew - take a look at the map, it might be the first part you're looking for. (without the re-ignition of the button) 

my maptester had such a long startpoint betatesting it overgrew its "whatever" length... 

sorry, i will... 

don't try! I already recompiled the map, because it was such a perfect mess,
it killed my real vis time on 5 days.

It had no hurry, so don't worry.
Better to serve you a perfekt map! 

Ok, I'm gonna go back on some of the stuff I posted last time about the func_rotate_train. It turns out there's a function in the hipsubs.qc file which does normalise the angles of the rotation. I think the problem is that 360 is an edge case which is treated badly. The function looks like

while( ang_x > 360 )
{
ang_x = ang_x - 360;
}
while( ang_x < 0 )
{
ang_x = ang_x + 360;
}
...

This function is meant to make it so that the multivalued angles are all mapped to a single value. However, '0 0 0' and '0 360 0' both represent the same angle, but are also both left unchanged by the function. Making the function look like:

while( ang_x >= 360 )
{
ang_x = ang_x - 360;
}
while( ang_x < 0 )
{
ang_x = ang_x + 360;
}
...

will make it so that each angle has a single representation. Now the simple setup of 4 path_rotates with:
'0 90 0'
'0 180 0'
'0 270 0'
'0 360 0'
will work as you'd imagine.

The way I think the func_rotate_train works is this: while the train is rotating, no normalisation of angles occurs and so the train will rotate in full from the angle it starts at to the one specified. Once the train arrives, the angles on the train(but not the path_rotate) are then normalised to between 0 and 360.

So, as a quick challenge, what happens if you set the angles on the path_rotates to:
'0 450 0'
'0 540 0'
'0 630 0'
'0 720 0'
once the bug is fixed? How about before the bug is fixed? 

guy i�m getting this error and crash joequake when i go to certan zone!

============================================
Host_Error: SOLID_BSP with a non-bsp model
============================================

any idear?

fuck :\ so close to finish this bastard and now show up errors like this :( 

Looks to be.

Probably removed a door or something but it left behind an invisible point entity holding the door's info.

Your editor hopefully has a method built in to find it, else not you can trawl through the map file to try and find it with notepad++ though that'll be a frustrating way to find it. 

Tools -> check for errors;

scroll down to the error "entity with no brush info" or whatever;

click it, click "go to error" (and the x/y view will pan to the center of the map)

close the dialogue then finally Press DELETE.

:) 

thks guys
was a func_plat :\ i had with no brush becouse i delete all the underground seccion that was made :\

might be in this week scrap speedmap event :) 

hey guys...

anyone have a clue as to how to set up GTKR 1.5 for Quake 1 mapping? I'm having problems getting it to set up textures and pointfiles.

damn this was so much easier years ago with qED... :(

thx. 

Put the wad files in your id1 folder. Make sure that GTKR knows where your Quake folder is. Make sure that the pointfile actually exists, and is in the same folder as the map file. 

Is there an info_notnull hack or suchlike to allow "statue" type effects, using a single frame of animation from a monster/player model?

i.e. I could have the body of a creature in a map? 

n/t 

The traditional way to do it is to create a point entity with:

"classname" "func_illusionary"
"model" "progs/ogre.mdl"
"frame" "23"


You need to make sure that this entity is lower down the list of entities than at least one monster_ogre entity, otherwise the model will not be precached, and you'll get an error. 

Thanks Preach!

So if I wanted to put a player model in I would use player.mdl (or whatever it is) and the precaching thing wouldn't matter because player is always edict no. 1? 

In actual fact, the player model is precached even earlier, as soon as the world spawns. And I seem to remember that even if the qc doesn't precache it, the engine requires the model to be there...So yeah, the player model is nice and safe. 

thanks, Lardarse. 

Hah, and I wrote a bunch of QuakeC to support corpses for "White Room". Damn it! 

It's always best to make proper classes for those kinds of things, you don't have to worry about the entity list order, and it's a bit easier to manage the map when things have suggestive classnames.

I've got a light tool question of my own now. I was under the impression that if you gave any entity a "light" key with non-zero value and a "targetname" of some sort, then everything with that targetname would get a switchable lightstyle. However, I've just given this a go with a custom class of entity and the lights are given style 0, which is a bit problematic when you come to toggle them. I can manually set the style to something else on the entity, and things work, but if I set that to 32, and 32 gets allocated elsewhere I'm in trouble.

So my main question is how light.exe decides what is a switchable lightstyle when it comes to custom entities, and if there's a way to deal with this. Any offers? 

"It's always best to make proper classes for those kinds of things, you don't have to worry about the entity list order, and it's a bit easier to manage the map when things have suggestive classnames. "

Well, the way I did it was to add a new spawn flag called "SF_CORPSE" (or something like that). Anything monster with that flag set would spawn in, assume a random death pose and go into a dead state so it didn't take up processor time.

It worked well enough and was definitely manageable. I can see your point about the separate classes though. 

Are definitely underused in Quake - the main problem being model precaches. Corpses aren't a problem because they'll be cached anyway since its almost a given that there's a living version in the map. 

Further to my post about the switchable lights, I've managed to narrow the problem down to occuring with aguirre's light.exe but not arghlite.exe.

When I give these entities a classname of "light" then they behave as regular switching lights, and are given their own lightstyle. Once I change the classname to "light_tubelight", arghlite treats them no differently, which is what I expect. But aguirre's light stops giving them a unique lightstyle, which causes them to turn off all the lights in the level when they get triggered.

It seems like it's filtering entities by classname before deciding whether the entity in question needs a unique lightstyle. So has anybody run into this, and is there a way to disable this with a command line switch or something? 

Are there any decent front end compilers for Quake similar to Eddi's GUI or Nem's Batch compiler for HL?