mrwonko

Reminds me I have yet to finish MotS... As for DF2: uhm... I don't remember much. I remember an elevator that moved diagonally, probably on Nar Shaddaa, which I found interesting since a func_door in JK2/JKA can't move in that direction. The stuff you pay attention to as a mapper... DF1 on the other hand I remember more clearly, probably in parts thanks due to the mod that recreated the beginning.

Well I don't know much about rend2, but the shader indicates OpenGL 3.0 is enough, no need for 3.2. But yeah, it could be related to your mobile GPU not being up to the task or the drivers not supporting it.

The Mobility Radeon 4650 is supposedly capable of OpenGL 3.2 so as long as your driver supports it that should work. You can verify this e.g. using the GPU Caps Viewer. It displays your supported version in the OpenGL tab and lets you try various demos to further test it.

What GPU does that computer have? That shader seems to be OpenGL 3, which practically means you need a DirectX 10 GPU.

It's where OpenJK writes its files. From Vista onward Windows finally does proper access rights and keeps normal users from changing files in the Program Files folder, where you'd install Jedi Academy (that is, the Admin would). Anything the user wants to write should go to his user directory (though people can't seem to agree on where in there exactly), which is where fs_homepath points by default, because you can't write to the folder JKA is installed to.

Lightmaps are very low-res. If there's a shadow from a normal map on it it'll usually be pretty big. Q3Map2's normal maps are really not useful for much, even at lower lightmapscales. I don't know about rend2.

Did you look at the sourcecode? The names are defined in surfaceflags.h and the sounds are handled in a function called _PlayerFootStep().

That's entirely normal. The sky is practically infinitely far away so anything closer (i.e. everything else) will show up in front of it. It makes sense, too, and I prefer when level designers adjust their levels accordingly (i.e. show the outside of the buildings you could otherwise look into), but proper level layout and vis can take care of it as well. P.S.: No need to add your name to the thread title, it'll be displayed right next to it anyway.

But you didn't add that shader to skies.shader, or did you? I can't find that in my skies.shader.

Is the shader in your shaderlist? If Q3Map2 does not load it, it won't know that it should not create a lightmap, which could be the cause of that error.

Being able to use .ase implies it's done in Q3Map2. I briefly looked through the source code and it does seem to be so (see light_trace.c:1276). Did you know you can set a frame to display using _frame2?

From Q3Map2's source code, map.c:1745 to be specific: /* group entities are just for editor convenience, toss all brushes into worldspawn */ if ( funcGroup ) { MoveBrushesToWorld( mapEnt ); numEntities--; return qtrue; }As for other improvements: use info_null with the "light" spawnflag to define spotlight directions. They'll be stripped out when the map is loaded. Also, use scripts in lieu of complicated entity networks.

@@IrocJeff, your choice of font style is annoying. More on-topic: In general, this is what you want an areaportal to do: And here's how having two area portals inside a door sucks: While you're between two areaportals in the same door (i.e. inside a brush covered in the areaportal texture on all sides) the whole map gets rendered and all entities go invisible. Big no-no. Bad mapper.

Automatic splitting of UV seams is something a good importer should handle, just like triangulation and rotation in case of different coordinate systems. It's a pain to have to manually do that. I'm guilty of this myself, my Blender exporter has all kinds of requirements or it won't work, but that doesn't make it any more excusable...

I don't know about more efficient, but it's only necessary to have one side to define "this is an areaportal" so I don't see why you'd want multiple. In fact, I sometimes experience short vis bugs when walking through doors which I imagine may be connected to having 2 area portals in there, but I never verified that.

Sounds like it's way beyond what JA was meant to do... You could write a custom mod for it but I don't think what you want can realistically be done with scripts in base JA.

Oh I see. You're obviously not actually hitting a limit then, so it's probably some problem with Q3Map2. But if it works in Grand Flaw in JK2 there's got to be some way, presumably just not the one you used? Are you sure it's done using _celshader there?

Sorry, I missed the part about you already having the count, that's my most common problem with script executing only once. A similar question that used to pop up was respawning func_breakables. The workaround there was to use func_usable with health and turning it back on after a while, which would reset its health. I'm not sure if using always_on yields the same behavior wrt health. I could test it but I don't really have time right now.

Well until you post an example we'll never know...

That must be the script's fault.

You don't want to do this. What you should do is cover most of the brush in system/skip and have the system/areaportal texture only on one side that covers the doorway and is inside the door. Otherwise you're relying on the compiler to only create 1 areaportal, not 6. If you enable cheats in SP, or enable cheats and set developer 1 in MP, you can use r_showtris 1 to "see through walls" and see what's visible at any moment. There's also r_lockpvs - I don't know if that works in MP - which once enabled only renders what was rendered when you enabled it, so you can walk around and examine that. Also, if you run your -vis compile with -saveprt q3map2 will save the created portals to a mapname.prt file which the prtviewer plugin for radiant (which it ships with) can display.

Since cel shading is implementing by duplicating each surface (it's moved outwards a bit and flipped) it doubles their number. You'll thus hit engine limits earlier. The limit in question, that for drawn surfaces, seems to have been increased in Jedi Academy, which would explain why you only run into it in JK2. You'll have to drop some geometry to "fix" this.

Give the target_scriptrunner a count of -1.

Chances are the problem is in the entities somewhere. (I removed all the assets besides the map and it still didn't run.) Try removing all entities except for an info_player_start and see if that makes it run. If so, bisect the entities to find the culprit(s).

It's not a general problem like you phrase it, it's just a matter of what equation you use to calculate the curve based on the control points and the one used by Quake 3 makes circular shapes difficult. I guess it'd never come in handy. If Q3Map2 is even half-decent it'll just calculate the brush's position and then discard it so there should be no difference in the result between manually setting the origin and using an origin brush. So you can't even argue with brush count. (And if that is in fact a problem I'll go and fix it in Q3Map2 so it isn't.)