mrwonko

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.)

It should just be a matter of moving the bespin cop's model.glm and model_default.skin into kyle's folder in models/players, I believe.

Wrong, there are even two representations: -0 and +0. Bruce Dawson has a nice series of blog posts on floating point numbers.

The whole point of having the origin texture is for defining origins. If it were a matter of order you could just use nodraw. But you can't, because that's what origin is there for. I would very much like to get a step-by-step reproduction or a video for the problem you're having... The only problem related to selection I'm aware of is with copying - if you clone an entity, pressing N will edit the original's properties, not those of the selected copy. Anyway, as for wobblyness, that may be due to patches being hard to make perfectly round due to math.

Maybe you confused blocksize and gridsize... The former is for vis, the latter for the light grid. What had you set it to?

No. You can only hard code different times for different states, i.e. save the current location and execute different moves depending on that.

I thought it was just a matter of using a water shader (such as the ones in common)? There may be more effects in SP than in MP.

Besides your current troubles, keep in mind that you can only have one portal in view at any time. If you have multiple (e.g. 6) only one will be displayed.

To what end? Planning to redistribute your map via floppy disk?

Q3Map2 can handle misc_model with either of those formats, as well as .ase (and possibly more?).

Surely Maya can export lwo, obj or 3ds? Those all work.