Pande

Lol, no it wouldn't.. that would require massive code changes and portaling. This is just a cinematic transfer from one region to another thru some sort of pass like a winding canyon.

Largest map size x 8 over lapping, but it did break the game if you used even a x4 lightmapscale so it was confirmed not possible. 2 or 3 layers was fine though. For anyone interested, I used corresponding _Cs and _Rs values for each layer, allowing the sun light to pass through to the other layers. With teleportation, this would make for a very large playable area. The idea in JKG is to have certain exit points from the desert, where upon entering you would then be asked in dialogue if you want to continue and warned about dangers and how much water you have on you. When you say yes, a cinematic occurs to cover up the silent teleporting of your player, and you appear in the new zone.

Yeah, that's just an iframe, really super easy to implement. You just generate some code from kiwiirc.com and place it on any page.

Not really dickish, they are actually required by law to pursue copyright infringements and if they are seen to be not doing so then they can stand to lose their ownership of the content.

Have fun with that

Yep, the shader command is surfaceparm nosteps

Seriously? ...

The person hosting it had to let it go for financial reasons, and it was dying out anyway. We moved to a new site but it died quickly as sites often do after a move. You can keep an eye on my own tutorial site here if you'd like, I'm going to try to make an effort to put more tutorials up than the 2-3 that are there. But the ones that are there are great tutorials none-the-less. http://www.map-academy.shipheadstudios.frihost.org I got the site looking like I wanted it from the ground up, but then slowed down when it came to actual content, lol.

I thought you meant you were roleplaying on Szico's map

No -lomem but there is -fast, which should never ever be used for a final compile (unlike -fast for light).

Few things: theres no -lomem switch for vis eez, thats for lighting. I think what you are refering to is the hilarious bugs I got with the game when the lightmap data was too big (because I was covering 1/2 the X Y grid x 16 layers with lightmap on about 80k brushes). Lmao that was a funny sight... never again.

Just to chime in here, that >2gb q3map2 is a HUGE improvement if you can use it. One of my JKG maps used to take 18 hours on an old laptop. On my new one, it took just 8 hours and I thought that's the best i'd ever get. Now it takes 20-30 minutes with this q3map2. That's a 1600% speed increase.

That's exactly how it works. I think all the user has to do is exec nightvision in their console and it does the rest for them, tho it's been a while since I used that mod. could be more or less work. Anyway, when it comes time to release, let me know, send me a pk3, and i'll see what I can do.

Check out the nightvision mod, shouldnt be too hard to find. The screen moving stuff was fixed, again probably with a cvar change. Many cvars were changed when you pressed N, and then changed back when you pressed it again. (as I said, done through a vstr) As for scale, perhaps he used tcMod scale in its shader or something.

Why not replace the crosshair graphic instead, the way the nightvision mod does? My main concern is now people won't be able to use this with cg_hudfiles 2 or w/e it is (the basic 'just numbers' hud). Also your painted crosshair and the one in the game aren't lining up. By the way, couple the above replacement of crosshair graphic with cg_dynamicCrosshair 0 (I think? correct if wrong) which stops that shifting of crosshair over NPCs. All of this can be bound to a vstr or a looping bind, if you need help with either of those let me know.

AOD and EW for mb2. JAWA and EK for base.

You don't need to worry about leaks, leaks are for -vis. You shouldn't even be compiling -vis for a .ase. o.0 The bottom line is: it need's at least one structural brush in order to set up the BSP tree. No entities are needed. Then q3map2 takes the .map, turns it into a .bsp, then takes the surface data and turns that into a .ase.

In addition to this, make at least one brush structural (or just make them all structural with invert selection, w/e). A caulkhull isn't necessary.

Oxford comma after Tatooine please, 'Tatooine and Hutta' is not a singular entity.

By based on keystrokes, I mean the end-goal of learning Blender's interface is to be able to hide it all and do everything using the mouse. And it excels, really really really well at that. That said, the windows or menus which you are not using keystrokes to access are easily and very customizably layed out. It also has a super-fast search (press space, type any part of a function) so for example, instead of going to the context menu which contains remove doubles, since the keyword 'remove' is so seldom used, I just press space then type remove d (this is still faster than moving the mouse) and press enter or click. Anyway, topic derailing, sorry.

Press numpad 5, voila depth. It's default is actually the depth / 3d perspective, but what you saw in whatever form of media or trying it or whatever was Orthographic perspective, which I actually prefer because it's more mathematically accurate while designing scale. edit: interface? terrible? It's all a matter of preference. I used Gmax first and got used to it, I guess. Then I moved to blender and instantly fell in love with the super fast keystroke based UI.

http://politefiction.bandcamp.com/

^ ^ Because blender is the way forward. kekekekekek /me runs.