NAB622

Just so nobody gets worried/disappointed in the lack of updates, I am working on some features, but nothing is finished yet. Regardless, I am putting this project on a temporary hold due to work hours, and the fact that I need to finish up a few other things. If all goes well, I should be back at it in January. In the meantime, if anyone else is interested in the code, it is all available here: https://github.com/nab622/upgRadiant

When you try to load the map and get kicked back out to the main menu, the game console should show an error message. What does it say?

It may be a little bit harder than it looks, but not at the corner you're pointing to. That corner should align perfectly. The angled faces on the inside of the pillars will likely be the issue. Simply copying the texture coordinates (Middle click to choose a texture and coordinates, and ctrl+shift+middle click to apply) should do the trick everywhere else. If it doesn't work on the angled faces, try reducing the angle slightly, and it might align.....otherwise you might need to use patch meshes there, although that wouldn't be too difficult to do either.

The team key is used for doors, to make them move together in sync. In case one door is blocked and reverses, all other doors on the team will do the same. If you want more than one spawner to be fired by that button, just give the other spawner the same targetname as the first one. When a trigger is fired, it will fire every entity with a targetname that matches it's target. The easiest way to do this is just to copy and paste your current npc_spawner - it will keep the targetname. Then you can change the other parameters however you need.

Edited my post, sorry, I think I was confused what you were doing. Hopefully I understand it now.

I think the best you can do in Radiant is to use the natural setting on your patch, and then align the textures on the brushwork to match. You might have some luck aligning the textures with ctrl/shift/alt + arrow keys, but that's about the best I can think of. Alternatively, you could manually do the math for the texture coordinates to the S & T coordinates and plug then into the patch inspector manually, but that's a lot of work. I did add something to address this in my Radiant fork, but as you know, it's far from done. Edit: Wait.....I'm not sure where I got the idea you were using a patch. Are you saying you just want the textures on the brushwork to the left and right of the pipe to align? If so, ctrl+shift+left click the texture you want to use in the 3D window, then ctrl+shift+middle click the surface to apply it to. It will copy over the texture and it's coordinates.

Also - make sure the trigger_multiple is set to trigger by the conditions you want. By default, a trigger_multiple will fire it's target whenever a player touches it. If you want players to have to press the "Use" button on the trigger, you'll need to set the player_use spawnflag. If nothing works, post a link to your map file, and someone here can definitely tell you what's wrong.

Create a trigger_multiple for the button (Don't forget a wait key on it). Target it at an npc_spawner entity. On the npc_spawner, I forget the key name that determines the NPC to be spawned, but i think it's npc_type. And you may need to set the count value to -1.

If ref_tags don't count, then yeah, there's no entity advantage. There are two tiny editing advantages, though - ifyou use the script to move it, you only have to recompile the script (Not the map) when you make a change. This can help on very large maps. Second, if you do not use an origin brush on your mover, the coordinates are essentially relative to the starting point of the entity - meaning you can make a single script to use across many entities (Just don't rotate it or stuff will go crazy, since there's no origin). I don't think either of these apply to what you're doing, I'm just throwing them out there in case they're useful to you or someone in the future. You've obviously made great progress, and I'd love to see the finished product.

Ah, also very good to know. The only bug I was aware of was the loop rearrangement. Thanks for seeing it through and posting back, I'm learning from this. You can save all the ref_tag entities by using move blocks, by the way. You can move any func_ entity to arbitrary coordinates at will.

Ouch, I did not know that. Thanks for the info! Glad everything's working. So the loop doesn't rearrange the first and last blocks on you? I had tons of issues with that years ago.

No, it looks like you're doing everything right...I would definitely verify that the deathScript on the turret is working, though. I've never used turret entities before so I have no idea how they work. I can't tell much further without seeing the map, though, sorry. I don't mind taking a peek at it if you're up for it, but it will take me a day or two to do so. Since this is undocumented territory - as a point of reference for incrementing variables, here's an old script I did for Taspir Power Complex V3 that runs when the map is loaded, continuously incrementing two timer variables for nefarious purposes:

Affect blocks look for a script_targetname, not a targetname. Make sure you're using the right one. Also, unless there is more to that script that that loops or waits, you don't need that flush() block at the top. Flushing is only used when you need to stop all existing commands before running new ones. To help with debugging, type /developer 1 in the console. You'll get a blue line in the console for everything your scripts do. Yes, scripting truly is a disaster.... The functionality it adds is incredible, but it's very broken in many areas. Fortunately for you, though, I don't think you're using any of the broken stuff for this.

Is this single player or multiplayer? I don't think controlling an entity works in multiplayer...

If Jeff's suggestion doesn't work, check the console for errors. Often it can guide you right to the problem.

This sounds awesome, actually. I think you can probably get this down to 22-ish entities total...It's probably going to be a long process for me to assist, especially since I'm extremely tired and I can't even run BehavED right now, but I'll give you what I can. As far as entity reduction goes, none of your desired actions requires a target_scriptrunner. Instead of using those, put a useScript on your trigger_multiples. You only really need target_scriptrunner when you're running the script directly on a player (Like messing with players' parms, changing their height, making them invisible, etc). For your turrets, since parms are kept between deaths, it sounds like deathScript might work too. It should run the specified script when the entity is destroyed, but not removed from the game. In the script that is run, if you increment a global variable each time a turret dies, it should make detecting turret deaths very easy. (The variable would need declared and initialized to 0 in a setup script, which can be done by adding a spawnScript on your worldspawn.) Incrementing global variables can be done by setting the value to "+1". (This does not work on parms, it is bugged.) As far as checking whether the turrets are still alive or not, there are several ways to do that....I'm still hashing that out in my head. Keep in mind, though, that there needs to be a client detection mechanism to keep the players from being locked out if someone dies while the turrets are active. So far, is any of this helpful? Or am I off on the wrong track?

Yeah..... There's a lot of bad info regarding icarus out there. I don't have the time to give you a full reply right now, but I don't think you can use parms for counting in this instance, since the turret should respawn on death and I'm pretty sure that resets all the parms. Could be wrong on that. Not sure since I never really played with turrets. If they don't reset on death, this will be mega easy to do. At the very least, i can tell you that you can increment and decrement global variables, just not parms - so that might help a bit. Could you be a little more specific about what exactly you're trying to do, though? There's several ways to go about this, and I don't want to go off on a long rabbit trail in the wrong direction.

After poking at things, I don't see a GTK3 migration being very likely any time soon, so I'm moving it to the very end of the todo list. GTK3 removed a lot of functions that Radiant used, and while there is a backward-compatible community tool I can use to get that functionality back, I don't think that tool will play nice with Radiant's old version of OpenGL. And I am not about to update OpenGL, since that would literally require a total rewrite of everything involving rendering - grid, camera, plugins, texture window......everything. So for now, I will continue working on it as-is - GTK2 and OpenGL 1.1.

Yeah, I've been working too many hours for the last decade. I do intend to finish this eventually, as I have actually been working on it for 15+ years on and off, but Radiant is actually the problem with this one. Since I prefabbed the hallways, I would really like a working cut-and-paste prefab system within Radiant that works like a photoshop smart object. It's a huge pipe dream, but the payoff would be amazing. I haven't even started on it, though. Right now I'm trying to migrate Radiant to GTK3 and it does not like me for it. Lots of hackery to fix. Basically, though, as soon as Radiant is fixed up and the tutorials are made, finishing this up is my next goal (Well, my next JA goal anyway, I do many other things outside this community). But it'll be a long time coming.

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!