mrwonko

I'm not sure about the exact limits, but in general:
There's a limit on the total number of entities, which I think is 2048, and that includes shots fired during gameplay etc. misc_model is turned into static geometry during compilation; if there's a limit, it's pretty high and probably depends on the number of different materials per model as well. There might be an NPC limit, if there is, it's probably somewhere in the hundreds, maybe 256 or 512. I don't know if spawned NPCs also count towards the entity limit, or if only their spawners do. Lights are only used during compilation to create the lightmap and basically unlimited. Effects could be limited in some way as well, possibly both in total and in the number of simultaneously visible ones.

A target_scriptrunner will by default only execute once and needs a count of -1 to be re-usable. You also need to set the runonactivator flag or the script will run on the target_scriptrunner instead of the player.

Yeah, if you're using the Blender MD3 exporter from my plugin suite, that skips non-triangular faces and prints a message about them to the console. So if there are no triangles in the mesh, it will actually export an empty md3, which md3view can't handle (and which isn't of much use anyway). The exporter pretty bad at failing in a noticeable way and could use some work... And the ASE exporter isn't much better, either - it just silently drops any vertices beyond the first 3 from each face.
 
Since you're talking about backups, you may want to use a version control system like Git for that.

Is that a newly created map on Radiant 1.4? There's a save bug in 1.4 from Vista onwards, either change the save dialog to the GTK version in the preferences, in which case you'll have to manually add .map to the filenames, or preferrably upgrade to 1.6.

You saved them as progressive jpegs. Those are not supported. Check the image save settings.

See Texture tilation when running and testing a custom map.

the target_teleport is not the destination, you still have to target the target_teleport to a target_position or similar.
 
Or, if you don't need to toggle the teleporter, use a trigger_teleport and leave out the target_teleport.

Assuming you are talking about multiplayer, as is implied by the death message:
 

/*QUAKED trigger_hurt (.5 .5 .5) ? START_OFF CAN_TARGET SILENT NO_PROTECTION SLOW Any entity that touches this will be hurt. It does dmg points of damage each server frame Targeting the trigger will toggle its on / off state. CAN_TARGET if you target it, it will toggle on and off SILENT supresses playing the sound SLOW changes the damage rate to once per second NO_PROTECTION *nothing* stops the damage "team" team (1 or 2) to allow hurting (if none then hurt anyone) only applicable for siege "dmg" default 5 (whole numbers only) If dmg is set to -1 this brush will use the fade-kill method */In particular: 
Just read the entity description.

Yes.  

Well, the format itself imposes no limit, but JA will refuse to load anything with more than the aforementioned 1k verts.

Animate in some external Tool like Blender, export as ROFF, play using
camera ( /*@CAMERA_COMMANDS*/ PATH, "my/roff/file" );

Your map's size is too damn high. It needs too much memory to compile the light stage. -lomem is one thing that may help, or if you have a 64 bit operating system you can try a 64 bit Q3Map2 build which can handle more than 2GB ram. Also, maybe don't do -super 2, that's 2x super-sampling, which calculates every lightmap at twice the height and twice the width for 4x the memory usage.
 
The downside of lomem is increased compile time. Maybe try -fast or -faster for faster compiles at the cost of decreased quality.

It's necessary, called t-junctions. There's a Q3Map2 switch, -notjunc or some such, to disable it, but that can lead to visual anomalies. The reason are rounding errors in interpolating the edges, leading to 1-pixel-wide gaps between trianges, like so.

Swap the last two stages.

That's entirely normal. The sky is practically infinitely far away so anything closer (i.e. everything else) will show up in front of it. It makes sense, too, and I prefer when level designers adjust their levels accordingly (i.e. show the outside of the buildings you could otherwise look into), but proper level layout and vis can take care of it as well.
 
P.S.: No need to add your name to the thread title, it'll be displayed right next to it anyway.

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

Well, you have this:

rgbGen lightingDiffuseEntity rgbGen const ( 0.000000 0.500000 1.000000 ) //The RGB values - 0, 128, 255 You can only set rgbGen to one value, so the latter overwrites the former. So instead of changing the colour based on diffuse lighting you set a fixed value. 
I suggest you just copy the texture and tint the image itself.

The only base sky shaders set up to emit light are normallight, bluelight, orangelight, test, test3, right_light, test4, test5, kejim_light, new_test, artus_light, yavin_nodraw, hevil, hoth, siege_1, hevil_2, test_korriban1 and rail_sun. If you use any other shader it's normal to have no light.

MD3 vertex coordinates must be within [-512, 512[ on all axes.

You set the texture to use with the md3shader object property as shown in the video at 1:45. You have to use relative paths to Base, so if your texture is in C:/Games/Jedi Academy/GameData/Base/models/map_objects/my_awesome_map/great_texture.jpg you'd set md3shader to models/map_objects/my_awesome_map/great_texture

Take a look at q3map_surfaceModel, it should do what you're looking for. Not sure how well it holds up with slopes, but I guess if you create the models with that in mind (i.e. lower them into the ground) it should work. Maybe create a separate model for slopes.

Strange... the save bug is known in 1.4 but should be fixed in 1.6. If you disable the win32 checkbox in 1.4 you need to manually add the .map to the filename.
 
Where are you saving the maps? Do you have UAC enabled? Do you run the radiant with admin rights?

r_mode -1
r_customwidth 1920
r_customheight 1080
vid_restart
possibly adjusting the FOV (cg_fov, I think)
Videos won't play anymore, if I remember correctly.

That's intentional. Brightness adjustments depend on the user's screen, after all, so it saves the unbrightened image.Yeah, this. The transparency of the leaves is defined in a thing called a shader, which is (in Jedi Academy's case) basically a text file that defines the material. A single broken such file can break other ones as well, so chances are you have a custom map/model/... that comes with a broken shader, resulting in broken trees and who knows what else.

Yeah. 56 is either FLUSH or INSERT. Those names - like the second parameter of the tag() command, which can be either ORIGIN or ANGLES - are turned into numbers as described in behaved.bhc. Looks like the decompiler doesn't turn 'em back into the identifiers. You'll have to do that manually.

This. 
Keep the entity limits in mind, you can't have all that many.