NAB622

Should be fine if they're the same targetname and the same color. Go for it. No, users would still have to download the bsp and the shader file somehow. The only way to host a server where the users don't have to download anything to join you is to use entity modding, which is very restrictive on what you can do. You cannot create any assets when entity modding, and you are limited to whatever bmodels are in the map you've loaded. As far as copying the system shader for your own use - I'm sure it's just using map $whiteimage. Very easy to recreate. I can't write shaders freehand or i would post one here.

Yes, to change colors you just toggle two (or more) lights. Just keep in mind that you can only have four lights hitting a single surface or the lightmap will go crazy and bug out on you. For the door, I'd have to see the texture, but I'm sure it's possible. The CAP option in the patch inspector should be a good start. You could also use brushes if you want to. It's a lot easier than it sounds, i think, but you have to know your way around the surface inspector and/or patch inspector to do it.

I don't see why you couldn't make a circular door..... Maybe I'm not understanding fully what you mean with that though. Edit: Do you mean applying a texture to a 'Cap' patch without it deforming around the patch? If so, yes that's possible. Lights can't change color, but you can toggle them, and that would be a pretty good alternative. Grapple hook that latches onto players would not be possible without a code mod for sure.

Thank you for posting your solution. I will be adding a fix for this in my Radiant fork, so hopefully nobody ever has to deal with this again.

If the .bak file is smaller than the .map file was before the incident, it does not contain everything, as it is literally just a copy of the map file and should be identical in size. Autosave.map would be your best friend in this scenario. However - most of the time, if you look at brackets and quotes in a text editor, you can generally find the errors in .map and .bak files pretty easily. For instance, if an entity was given a double quote in one of it's values, that might confuse things. When loading a map, I believe the console in Radiant will tell you what line the failure occurred on.

If you're okay with rebuilding from the autosave, that's fine. If you'd still like to shoot for restoring what was lost, check the size of the .bak file. If it's anything above 1 KB, the map is in there, but a syntax error is preventing it from loading. Those can be found and fixed in a text editor. Either way, glad to hear that everything wasn't lost!

You might want to try different versions of Radiant, 1.6 is kind of a bugfest right now (Well, really, they all are, but many of the bugs are different between each version). Other than that I'm really not sure what's wrong, sorry. :/ I hate everything to do with Radiant 1.5, but I think most people use that or netRadiant these days. A lot of people say that netRadiant is good, although I found it unusable on my computer.

Make a copy of the .bak file to somewhere safe, then rename it to .map. Load it and see what you get.

Good point, I never liked it either. I think it's supposed to help detect shader conflicts, but honestly, it makes it worse because you never know there's a conflict from another shader. I had accepted it as a fact of life years ago. I'll add it to my todo list, although it'll be pretty close to the middle for now. Going to try migrating from GTK2 to GTK3 soon, that'll be a big job.

Is there still a .bak file in the same folder as the .map? If so, copy it for safekeeping immediately. It can be used. Also, check autosave.map. If neither of those work - what is the size of your .map file?

Hmmmm.....not sure, then. Is shaderlist.txt present in base/shaders? That's the only other thing I can think of.

At the top, where it says Basepath, it needs the base folder, not the gamedata folder. Add "base" to the end of that line and you should be good to go.

Another update! Big progress today. The horizontal culling code in the renderer has been corrected! FOV settings above 90 will no longer bog down the renderer. Vertical culling code has been added to the renderer! This means that all four sides of the camera will cull out brushes that are not visible (Previously this was restricted to just the left and right). This should greatly increase performance on large maps, especially when the render distance is set up high (The old render distance was 20000, and I have it set to 65536 by default now). Misc_model_static will now show up just like a misc_model, instead of a pointless red block. The preferences have been updated to reflect all the new camera settings. I have an image and a video of the changes below: (The video is actually high quality this time because I fixed the bad recording settings in OBS.....whoops) Thoughts are welcome!

Okay, yeah I see why you're confused.....I'll start from the top with this one and try to clear everything up. Firstly, target_scriptrunner is unnecessary in most cases, although it's perfectly valid to use it. If you're firing the script with a trigger, you can use a trigger_multiple with a usescript value and it will have the exact same effect. On to the entity setup... Scripts can move func_ entities (Except func_group), so you'll need to set up your mover that way. func_door, func_wall and func_static are all valid movers. (I hate func_static, but that's another thing entirely). To have your script move that particular mover, you'll need to use an affect block in your script (Which you have), and on the entity you'll need to set a script_targetname to match. Any movement you apply will now directly affect the entity. Make sure you use an origin brush as part of your entity, so rotations don't get messed up. Now, it looks like you have a misc_model involved with your mover. Misc_model will not move on it's own. You need to set it's "Target" value to be the targetname of whatever func_ entity you want it to follow. Right now you have it targeting the target_scriptrunner, which won't do anything. For the script, you're using a task within a loop. Unfortunately, all this will do is rotate the affected mover 5 degrees on all 3 axes, and then stop. Moves and rotations are applied directly to the vector and angle values on the entities, so applying a rotate 5 5 5 more than once will make no changes. Furthermore, you don't really even need the task for that - just apply the rotation directly. Is your desired affect to make the entity rotate over on all 3 axes? If so, check out this script from Taspir Power Complex V3 that rotates a vortex cube over the center of the map: The use t615 line at the top triggers the mover, which is a func_wall, between being visible and invisible. The use "nothing" blocks are there to pad the loop, since there's a bug in JA that rearranges the first and last blocks of loops. Good luck, hopefully this helps! Any further questions, post back and I'll try my best to help.

