NAB622

52 minutes ago, kwenga said:

It seems that OJP for some reason won't recognise operators and treats "+1" just like "1". On basejka my counter worked flawlessly.

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:

//Generated by BehavEd

rem ( "This sets a timer and keeps it counting so that the game will know when new players have joined." );
declare ( /*@DECLARE_TYPE*/ FLOAT, "timer" );
declare ( /*@DECLARE_TYPE*/ FLOAT, "timer2" );
wait ( 1000.000 );
set ( "timer", "0" );
set ( "timer2", "25" );

loop ( -1 )
{
	use ( "DEFAULT" );
	use ( "DEFAULT" );
	wait ( 1000.000 );
	set ( "timer", "+1" );
	set ( "timer2", "+1" );
	use ( "DEFAULT" );
}

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.

4 hours ago, fullkevlar said:

I was hoping the relight the whole level using the light entities on a switch.    Probably about 15+ light entities.    In some stretches, the floor would certainly have more that 4 lights hitting it at once across its entire length.

Should be fine if they're the same targetname and the same color. Go for it.

1 hour ago, fullkevlar said:

my understanding is you can host a map with stock textures and people should be able to join without having to download a pk3.

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.

54 minutes ago, TheRedMenace_ said:

My paths were actually wrong and it was such a simple error. It was because my paths had / in it, instead of \. So stupid in hindsight. 

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.

1 hour ago, SomaZ said:

What I really want to see is removing the stupid shaderlist.txt. Is there any good reason to have it?

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.

1. The horizontal culling code in the renderer has been corrected! FOV settings above 90 will no longer bog down the renderer.
2. 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).
3. Misc_model_static will now show up just like a misc_model, instead of a pointless red block.
4. 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:

//Generated by BehavEd

rem ( "comment" );
use ( "t1615" );

affect ( "center_vortexes", /*@AFFECT_TYPE*/ FLUSH )
{
	rotate ( < 0.000 0.000 0.000 >, 0.000 );
	wait ( 2.000 );

	loop ( -1 )
	{
		use ( "nothing" );
		use ( "nothing" );
		rotate ( < 45.000 90.000 45.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 90.000 180.000 90.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 135.000 270.000 135.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 180.000 360.000 180.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 225.000 90.000 225.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 270.000 180.000 270.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 315.000 270.000 315.000 >, 1500.000 );
		wait ( 1000.000 );
		rotate ( < 0.000 0.000 0.000 >, 1500.000 );
		wait ( 1000.000 );
		use ( "nothing" );
		use ( "nothing" );
	}

}

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...