NAB622

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.

Does anyone have any objections to this being renamed to "UpgRadiant" ? I need to change the name, and that describes what it is pretty well, but I'm terrible with names.

So my big project for now is to make mapping tutorial videos...and GTKRadiant is such a bugfest that I want nothing to do with it, both 1.5 and 1.6. That said - the internals of Radiant are actually rock solid, but because of the bugs nobody seems to care much. So - Radiant 1.6.6 has been forked, and a new branch is being worked on, currently referred to as DogiRadiant. I don't have anything visual to show for it yet, other than a screenshot of the modified color scheme on the grid, but here it is anyway: Things that have been removed: The preferences menu has been almost completely gutted. Most of the nonsense features have been removed. There are so many things in there that were relevant to 1999, when computers had 64 MB of RAM. It's 2020, and it's time for it all to go. (The code for these features mostly remains, but they have been removed from the menu) The Z-Window, on the far left side, has been completely removed. It was useful in the days of DOOM and Quake 1, but not any more. New features that have been added: The grid can zoom in much farther, and also zoom out a little bit farther as well. The grid can now go up to 4096 in size, and down to 0.125. (It can actually go down to 0.03125, but due to float point inaccuracy it has been capped at 0.125...for now.) Cubic clipping increments have been increased from 64 to 1024, and the maximum cubic clipping distance is attached to the maximum render distance Maximum render distance has been drastically increased to 65536 (Half of the entire grid) - Cubic clipping can now be used if Radiant is running too slow Texture window scaling has new pixel-size options - normally, textures can only be scaled at 10%, 25%, 50%, 100% and 200%. New options are 64 pixels, 128 pixels, 192 pixels, 256 pixels, 384 pixels, and 512 pixels. (This was previously an option hidden in the preferences, but it makes so much more sense in the menu, and is easier to use with predefined options) The 3D camera movement was removed from the preferences menu, and has instead been attached to the grid size. So if you are doing a detailed edit on a small object, it will be very easy to get close to it. If you are trying to move quickly across a large map, set the grid size up high and you'll be there in no time. The 3D camera view's strafing feature has been modified to not lock the Y axis to a vertical position. If you want to lock the Y axis vertically, press Ctrl + Shift to strafe instead. Bugs that have been fixed: Grid has been recolored so it's much easier to work at both higher and lower settings Edits below grid size 0.5 are no longer lost Dragging something off the edge of the grid will no longer shoot you off into the distance without warning - scroll speed has been massively nerfed Surface inspector no longer performs an "Undo" when closed Surface inspector now updates its numeric values when changes are made to selected materials Large undo/redo operations are now much faster Undo operations can no longer get out of sync - Radiant makes you wait until one operation is done before performing another Increased the undo limit from 64 to 512, and changed the maximum undo memory buffer size from 2 MB to 2 MB x the undo limit (So maximum 1 GB, more if the undo limit is increased) Right-clicking to scroll in the texture window will now stop at the bottom of the window like it's supposed to, instead of scrolling off into nothingness Making an arbitrary sided sphere or cone brush will no longer crash Radiant, and failure to create them will print a message to the console telling you why it failed Planned features if I can stick with it long enough: Windows compatibility (Right now I'm doing this on Linux, so it will require effort to get it on Windows) Add a preference to the preferences menu for the cubic clipping distance Reorganize the toolbars in a more useful way Make GTKGenSurf more user friendly Fix up vertex editing (This will probably be very hard) Making EVERY edit trigger an undo point (Since the buffer is 512, may as well fill it up) Convert the internals to use doubles instead of floats, and enable the grid precision all the way down to 0.03125 units - this would be excellent for modeling at small sizes If the internal math is successfully converted to doubles, increase the grid size New save format, JSON based "Smart objects" - similar to a smart object in Photoshop, I want to be able to save a group of brushes as a prefab, and then copy/paste it into the map at will, and deform/warp them individually as desired Already the program feels a lot more professional than before - but there's still a very long ways to go. I wouldn't expect to be done with this for a year or so, since I'm new to C and haven't even touched C++ yet. Comments are welcome! Report any bugs you know of, and I'll check them out - I can't promise everything will be fixed, but at least I can look! Also, if another version of Radiant does something better, let me know - all Radiant clones are open source, so it's all up for grabs!

I'm using 1.6.6 as a basis for this, so any bugs that aren't persistent from 1.5 to 1.6 are likely already fixed - but I will keep my eyes peeled!

Just another thought - GTKRadiant does have a built-in plugin called GTKGenSurf, which is supposed to generate terrain, and it looks like it can accept height maps too. Everyone forgets about it because the plugins menu isn't used often: https://icculus.org/gtkradiant/documentation/Terrain_Manual/pages/table_of_contents.html

Do you have the affect blocks together inside a big loop, or loop blocks inside each of the affect blocks?

Yeah, affect blocks and loops do not play nice together. The loop will get rearranged, often into a non-working state.

Yeah, that's probably the only way to do it, and that will involve either a func_train or scripts, and scripts are likely to be a pain here due to bugs with "Affect" blocks. I suppose func_train might be usable too... Maybe that's what they did. Don't let me discourage you - just expect it to be really weird, if it works!

I've never heard that one before..... Interesting. I do know if the surface inspector is already open in the background, it's supposed to close the next time you press S, so maybe it's stuck in the background and not closing..? Very strange. Will definitely poke at that.

I don't believe there is a way, at least not without it being really janky. Trigger_push and/or target_push are supposed to do it, but conveyor behavior wasn't properly added to the MP code.

