mrwonko

I've never experienced either of that, could you provide a small example map of that happening?

I'm sure there are people who could help you if you asked specific questions. "I've noticed some thing aren't doing what I'm used to" is nothing anybody can really help with.

I believe Q3Map2 can extract the lightmap from a .bsp (yielding a set of images) so you can paint it (in your case, make it brighter) and then use Q3Map2 to put it back into the .bsp. Changing the sky would be a matter of editing a .shader file to point to a different sky or replacing its textures - you could open the .bsp in a text editor and do a search for /skies/, that might point you to the sky-shader used.

You need to configure your BehavEd correctly, setting the command description file to behavEd.bhc and the source files path to the SourceForBehavEd directory.

But those are really just like the .txt files BehavED saves, except renamed. For some reason.

Wrong, .ibi is compiled. .icarus is the file extension Raven apparently used, you can just rename them to .txt to open them.

The NPCs need to have the CINEMATIC spawnflag set so the AI doesn't try to do anything except what you tell it to. You give them names using npc_targetname and affect them in your script using the affect command. You tell them which waypoint_navgoal to navigate to using the ordinary waypoint network by specifying its targetname in a set(SET_NAVGOAL, targetname_here) and use set(SET_ANIM_BOTH, ...) and set(SET_ANIM_HOLDTIME_BOTH, ...) to make them play specific animations. You can use tasks with dowait() for a script to wait for the NPC to walk somewhere and use signal() and waitsignal() to synchronize multiple NPCs. You can also create level-specific custom animations by putting them in models/players/humanoid_<levelname>/humanoid_<levelname>.gla - use BOTH_CINEMATIC_X, which are meant for just this. The JKA SDK contains all the SP scripts, so you could take a look at those. There are 3 SP levels or so included in the Radiant Jedi Academy files, which may also help shed light on it.

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.

Could you post an example of a broken decompiled script?

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

Oh, right, it's the light stage that fails. Works once I delete those brush cylinders though.

Well, I get mail everytime somebody posts. I can compile that map without a problem... However there are a couple of problems with the map. First of all, and this is unrelated to your problem, more of the brushes should be detail, like the pillars and basically everything but the floor and the walls. (You can hide detail brushes and patches and entities with ctrl+d / ctrl+p / alt+2 respectively so you only see the structural brushes. Also, and this might just be the cause of your problem, why would you do a round pillar using a brush? That's exactly what curves are for. Curve -> Cylinder gives you a nice cylinder, and Curve -> End Cap gives you nice end caps for your cylinder. Don't use a 20-sided brush. In fact there's hardly ever a need for a brush with more than 4 sides.

I'm not entirely sure I remember this right, it may be caused by having a many-sided brush (or more specifically a brush-side with too many vertices) - anyway, as is always the case with these problems, the easiest thing would be for you to supply the map so we can take a look.

svn.icculus.org/gtkradiant-gamepacks/JAPack is the JAPack. I did not make it, I deleted redundant models (included as ASE and MD3 or those already in the assets*.pk3) to reduce its size. Thanks to that it's now small enough to be included in Radiant builds, like the latest one at http://gtkradiant.s3.amazonaws.com/GtkRadiant-1.6.4-20130824.zip.

Look, it'd be easier to just upload the map for us to judge. Or wait for the tutorial. As I said, it usually shouldn't take more than a couple of minutes, but it depends on the map, obviously.

Well, with a sufficiently detail-brushed map the -vis stage shouldn't take more than a minute, surely not more than 5, in my experience. (Then again it's been a while since I last worked on maps so my memory might be wrong.) In an extreme case your entire map might be detail and you manually place occluder brushes (which is what the antiportal texture is for).

Well, there's there's stuff like grates made out of brushes as well as decorated windows in there, that should definitely not be structural.

Better FPS.

In that case, also include the .map, because lots of information gets lost when you decompile a .bsp back into .map.

That's during -vis, right? That's bound to take long if you have lots of structural brushes, but you generally shouldn't. I'll hopefully start writing tutorials shortly, vis will be one area. I'd appreciate if you took a look here and told me if you need any other tutorials. Easiest way for us to tell you what's the problem with your map is to take a look at it, by the way.

Ignore that and feel free to leave the .md3 out if you're just using misc_model.

Regarding mono/stereo: target_speaker sounds need to be mono (after all there's only one speaker) while background music (the music key in worldspawn) has to be stereo.

The whole purpose of the -vis stage is to calculate the visibility, hence the name. To that end it takes into account only the structural brushes. The point of it is so the game only needs to calculate what's currently (potentially) visible. If you were to put a huge structural box around the map and make everything else detail, the -vis stage would conclude that everything is always visible, so you'll want to retain the basic layout of the map, while making details... well, into detail brushes.

The Source Engine is based on the Quake 2 Engine and thus lacks the Quake 3 Engine's new Patch Meshes for curved surfaces. Q3Map2 can turn patches into "ordinary" geometry with the -patchmeta switch, but the Source Engine has its own compiler without support for patches.

Sure, have as many mirrors as possible, there's no point in exclusives when you're sharing information.