NAB622

What is that snippet of code you posted? It doesn't look like a .map file or a .shader file...as far as I can tell, the error is complaining about line 47373 in your .map file. It's likely a bad value on an entity that's causing a parse error.

Update! Nothing visual to show for this one either, since it's all internal - but the internal vector math in Radiant has been converted from float precision to double precision. What this means is: The lowest precision on the grid will indeed be 0.03125, not 0.125 You can edit at 0.03125 all the way to the edge of the grid, and your edits will not flake out You are guaranteed the 6-decimal precision of a .map file all the way to the edge of the grid (No float point errors) The grid can theoretically increase in size (This is a bad idea since JA still runs on float precision, but it CAN be done) q3map2 should not need the T-Junction phase any longer, which is good because it creates a bunch of pointless geometry everywhere Now, because of this, I still have several serious things to fix: q3map2 is completely broken (It's still running on float precision internally, and I will have to have it convert everything down to float when it saves the BSP file) The grid view in Radiant needs a few heavy changes to the way it renders - if you zoom in to 0.03125 and go halfway to the edge of the grid, everything gets janky and unusable, and it gets worse the further you go toward the edge Radiant is somewhat less stable, since there are still things trying to run on float precision in various places. I have to hunt them all down Finally: The camera window will also likely flake out a little (Below 0.5 precision) at the edge of the grid, since OpenGL runs on float precision. I do not intend to even try to fix this, as it will reflect what will happen in JA, since JA also uses float precision. Hopefully I will have screenshots of a few new things soon, but since this is all internal stuff, there's nothing to show yet. However, once the internals are set, the benefits will manifest in the other features!

None that I know of. Just play around until you find them, sadly. In my fork, I am adding the functionality of J to the preferences menu, because it really needs to be somewhere. I was not aware of that shortcuts list, so thanks for that. However, do not trust it - use it as guidance only. At a glance, many of the items on it are severely outdated as of Radiant 1.4, and that was about 15 years ago.

Press J a few times. 🙂

Sorry for all the waiting - still working a lot. I haven't finished the patch inspector yet. I am close to done with it, but the UI isn't finished, so I don't want to show it just yet. In the meantime, since I've been working on the preferences, I thought I'd show what I was up to over the last few days:

I believe that's supposed to be saved in jampconfig.cfg, but if it isn't, open jampconfig.cfg in notepad, and add your cg_fov command at the end of it. That should work.

I can say from experience that music files above 128 Kbps frequently fail to load, at least when created with Audacity and the LAME encoding library. Not sure why.

Ohhh, you're using the tag stuff for movement....I hate that method. I don't know if it's responsible for your problem or not, but it's a silly method in my opinion, because it requires you to recompile the entire map for any change in movement. When you are using a move block, you can just move the elevator to any arbitrary coordinates in the map you like - there's no need to use target_position or ref_tag or any of that nonsense. Better still, if your elevator has no "Origin" brush, then 0 0 0 is the starting position of the elevator, and you can move it relative to that. So, moving it on the Z axis by 192 units will move the elevator up 192 units (I forget which order the axes are in). Plus, you can guarantee that the elevator is always back where it started by telling it to move to 0 0 0. The biggest advantage to this method, though, is that if you change something in the script, all you have to do is recompile the script and reload the map, and you can see your changes immediately. You will not have to recompile the entire map. If your elevator does have an "Origin" brush (Which is required for rotation), then the exact center of the "Origin" brush will be the elevator's coordinates in the script instead of 0 0 0 - it's a little more tricky to use this way, but you can still make a working elevator without too much effort. Also - keep in mind that you can take an even easier approach to this entire thing, and just use func_doors for everything, and have the script use the movers in the order and timing that you want. This is by far the easiest, although least flexible, way to go.

Post a screenshot of your script. It's probably something to do with the method of movement.

You can just add that into the script, either by using move blocks on the doors or by having the script fire a func_door by targetname, with a use block. Ideally, the doors should be part of the building and not the elevator, or bad things can happen. Side note: instead of using a target_scriptrunner, you can put a usescript on the trigger_multiple, it should have the same result and save you an entity.