Post a picture of your script, and a picture of the entity window with your mover entity selected, and we can get you all set! Most likely, your issue is the lack of an origin brush, but it's hard to say without seeing the aforementioned items. Also, to help with debugging scripts, type /developer 1 in the game console. Everything a script does will print to the console.

Right now this is native to Linux. I'd love to get it on Windows but I'm not very skilled, so I'll revert back to the old Scons build system for that, cross my fingers and hope it works. If it doesn't, I will still try my best to get it on windows.... But like I said, not much skill here. Right now that's not even close, though. I'm going to be looking into the possibility of migrating to GTK3 once enough of the bugs are fixed. GTK2 only supports three mouse buttons, and I'd like to use buttons 4 & 5 to change the current grid size, since I attached everything to it. We'll see what happens...

Aw, thanks. I have no doubt this will take at least 6 more months to complete, maybe even closer to 10... But when it's done it'll make things so much easier, at least for me. I still plan to do those tutorial videos, too, but I can't even start them until radiant is done anyway. Ultimately, Radiant should just be replaced with a whole new program, but I don't have the skills or the time to start from scratch. Plus, as I say all the time, Radiant's internals really are rock solid, they just need the bugs fixed, and a UI to match.

Another update! Here's what's new: The plugins are all fixed and working again, Bobztoolz in particular. The camera view now has a horizontal FOV setting (As of right now, this WILL adversely affect frame rate if it is over 90 degrees since I couldn't figure out the culling code, but the new cubic clipping settings should help with that). Had to get some help on this one, but it's absolutely worth it. The grid and camera had bugs where they would not re-render when the windows were resized. This has been fixed. EDIT: The dialog boxes have had mnemonics added. Instead of having to click "Yes" "No" or "Okay" all the time, you can now use the keyboard (Alt + mnemonic key). Small change, but great for power users. The patch inspector is almost done! I have attached an image below, let me know what you think (I'm very interested in input): I do also intend to do some major overhauls on prtview and gtkgensurf, but that's stuff for later. Both of them are full of useless, bogus settings that don't need to be there. Prtview can actually be reduced to just a toggle button, so that'll be my goal when I get to it.

Hmm. Not sure why...... They load on my phone and my computer. Here's direct links, although that probably won't be any help: http://storage.nab622.com/nab622/CameraFOV1.png http://storage.nab622.com/nab622/CameraFOV2.png

Small update. As usual, not much to show, but here's the goods: Vertex and edge flags are now a LOT larger. Since you can zoom in much further than before, this will make vertex and edge selecting and editing much easier. The size was also added to the preferences, so it is easy to change if you don't like it. The camera icon on the grid now has a thin black outline to guarantee visibility. In the previous update, I had made the FOV lines for the camera icon (On the grid) change in length based on the camera’s angle relative to the current grid view - now, the aperture angle of the FOV lines will change to match the current camera FOV (Based on the window size). The camera icon will now tell you exactly what it is looking at on the grid. Fixed a bug where the grid and camera would not re-render correctly when windows were resized. Rewrote the way the grid zoom is calculated. It is much cleaner now (No visible change with this one). The undo buffer is now cleared when a map is loaded or a new map file is started. (No idea why this wasn't a thing to begin with). Here's a few shots of the improved FOV indicator, as well as the new vertex flag size: I know progress has been slow, and I apologize for that, but I'm still working a lot of hours, and that's my main inhibitor - the second inhibitor being that I'm having to learn some basic vector math as well as C, and I am very bad at math.

This is a relatively small update, related to the one above. I've made lots of small changes, but some of them required figuring out some vector math (Yikes)...and it's impossible to show what's happening with still images, so here's a video of what's new: The new stuff is: The camera icon on the grid has been made bolder so it is easier to see, and the FOV indicators on it will change length based on the camera's angle relative to the current grid axis. Moving and angling the camera on the grid (Ctrl + Middle click to move, middle click to set angle) is much improved as well, although most of the changes there are likely not noticeable. Bottom line, the camera will correctly "Roll over" to the other side, instead of turning upside-down and/or reversing the input like I've seen it do in the past. (Not sure what version of Radiant that was???) Finally, the angle arrows on entities will show the correct orientation when targeted at an entity, or when using the "angles" key, and will update every frame, so they will always point in the right direction. I forgot to show the dotted line selections, but you can sort of see it in a few places. Also worthy of note, Bobztoolz is completely broken and doesn't even show up on the plugins toolbar. I will have to fix that soon.

Type /developer 1 in the console and your messages will appear. ?

Small update! Got two more things added, although I had to have some help. When a map is loaded, Radiant will now snap the camera to the location of an info_player_intermission first (If there is one). Info_player_start and info_player_deathmatch are still used, but they are fallbacks. Radiant will also take on the same directional angles (Including those of a target!) of whatever entity it snaps to. This means that Radiant will see the same thing as the game when the map is loaded. When selected items are hidden behind other geometry, the selection outline will show as a dotted line, just like Radiant 1.5 does. Here is a shot from ffa5_sample, just after loading (To show the camera angle), and with a few items selected to show the dotted lines:

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!