NAB622

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

19 hours ago, dark soul said:

We have multiple loops running in different affects and it goes ok

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

3 hours ago, dark soul said:

Bugs with 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:

1. 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.
2. 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.
3. 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.

17 hours ago, Aldro Koon said:

This is 1.5 => You can type and assign a texture simply by giving the path here

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.

17 hours ago, Aldro Koon said:

Pressing Axial, Natural or Fit saves the changes, and then you can just add a minus or plus on horizontal stretch to flip a texture. It remains perfect that way.

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.

17 hours ago, Aldro Koon said:

Then when you try to flip it by adding a minus or plus to horizontal scale, it forgets everything prior.

Yeah, that's definitely a bug, and it wasn't present in 1.4 IIRC. Interesting.

17 hours ago, Aldro Koon said:

No idea what that texture subsets are but maybe that explains why this shit is lacking so much.

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.

On 7/1/2020 at 12:16 PM, Aldro Koon said:

You can't input textures manually in the surface inspector by typing the texture name. You had to manually search and find them from the big dropdown list and then select the texture you want by scrolling around. Horrible and takes a ton of time to find the particular texture you want.

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.

On 7/1/2020 at 12:16 PM, Aldro Koon said:

Mirroring textures by simply doing a negative or positive next to horizontal or vertical stretch and then pressing FIT or NATURAL would forget the shift I previously made. Doing it the opposite way would completely disregard the other properties of FIT or NATURAL. Thus I had to manually shift every single texture on my own and manually resize them by clicking on the arrows. Then sometimes when I accidentally pressed S as a way to minimize the surface inspector --> It forgot all of my progress and I had to redo this process. At one point I started almost crying. S used to close the inspector without losing any progress in 1.5 whereas with 1.6 it's like a cancel button. Or rather, 1.5 doesn't really have a confirm button. It's always confirming but with 1.6, they for some reason want you to confirm your changes. It's hard to explain with words exactly how inconsistent and messy the surface inspector is when you are trying to fix an image. But it was absolutely horrendous and made the final result be inconsistent in the end. At one point, I even decided to make a texture file be mirrored to save myself the pain. That's how atrocious it was.

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)?

On 7/1/2020 at 12:16 PM, Aldro Koon said:

Dragging items halfway across the map using the grid was far more tricky as the mouse wouldn't properly register my click as I needed to zoom in a lot to be able to click inside of it. This made moving an item halfway across the map a long and tedious project due to how large my map is.

Strange. Never heard that one before.

On 7/1/2020 at 12:16 PM, Aldro Koon said:

Free rotate tool is missing and the vertex stuff was also annoying.

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. 

On 7/1/2020 at 12:16 PM, Aldro Koon said:

Clicking on multiple lights will display these big ass white balls that completely cover the camera and make you unable to see ANYTHING. What the actual hell? I had to almost guess where the next light was at times lmao. Maybe there's a way to turn off that huge radius thing but I couldn't find it. I know it was possible to do in 1.5 (although there it never actually blocked my vision, it simply became transparent if I recall right).

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.

On 6/28/2020 at 6:45 AM, Aldro Koon said:

1.6 was cancer to me, there's so many missing features that I can't fathom how it is actually called 1.6. The G-Wing map we released was made with 1.6 and it made me want to hang myself. Never again, lol.

I never had bugs with 1.5 except on certain .map files for some reason. But once it actually works to use, it's so much better IMO.

Not to derail the thread - but I'm honestly curious, and since this was a hot topic on filefront back in the day, I figure some civil discourse may be helpful.

Specifically what is missing in Radiant 1.6? I think the free rotate tool was missing, but was there anything else? I never really used 1.5 much. I think the vertex editor in 1.5 was also a bit better than 1.4, but just barely. It's still the buggiest thing in 1.4, 1.5 and 1.6.

My primary issue with Radiant 1.5 is that it is bugged and can create brushless entities in the map, and the user won't know until they have already compiled it, which is frustrating and a total waste of time (Back in the day, compiles took hours). Here's a screenshot of it from years ago:

When this occurs and the map is loaded in-game, the user will get the error sv_setBrushModel: null. To a newbie, it's very confusing, especially since they didn't actually do anything wrong most of the time. I couldn't even tell you how many times on the Filefront forums I had to tell people this, it truly was that common. There were also reports of 1.5 corrupting map files as well, although I don't recall if those were confirmed or not. In general, though, I had a truly awful experience with it when it first came out, and reverted back to 1.4 within just a few days.

Personally, I do not recommend Radiant 1.5, as there are a few very serious bugs, one of which can confuse the heck out of newbies. Radiant 1.4 and 1.6 are both good, though.

Radiant 1.6 can be found here:

https://icculus.org/gtkradiant/downloads.html

Not really, since you're connecting them with corridors. What it does mean, though, is that you should use some HINT on those corridors to help the VIS process, but that's all.

Don't forget to post the photos!

blocksize 0 isn't a great idea, but I'm glad you were able to find the problem with it! As long as the map stays small, you should be fine using it. If it gets larger, try a different blocksize, like 2048 and see if the issue persists. Just remember that for the future, don't default to blocksize 0, as it will have effects on larger maps.

