Ramikad

Giving it a second thought, there's another possibility on Yoda's last sentence of the last Jedi: Kanan dies and then Ezra abandons the Force.

For what it's worth, that particular grass texture has a phong shader on it.

What kind of surfaces, out of curiosity?

It can actually be done in a much easier way, by making them actual lightsabers and setting g_saberPickuppableDroppedSaber to 1. Why deal with the inside part too when you can just set a cull none or cull twosided in the shader?

Actually I hope this too; after all, Yoda says in Episode VI: "[...] when gone am I, the last of the Jedi, will you be." And it's interesting considering that Yoda knows about Kanan and Ezra...

Jedi Knight: Jedi Betrayal is (or rather was, at this point) a fan-made sequel to the Dark Side ending of Jedi Academy. http://www.moddb.com/mods/jedi-knight-jedi-betrayal1 http://jkhub.org/wiki/index.php/Jedi_Betrayal

I believe that as long as the map name stays the same and the structure isn't changed, as it seems from those screens, it's fully compatible.

As far as I remember MAX_TW_VERTS occur when your brushwork is too complex. Turning part of the geometry into models helps. Also, what is _blocksize supposed to do, anyway? Pande suggested me blocksize 0 (without that _ before it), but I never quite understood it.

I think the last scene leaves little doubt about what happened: http://img2.wikia.nocookie.net/__cb20060118180141/starwars/images/e/ee/Spirits_copy1.jpg I doubt Vader survived.

I second that. I had the chance to read through the plot written for JKB, and I liked it.

My eyes are transmitting rainbows to my brain.

Followed by head_a1|torso_g1|lower_d1 (or anything else in their place) if it supports this kind of customization.

Just drag the link in a new window. It works. http://s16.postimg.org/61q5an0d0/projectx.jpg

I just made a quick test, and overall it seems that it actually works pretty well as a hub: I tried going back after opening a door or killing a stormtrooper, and they remained there. And every time I spawned on the correctly targeted info_player_start entity.

I can't wait to see the Sulon Star in all its glory... From the refueling system, of course

It doesn't? As far as I know JA supports sort of "hub" levels; target_level_change has option "hub": HUB - Will save the current map's status and load the next map with any saved status it may have and coped with this key value: "target" - Name of spawnpoint to start at in the new map It seems to support these kind of hubs. Haven't looked through the code though, so I may be wrong.

Or you could reuse a protocol (or actually, ANY NPC model) to place it somewhere appropriate, make it almost completely invisible (either with *off parts in the .skin or through transparent shaders), and only make the "mouth" somewhere; two skins of it, one static (for when it's silent) and one animated (when it speaks), that you can simply switch through script when speaking. Just an idea

I agree. And that ignition sound screams "UNSTABLE!" to me

In singleplayer, Force Pull has this description: Rank 1 - The Jedi can pull certain levers and objects in the targeting reticle; can also pull one enemy. Rank 2 - The Jedi can pull the weapon out of the hands of an enemy, providing the enemy is facing them. Rank 3 - The Jedi can pull multiple enemies and their weapons. Pfft, newbie... still stuck at Force Pull 2

Looks great! But don't forget Stage 2... http://www.therpf.com/f11/screen-accurate-millennium-falcon-cockpit-cg-model-102451/index16.html Just joking about Stage 2 ofc

Not sure about you, but in my tests those type of models come out with very strange lighting on them. Sometimes they display correctly, sometimes they're completely dark, sometimes they're completely lit, often at the same time... and most importantly they don't draw any "concrete" shadow on the map, which is inevitably going to look weird if the area is not properly lit or without the "hi-res shadow trick". Unless, of course, the lighting problems are caused by too many polygons.

I just tested it, both without and with "Affect Player", and doesn't seem to work. At first look, the script seems ok. It's possible that SET_ORIGIN is very selective about tagging an entity; the easiest way IMO is to manually set the destination coordinates and angles. As for the angles, you want to only set the Z value (the third one), to avoid having the player stuck in very weird positions.

Except that I don't see the reason why it should be a MD3 and why it should have LODs. misc_model_static and the other misc_model_xxx entities capable of supporting LODs, in my experience, don't really deal well with lighting and shadows.

Pande said it right... Model is the way to go. If you turn it into an ASE, you can set a "Number of subdivisions" low enough to remove that error automatically. Be wary though, the quality is going to increase in terms of vertex and poly count.