Something to do while I wait for ONE demo.

I had an idea that's similar to all the stuff I've been doing recently. I'm not sure how possible it is in QL, but in Q3 it would be pretty easy. I'll run from map to map. It would be amazing if I got it to work properly, but I don't think it will work out.

To describe the idea more clearly: I will be doing a short strafe run on, say ctf4 (because the space maps are the easiest), then rocketjump "into the void", and land on the next map (might me dm18). So this is actually quite a bit more complicated than my last project, which is now on hold. But it's also more doable by me, because I don't need to wait for someone else to send me a demo; I can do it myself.

There are quite a few complications I can think of right off the bat.

First, the obvious one: It will be a huge pain in the ass to move smoothly from map to map. I have a few ideas, but they all have their own problems, and I don't know how reliable each one is.

The first way is to use some sort of savepos command to save my origin and velocity, then change x/y/z when I switch maps. Once again, this would be easy in Q3, but not possible in QL, because all QL has is setviewpos, which only allows x/y/z/y/p/r, without v0,v1,v2, like Q3's placeplayer. It automatically sets my velocity to 400 in the direction I'm facing, just like a teleporter. So that isn't really viable.

My second option is to somehow run on my own custom, flat .bsp, and make sure that my jumps line up with the other maps. I could add some brushes for the major structural pieces (or in some cases, make holes, like on ALL THE MAPS because they're space maps). Then it's simple; I make a single camera path that goes through the "fake" map. I capture JUST the player model and any rockets/etc. that I use, because I expect to use at least some rocketjumps to go from map to map. Then I offset the camera so that all the maps fit beside eachother fine. This seems like it would require decimal-point precision in the camera placement, which means a LOT of testing, and tons of work that I don't really want to do, and is very unnecessary, because there's another step that would also have to be done, which is only slightly less monotonous: I would have to fix the leaf nodes that are stored inside the demo.

Q3MAP2 does this thing where, when compiling a .bsp, it generates little (or large) leafs all over the map. I don't know the specifics, but while inside one of these leafs, only what's inside it can be rendered. Everything outside is completely ignored; it isn't drawn, and it isn't rendered. It helps a lot with rendering efficiency, and probably with compression. I don't really know much about this, because I only took a quick look at hinting in Radiant, and that's all I did to look into the more advanced map stuff. The whole reason I brought this up is because these leafs are saved inside the demo, and the whole world disappears when you leave them. It's quite a predicament, and only matters when you try using bsps that don't belong (playing a demo on a map that it wasn't recorded on). Fixing this is a big problem, and yet another one I'd rather ignore.

The third (and final, as far as I know) way to fix this whole problem of running in-between maps, is to decompile all of the .bsps that I will be using, line them up, compile them, do my run, make the camera using this custom bsp, then offset it for each individual bsp, record only the player + related entities on my custom bsp, then each individual map, and then the sky in my own skybox bsp. This is really the least complicated way to go about this. It has quite a few more major steps than the first two solutions, but each one is a lot less time consuming, a lot more reasonable, and a lot easier.

The custom bsp will be a piece of shit with no lights, tons of misaligned textures, and broken entities/brushes. Decompiling is an imperfect technique, and can never be perfected. The reason being, the light entities themselves are ignored, while the lightmap is saved to the bsp. I don't know how unreasonable it would be to approximate the color, intensity, and position of the lights based on the lightmaps, but it seems like even a very inaccurate approximation would be better than nothing. So it would be stupid for me to use this bsp for anything else, is what I'm getting at.


I pretty much described every annoyance that I've thought might appear in this. There are some things, like chroma keying, that I'm horrible at, but that isn't even significant compared to the other problems I face with this.

The things I do keep getting more and more complicated, and I love it! It's so fun to play around with the game in this way. I don't just get a demo and upload it to youtube anymore. I actually do things now, and this I'm very happy about. I'll start working on this on Saturday, then on Monday, because I'm going to a convention on Sunday. My other trans-map air-rocket project has a higher priority than this one, though, so if someone sends me a demo while I'm in the middle of this, I'm saving my work and moving over to the other one. Unless I'm in the middle of rendering it or something.

That's all for now. I have a thing for writing about what I'm thinking, so these really stretch on for quite a bit.