mrwonko

That's wrong. There are no limits to what you can do, it's just a loooot of work. Well, and in the case of Euphoria it'd also be a matter of getting its SDK, which is apparently nigh impossible, so maybe that's why you got a definite "No", but there are no boundaries imposed by the code itself, since you can change all of it, there are just boundaries outside the code, like your skill, time, available libraries etc. You added them yourself? So that's obviously possible then, I don't see why OpenJK has to do it for you. That's very much a gameplay change and thus outside the scope of OpenJK. If you want newbies to have an easier time modifying OpenJK, you should ask for/write tutorials on how to add new buttons etc., not clutter OpenJK's codebase with unused code.

nar_shadaa, eh? That's JK2 stuff, might just not be included in Jedi Academy. You can search the JK2 assets for the textures and include them with your mod though.

In general the download-free maps are done by editing the entity chunk in the bsp. Take a look at Q3Map2's -onlyents

You can't.

well, it's not entirely dead yet. It'd be a shame for all the files they host, but other than that I'm not too attached to it. Darth-Arth.de on the other hand... That's what really got me into modding. Shame it died.

I wrote a Blender plugin that can import glm models, keeping weights intact. The models can be re-exported and will work as before. If you move tags you might have to reweight those, but nothing else. Keep in mind to do it across all LODs. https://jkhub.org/files/file/1413-blender-264-jedi-academy-plugin-suite/

You'll probably want a lightmap. q3map_nolightmap prevents generating one during compilation and lack of a map $lightmap stage prevents using one. Shaders are very close to the hardware - you basically need to learn a lot about how graphics cards work in order to be able to properly write them: Blending, depth tests, what purpose alpha sorting has (note that the Quake 3 engine does not alpha sort). I've only recently started to fully understand them, and I've been mapping for over 10 years.

To quote myself on the matter: Lazy bum.

That's irrelevant since it's a Q3Map2 problem. Anyway, maybe the thinness is not the problem then. I just remember very flat brushes (relative to their size) causing problems, but maybe not yours.

When you use large brushes, make sure you don't make them too thin. Radiant doesn't preview things quite like they look ingame. Case in point: moving or blinking textures like Lava. So it may just be a problem with the trees. Which ones are that?

Okay, I've taken a 100MB of Screenshots of the Echo Base in Episode 5, that should do nicely. Take a look. One thing I noticed: The movie features neither elevators nor stairs. ctf2 has both. Still, a good reference. SO how closely will we stick to the original layout? I suppose the heights should match closely enough that anything accessible via level 2/3 force jump should still be in the remake?

Because you don't collide with them. Whenever you want to move brushes/models but scripting each move/rotate manually using ICARUS is just not feasible (say for baked rigid body physics) ROFF is your friend. It's also the only way to do a relative move, i.e. you specify an offset, not a destination. Another thing besides moving brushes you can do with ROFF is animating camera paths. Again, this can also be done manually using icarus, but it's a major PITA compared to simply using some proper 3d modelling/animation package.

So, Hoth then? Keeping the original layout but improving visuals? Some specific planning may be advisable - looking what we need (e.g. an X-wing), gathering references and so on. I'll get started on that after uni unless anybody has objections to Hoth...

You, sir, need parallax occlusion mapping.

Could you elaborate some more about what your result is supposed to look like? Having an overlay is the simplest way of achieving this, but depending on how this is to be used (e.g. a grate?), depthFunc equal could work as well.

Playing an effect could be done using animevents.cfg. In that case, the fx_runner could play a dummy-effect and really only be there to cause damage.

I doubt that. I can imagine it breaking if it changes the leaf, which often happens to be behind a wall though. To verify this is the problem, try going to where the effect originally is, do r_lockpvs 1, then move to where it is supposed to play. Actually, I'll experiment some more myself. EDIT @@Szico VII: Okay, confirmed it. Moving an effect does not update it in the effect system - it is not played until its original leaf is in the PVS. Workaround: Do no VIS compile. http://www.youtube.com/watch?v=y0i_0zEdFOo

Glad to help, but how does this concern you?

NPC_Targetname is not necessary, it's just so I can see the script executing entity's name. Should've removed that. Regarding the deathscript: Ever wonder why NPCs use NPC_Targetname instead of Script_Targetname? They have a script_targetname, too, but that is for the spawner. I suppose the script names get copied to the NPC when they are spawned and only those copied values get changed by the script. As for having multiple at once: I haven't investigated how exactly Icarus works, but I suppose it doesn't suspend a script mid-execution unless there's a wait so the scripts should run serial. The affect could mean trouble though, I don't know if it's guaranteed to start as soon as that command is issued or if it's just sent to a queue. Worst thing that could happen: All the dying NPC's effects go to one of them, or to an undefined position. (Triple Zero?) The pelvis thing is weird, but not unusual. The code seems to make a lot of assumptions about that kind of thing.

Vector is the type of variable - a 3 dimensional (mathematical) vector, used to represent positions in 3D space (x, y and z coordinate). It's how an entity's origin is stored. As to how the script works, that's the deathscript of your NPC. It queries the NPC's position and stores that in a new global variable of the name tmp with the type (3D-)Vector that is created first (via declare). There's a limit of like 16 global variables so you want to keep their usage down, which is why it is removed (using free) once we're done using it. If you want to get data from one entity to another, you'll have to do it via global variable because all the other things you can set/get are relative to the script-executing entity. Anyway, I've tried actually building an example map and found that using move(); on an fx_runner in MP breaks it. So I tried set(SET_ORIGIN);, and what can I say? http://youtu.be/E_CckT-9ckY Works like a charme. I've had to use an extra relay so the fx_runner executing the script does not use itself - Jedi Academy prints a warning to the console if that happens since it's prone to causing infinite loops - and reset the deathscript because apparently dying once causes it to be executed multiple times (wtf?). So this is what the final script looks like: //Generated by BehavEd declare ( /*@DECLARE_TYPE*/ VECTOR, "tmp" ); set ( /*@SET_TYPES*/ "SET_DEATHSCRIPT", "" ); set ( "tmp", $get( VECTOR, "SET_ORIGIN")$ ); affect ( "dat_cool_fx_runner_script", /*@AFFECT_TYPE*/ FLUSH ) { set ( /*@SET_TYPES*/ "SET_ORIGIN", $get( VECTOR, "tmp")$ ); free ( "tmp" ); use ( "dat_cool_fx_runner_relay" ); } Here's the map I used for testing:

As to why this happens: It means your lightmaps need a lot of memory to be generated. More than 2GB at once. 32 bit programs can't handle more than 2GB, usually, and never more than 4GB. Probably caused by having a lot of huge terrain, if this looks anything like the Utapau I'm thinking of.

Origin tag as in so? move ($tag( "npc_targetname", ORIGIN)$, 0.000 ); What about this then? $get( VECTOR, "SET_ORIGIN")$ You'd need a global variable (via declare, don't forget the free later) to be able to get that origin over to the other entity, does this work? //(BHVD) declare ( /*@DECLARE_TYPE*/ VECTOR, "tmp" ); set ( "tmp", $get( VECTOR, "SET_ORIGIN")$ ); affect ( "dat_cool_fx_runner", /*@AFFECT_TYPE*/ FLUSH ) { move ( $get( VECTOR, "tmp")$, 0.000 ); free ( "tmp" ); rem ( "maybe wait() here?" ); use ( "dat_cool_fx_runner" ); }

Is the shader in the shaderlist?

Did that one door close while you were still standing in front of it? If you're using trigger_multiple to trigger your doors, do use target2 + toggle.

You're aware that standalone will likely get you a cease & desist?