What are the most annoying bugs to you in GTKRadiant (1.4, 1.5, 1.6 and derivatives)? I'm on a bug fixing spree, and I'd like to keep the momentum rolling. Adding new features is mostly beyond my skills (Still very new to C!), but most bugs shouldn't be a problem. Hit me with all your bugs!

If the original BSP does not reference a music file, I'm not sure there's anything you can do other than use /music. If it does reference a music file (Even if it doesn't exist), you should be able to make your own PK3 file that adds or overwrites the missing file - just name the pk3 something alphabetically later than the original PK3 file. At least, that is how it's supposed to work...

So, @Aldro Koon.....about the surface inspector in Radiant 1.6. It looks like, when they rewrote the surface inspector, they copied it over from inside the main program itself, and made it a plugin...and when they did, they removed the cancel and apply buttons - but they forgot to remove the line of code that performs an Undo when you click cancel, and under certain circumstances, when you close the inspector, it performs an automatic cancel. So if all you did was close the surface inspector and your stuff got all messed up, all you need to do is hit redo, and your stuff should come back. I'm still hunting for several other relevant errors, but that one was pretty easy. No wonder you were so frustrated with it, though! Also - 1.6 is using 1.5's vertex editing code, as far as I can tell, and it's still pretty broken. That's beyond me, though, since I'm terrible at math. Actually it seems like most of 1.6's code is just 1.5...

Yes, actually, although it's still slow going. This topic is having me rethink a few angles: I might actually end up making a branch of Radiant just to fix a few of the really awful bugs in 1.6, but I'm not really sure yet. Depends on how deep the problems go.

@Ramikad pretty much has it on point here. You can script something like this, but if you're just extending a single-piece bridge, func_door is a good option and very user friendly. A couple points of interest: I would not make the func_door usable - rather, I would use a trigger_multiple with a wait key, and have it fire the func_door. Otherwise players can accidentally trigger the door multiple times in quick succession, causing the bridge to reverse when it shouldn't. Make sure you set the crusher flag on the door, or it will reverse when it hits something, like a player or NPC. You can also set dmg to 0 if you don't want it to hurt anyone while crushing. You can use more than one func_door for this - and if you do, make sure you team them so they don't get out of sync with each other. Otherwise, if one door is blocked, it will reverse, but the others will continue their previous movement. Also, just a sidenote - I hate using func_static for scripts. It doesn't have any extra utility other than just moving around. func_door and func_wall are just are usable as far as scripts are concerned, and they add extra functionality to the mix. Origin brushes are only required on a scripted mover when it is rotating - although it is good practice to always have one regardless. Without an origin brush or a key/value pair that specifies origin, the origin of any entity is assumed to be 0,0,0, which will screw royally with rotation.

Well for a cave, you might try these, although you'd have to sew the seams together: As for EasyGen, I haven't heard mention of that in years. I'm sure there's some easier tool by now, but I am not aware of it, since I've basically been on an 8 year hiatus.

The build of Radiant I'm using was forked from Radiant 1.6.6, if that's worth anything. I doubt they fixed many bugs between 1.6.4 and 1.6.6, but there is a small version difference there. In Radiant 1.4 and 1.6 it also accepts paths there - once you press enter, the texture loads. Odd that it's misbehaving for you. Just tested it again on my end and it works as it should. One could argue that you shouldn't have to press enter for that, and I would agree, but that's just how it was programmed. Yeah, that was actually another thing I didn't like about 1.5...they mashed the surface inspector and the patch inspector together as one thing, and it makes the interface too busy. The Natural button was supposed to be for patches only. I'm not saying that there shouldn't be one for brushes, but it clearly was not intended for them. Yeah, that's definitely a bug, and it wasn't present in 1.4 IIRC. Interesting. When texture subsets is enabled, a text field will appear above the texture window. You can type in it to filter the entire texture window by path and/or by filename. It is by far the most useful feature in the whole program with regard to texturing. If 1.5 has it, make sure it's enabled there too. It saves so much time.

Just tested it on my end, and I do not have this issue..? Also, the Texture subsets feature in Radiant will eliminate texture hunting entirely. Very very useful. I don't recall if 1.5 has that or not, but 1.4 and 1.6 do. Make sure you turn that on, it's amazing. Are you sure you aren't talking about the patch inspector..? The "Fit" and "Natural" buttons are only in the patch inspector. And as far as I know, the patch inspector always was always a bugged up mess - are you saying that in 1.5 the patch inspector works better? Or, if you did mean the surface inspector, maybe caps lock was on (Pressing any keys, including numbers, while caps lock is pressed, will make Radiant misbehave and bring up the wrong stuff)? Strange. Never heard that one before. I couldn't tell you how many times I crashed all versions of Radiant making cave prefabs a long time ago, all through vertex edits. Someone needs to fix that. I even used Radiant 1.5 because of the free rotate tool, it was the only time I ever used it for something. That's.....interesting........sounds like a video bug. 1.3 through 1.6 all render lights the same. Not sure if that's the program or something else. Now, to be fair here, I'm running Linux and also a custom version of Radiant 1.6 with a few really annoying bugs fixed - but none of them have been brought up here. It's also entirely possible I'm running a newer version overall. But the way you've described it.....something about the program or your computer definitely was not behaving right. o.0 Edit: Also - the reason Radiant 1.6 looks and behaves the way it does, it because when 1.5 was released there was massive backlash from the community. 1.6 is based off the 1.4 source code, so there are missing features (Free rotate) and some bugs from 1.4 returned. Radiant 1.5 is an only child, so to speak.