As for what blocksize is and how it works, here's an excerpt detailing how VIS works, taken from here:

http://nab622.com/tutorials/MappingErrors.html#show all:_:compile_time_errors-max_map_visibility-full_explanation

Quote

To boil it down, VIS works like this:

- During compile, a single, large brush is generated for every area of your map that is fully enclosed in 'Structural' brushes, encapsulating each one.

- The _blocksize value in the worldspawn is used to break each of these brushes up into equal sized blocks on every axis (Default 1024 units).

- Next, these blocks are sliced along the planes of each HINT brush in the map.

- Finally, every 'Structural' brush in the map is CSG subtracted into what remains (Detail brushes are ignored).

The resulting pieces are your map's 'Portals', and they are then used to determine what areas of the map are visible from each other.

Somehow, between the blocksize slices and the portal slices, the compiler bugged up and was marking the offending geometry as being not visible. Also, thanks to the images you posted with showtris, there's some really odd slicing going on with that wall, which is weird because it shouldn't be slicing at all.....that's one thing I wish q3map2 had never done was slice brushes every place they intersect. But that does explain why part of it was visible, and part of it was not.

Just a heads-up - Chrome does not like tinyupload, and actually blocked me from visiting the domain and from downloading your map file. Might want to use a different service in the future.

3 hours ago, Ramikad said:

What suggests me that it's actually another brush overlapping it is that you said you tried to recreate it with the same results - that shouldn't happen. Other than that, I don't know. One last thing you could try would be to move all your map by a little in any direction - say 128 units (a random number) - and see if that changes anything.

As weird as the suggestion sounds, I'm with Ramikad on this one. I think there's a suspicious thing going on with the VIS. Try moving the map a little on all three axes and see what the result is. Worst case scenario, it just doesn't work.

The reason I'm thinking that is.....the default blocksize of any map is 1024, and most of your outer walls intersect the 1024 and -1024 points on the grid on several axes. Additionally, your VIS is creating a lot of slices, many of which branch out from the center and spread out to your outer walls. It shouldn't actually cause any problems - but admittedly, it is awfully suspicious that the wall seems to be breaking near where those slices intersect it.

3 hours ago, fullkevlar said:

is it okay to select the whole map with a box and move it at one time?   Or would that produce the same bug, just moved to different coordinates?   I'll try either way when I'm at the computer later today.

Yes, it is okay to move everything at once. The easiest way is just to deselect everything and invert the selection - no need to use a box. For extra caution, you can always save the map as "Delete_me.map" before doing it so there's no risk. If the problem is related to the blocksize somehow, it might actually fix the issue. If this does nothing and the issue follows the map to the new coordinates, that will help troubleshoot it.

If this doesn't fix the issue, try turning on /developer 1 and /r_showtris 1 and post a screenshot of the broken wall from a distance.

Also, just a technique suggestion - if that is the final size of your map, you might even consider ignoring VIS altogether - just leave the outer walls structural, and make everything inside detail. There really isn't much to hide from any angle, so why bother to optimize? It's unlikely, but possible, that this will help too.

I'd like to take a look at this too, actually - at what coordinates in the map are you seeing the void? (I'm not at my computer right now, but having coordinates will greatly speed this along)

You need the count -1 on the target_scriptrunner, not the trigger_multiple. That should fix it.

Also, a better practice would be to avoid target_scriptrunner altogether for this. Just add a useScript to the trigger_multiple, and you'll get your infinite uses and save a few entities in the process.

Edit: I've found that func_door is a lot more useful for scripted elevators. Func_static doesn't have a lot of extra utility to it. 

Also, instead of ref_tag, you can use a move block in your script to literally move the elevator anywhere you want in the entire map. Ref_tag is valid, but not nearly as flexible.

I'm not sure why you got a qpath error - as long as you replaced the old file with a new one that had the exact same name and path, it should work. But, I can address the other two things.

First and foremost, JA can only read MP3s encoded at 44.1 khz, 128 kbps constant bit rate, stereo. As far as I know, literally nothing else will play. Re-encode your MP3 to match these settings and give it another go.

For your CM_LoadMap error, the server and client must have the same BSP - if you modded the BSP on the client but not on the server, there's a good chance it triggered some validation check, resulting in that error. I would suggest reverting the BSP back to the original one from the download, as there is no reason re-encoding the file and replacing the one in the PK3 shouldn't work.

If all else fails, in a pinch you can just add your MP3 directly to the game's 'base/music' folder and play it at will with the /music command.

If I understand this correctly, you're saying that when arbitrarily rotating a brush, the textures shift? As far as I know, this is either normal, or a bug in Radiant.

In my opinion, the best answer would be to never use arbitrary rotation. Use edge or vertex manipulations instead. They come with their own problems, but arbitrary rotate will misalign vertexes like crazy, which is even worse. However, the texture coordinates will remain the same if you're doing a vertex or edge edit.

If you need a precise texture alignment and the ability to perform an arbitrary rotation, use a patch mesh. Textures on patch meshes never shift during edits of any kind.

See if the game console has anything to say about it. Usually there will be some warning in yellow that tells you what's wrong. Most likely it's a missing texture, and if it is, the console will tell you what's missing.