mrwonko

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?

If this is for some movie or the like, maybe a simple SET_ADDLHANDBOLT_MODEL script would do the trick? I've never actually tried using it, but I guess that set ( /*@SET_TYPES*/ "SET_ADDLHANDBOLT_MODEL", "models/weapons2/briar_pistol/briar_pistol_w" ); could yield the desired result.

We had an idea in IRC: Why not remake Hoth Wasteland CTF? That has the benefit of giving us a clear guideline and the result being usable in a free Jedi Academy asset replacement set. Personally, I'd be down. I'd still like to have some gruesome pulsing flesh some day, but until then a Hoth remake is fine. Very high-poly, preferably, so it could showcase dynamic lighting well. As I said, I have a DropBox account now and could just set up a shared folder. I just need to friend you on DropBox.

So it would be a matter of creating a new BSP version?

Sounds like you should look into revision control.

The code would surely benefit from some refactoring and doing that in C++ wouldn't hurt either, but it's just such a massive task that I don't know if anybody is going to do it. (And finish.) I'd like a nicer version of the code myself and I do like C++, but I'm not sure that even with my love for Jedi Academy I'd be able to do this. I may try though, but that won't be a part of OpenJK, it'd be my own project. If done properly it could hardly be done without breaking compatibility with existing mods though.

Scripting.

It's a Q3Map2 feature, not a JKA one. It's for manually editing lightmaps and then using -import to put them back in, as far as I know. No, it's just for manual editing besides scaling, as far as I can tell. Although I agree that an arbitrary lightmap size limit is no good. On the other hand, lightmaps already make up a major part of the level size, I'm not sure they need to be increased any further - realtime lighting would be better suited for the cases where you want crisp shadows.

I hadn't noticed that yet... It should be impossible. Maybe some trickery with using a different texture below it? Usually this sort of effect (refraction) requires a fragment shader, and JKA hardly supports them. (Except for the force push effect and the cloak in SP. And the shield? Something like that. Surely hardcoded, anyway.)

Maybe you could upload the model in its current state so we can take a look?