Ramikad

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.

Best possible thing would be trying to continue JKB with a new team tbh

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.

If you're using multiplayer its /model instead of playermodel

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

5. So replay maps?  The problem is the engine doesn't keep persistent map data after you switch levels, but I'm sure you could easily store this info to a text file and then retrieve it when loading the map and stick it into the map/change maps cfg based on data.  This would take a bit more work though.

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 think they screwed up having his lightsaber made from some tool-like staple gun. It doesn't look two-hand friendly at all. I don't like it.

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.

I know Darth Vader pulls the blaster away from Han Solo while he's firing at him

Pfft, newbie... still stuck at Force Pull 2

Just started today (Lando's Lady Luck ) :

 

http://wrzucaj.net/zu7

http://wrzucaj.net/zu8

http://wrzucaj.net/zuF

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

I don't see why they would mess up with lighting & shadows unless the LODs aren't done very well. Could be some game bug, who knows.

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.

The transition happened, but it didn't save my progress in terms of health, weaponry or other items - quite the contrary, I evolved into a Jedi master and got a lightsaber each time a level transition occured

Just tick keep_prev on info_player_start.

What you've heard is correct. Simply adding a _1, _2, ... to each higher LOD (as the numbers increase, the detail decreases). Note that this doesn't work if you use the model as a misc_model, it has to be misc_model_static or misc_model_breakable

Precisely. Out of curiosity, do you know why it only works with these kind of models, and not with plain old misc_model?

it work with script_targetname or targetname with icarus, not with trigger o.o

Huh? Every single time I did this in the past I used func_usable entities, which would work pretty much the same as trigger_xxx entities.

Anyway, it's strange that it doesn't work. If you did everything correctly it should work just fine.

Edit: Just tested it, and lights are triggered by both func_usable and trigger_multiple.

You mean turning lights off and on? If that's the case, you can simply "use" the light entity, in the game or through scripts.

Not completely sure, but I resolved this making the prisoner ignore enemies (SET_IGNOREENEMIES TRUE). I put both strings after SET_ANIM_HOLDTIME_BOTH -1.

Nice stuff! Do you know any more details about what they were planning for the Alderaan mission?

SET_NOTARGET will do just fine. It works on everything, NPC and Player.