Are you talking about SP or MP? In MP, g_npcspskill is definitely the variable used to calculate the health, not g_spskill. The actual calculation for NPC health is in NPC_spawn.cc, around line 930: if ( ent->health ) // Was health supplied in map { client->pers.maxHealth = client->ps.stats[STAT_MAX_HEALTH] = ent->health; } else if ( ent->NPC->stats.health ) // Was health supplied in NPC.cfg? { if ( ent->client->NPC_class != CLASS_REBORN && ent->client->NPC_class != CLASS_SHADOWTROOPER //&& ent->client->NPC_class != CLASS_TAVION //&& ent->client->NPC_class != CLASS_DESANN && ent->client->NPC_class != CLASS_JEDI ) {// up everyone except jedi ent->NPC->stats.health += ent->NPC->stats.health/4 * g_npcspskill.integer; // 100% on easy, 125% on medium, 150% on hard } client->pers.maxHealth = client->ps.stats[STAT_MAX_HEALTH] = ent->NPC->stats.health; } else { client->pers.maxHealth = client->ps.stats[STAT_MAX_HEALTH] = 100; } That said - it looks like it also affects some other things with the AI directly below that segment, so modify it with some caution. Edit: It also shows up all over the place in the NPC code in general, so yes, definitely use caution editing that.

Before I get too much farther, I have to ask - does anyone here have experience with compiling GTKRadiant for Windows? It looks like it's going to be a nightmare, and any help would be welcome. The instructions guide is less than helpful, and I'm still totally new to all this. Progress is getting a bit slower - I'm fixing a lot of superfluous bugs and bugs that are under the hood, plus I'm running into much harder stuff that I'm needing to seek help for. I did make a few more modifications to the surface inspector - and now, it can accept 2 decimal places when fitting a texture, as well as negative values, making the effective range -512.00 to 512.00. Hopefully the changes aren't confusing - let me know what you think! Next up on the list: the patch inspector is getting addressed.

netRadiant custom will likely be far more advanced than this when it is complete - all I am trying to to is bugfix the program so it stops crashing as much, and simplify/streamline the interface where needed. Once I make the tutorial videos, I intend to leave it be, except for the occasional bug fixes. I'm just trying to keep this as close to the original release as possible while making it actually usable, even for games other than JA. That said - while digging through the source, I've discovered old features that fell by the wayside, that will make mapping so much easier - they just needed a re-tuning.

I just spent some time redesigning the surface inspector. Here's what I came up with. Anyone have any thoughts? It still has all the functions the old one did, plus some extras for ease of editing and to help newbies understand. (Keep in mind that the dark window color is from my GTK theme on Linux, and on Windows it will probably be the usual light gray) Is this easy enough to understand? Is it too cluttery? Is it missing something important? Is it perfect?

Update for the last few days of work (I'm under quarantine for the next few days so I'm getting a lot done): The camera is now bound to the grid. There is a small "Cushion" distance outside the grid boundaries where it will be allowed to go, but it will stop there. No more getting lost out in the void. The grid view cannot leave the grid. Again, no more getting lost. Brushes cannot be rotated/scaled/created/resized outside the grid. As soon as the grid boundary is reached, Radiant will cancel the operation and give a message in the console. Because of how I did it, this does mean larger operations will be a bit slower - but with how fast today's computers are, I doubt it'll be noticeable. (Still working on stopping the user from moving existing brushes off the grid, though.) Surface inspector will provide live updates for textures being drag-edited in the 3D view. Surface inspector will now "Roll over" the shift and rotate numbers when it reaches the maximum - so if you have a rotate value of -15 on a texture, Radiant will change it to 345. Same thing with hShift and vShift - if they exceed the texture resolution, they will snap back to where they should be. This takes place seamlessly in the background and should not be noticed by the user, and makes texture editing much easier. The fit option in the surface inspector can now fit up to 512x512 (Instead of 32x32....I've had scenarios where 32 wasn't enough). This also works with the aforementioned rolling over of hShift and vShift numbers as well, resulting in easy numbers to manipulate. I still have a long ways to go, and there's a significant list of bugs I've created along the way.....but so far these are far less serious than the ones being fixed.