Does anyone know if entities such as func_trains work in Portal Sky boxes?

One of my greatest desires for JK editing is to have animated skyboxes and the thought of a Star Destroyer cruising overhead is something I think would be EXTREMELY cool.

Has anyone tried this? Does it work?

No-one interested?

This could revolutionise the way maps are made you know!

Whoever can answer this would get a credit in every map made using this technique! Think of the fame, the glory, the women you'd get! :)

You could have a scripted battle going on in the background, you could see ships taking off and landing miles away in the distance, you could make Coruscant come alive (instead of those sh*tty scrolling car bitmaps that raven use).

Think of the possibilities!

The reason I don't try this myself it that I don't get very much fun time on my PC and so if I spend hours getting something to work and it doesn't, I consider it wasted, so if any of you ubermappers out there want to try this and it works, then drop a note in this thread. Cheers

If you get hold of a star destroyer model, surely you could just get it placed just below your sky, shove it on a func_train (or other similar idea) and then use a script to make it "cruise"?

[edit] This post assumes the existence of a star destroyer model, lol.

I just made a test map with a regular func train (no model) and it worked fine. So yes, you can put moving objects in the sky portal.

It will work with models as well because models targetted towards an entity get baked into the BSP so they'll work like they're a set of brushes.

Yeah, I tried it last night with a wedge shaped brush (representing my star destroyer). Portal skies are possibly the greatest creation for the quake3 engine. I've made a couple of city based maps and have had to model all the buildings in the city to scale. Compile times were not good.

With these skies, a 2 hour compile takes about 5 minutes.

Awesome.

These skies can be reused as well - just move the _skyportal entity to a different place to get a (slightly) different skybox!

Coruscant here I come!

1 more question though: my wedge shaped train works fine in the skybox until I add a "speed" key to it - it then won't show up at all. Any ideas? Should it be "_speed"?

I set speed to 25 the first time I tried it and it worked straight away...

On the func_train itself or the path_corners?

I'll have to have a fiddle with it - the speed at which my Star Destroyer moves over head would create hell of a lot of air displacement that would flatten my city:)

Also, what method would you recommend to create traffic:

Would you have each individual model use an origin brush or would you group a load in a line and have them share the origin?

I'm just concerned that my traffic would look ridiculous when turning for a path_corner.

If I were to use the 1st method (each model individual) is there a way I can set the wait value per train rather than setting it at the path_corners? I don't all my traffic merging into one big blob:)

Now I know I wasn't completely stupid I can ask what's the difference between a normal sky (i.e. texturing one side of a brush with a sky texture) and a portal sky?

Portal skies are awesome, normal skyboxes aren't! that's the main difference.

What a portal sky basically is is a a box made of 6 brushes covered on the inside with the sky texture and on the outside with caulk. This box will be outside the normal confines of your map. In this box you put a misc_portalsky entity.

No the good bit. In this box you can put models, brushes, func_trains:) etc and all these will displayed as part of the sky in your map, hence the original question for the thread.

I think there is a tutorial by Raven on www.map-review.com) - go check it out!

I set it on the func_train and left the path_corners alone.

BTW how about using a func_static and scripting them? Then you can make things move smoothly.

As for traffic, I'd be careful if I were you, the one downside to skyportals is they have a lag effect (god knows why...but they do) so don't put too many moving things in them.

I'm not planning on using it in multiplayer so it doesn't matter too much about lag.

I've only just got into scripting so I wouldn't feel too confident about setting up a load of moving traffic. I'll have a look for some tutorials on it though.

My scripting abilities at the moment are limited to making npc's play certain animations, so at the moment i've got this cool reception with massive windows overlooking my gloriously blocky city with the npc's standing around chatting.

I'm, going to have to learn how to script func_statics anyway so I can have shuttles taking off and landing, TIE flyby's etc.

I'll try and get some screenshots up once it's nearly finshed.

Don't get too carried away all your great ideas are gonna cost ya. The skyportal has a price on performance right off the bat and if you're doing a city with wide open spaces and lots of NPCs and stuff to draw it's gonna hurt. Test out what you want to do first and see if you get a decent frame rate before you try to implement all your ideas and your final design.

Smooth movement by a func_static and scripting isn't in the end very easy to do. You must script separately every move to a new place. So, if you want to have smooth movement, it means a lot of scripting. Func_trains might often provide a better compromise, because placing a huge amount of linked path_corners is no problem after all.

Except you're going overkill with the entity county to create corners and I don't think the entity turns yet does it? So you end up with a train facing the wrong direction.

It's actually really simple to use script. I actually made a test map to demonstrate this to someone as they wanted a map with a subway

affect("trams",FLUSH)
{
rotate(<0 -90 0>,6000);
move($tag("point1",ORIGIN)$,0);

move($tag("point2",ORIGIN)$,2000);
wait(2000);
move($tag("point3",ORIGIN)$,2000);
wait(2000);
move($tag("point4",ORIGIN)$,2000);
}

That script required 4 ref_tags at 33 degree intervals (or there abouts) to make a 4 point 90 degree segment (I just did it by eye, nothing more). That script will then move the tram from point1 to point 4 over a period of 6 seconds rotating the train as it goes through 90 degrees. The result is a train that appears to go around a bend very smoothly and looks superb.

I even added flashing lights at one point to make it look even more 'real'

Granted. Just remember to set the linear 1 key/value...

Yeah, there might be some problems involved with func_trains (man, I don't know why I am suddenly speaking for them... I only began using them so recently anyway...).

Originally posted by WadeV1589
Except you're going overkill with the entity county to create corners and I don't think the entity turns yet does it? So you end up with a train facing the wrong direction.


I'm just using 1 or 2 brushes per item of traffic with the texture making it look more complex. The path corner entities have a "turn train" flag, and as long as you orient the train facing "east" in the editor from the top down view, it goes around with no problems.

Also, is there anyway to have more that 1 train per "track" eg, have one starting at "point01", another at "point02" etc?

I'm still looking into this scripting business at the moment so perhaps i'll give that a go as well.

One more thing - a complete noob question - how do you bind a model to a func_static?

I get an error message in JKA relating to the fact that it isn't a brush. Should I create a brush anyway? And would the game remove this and replace it with the model?

To link one to start at point one and one to start at point two, do just that, ctrl+k one to one corner and bind another object to a second corner.

As for model to a func_static, select the model first, then the func_static and ctrl-k them. The model will stay where it is relative to the func_static as it moves.

Do you know when something sounds so simple you think it can't possibly work and so don't try it?

You've probably guessed the reason I had to ask:)

You can also use the model2 key to get a model to show in game when using a func_static or a func_train entity.