NAB622

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

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

Actually I can 1-up that offer - here's a link to a modded mapextras.pk3 I made years ago. It distinguishes between the different types of caulk and nodraw, and makes them slightly transparent for easier editing. http://www.nab622.com/ccount/click.php?id=5

Those are all stored in mapextras.pk3 - see if you accidentally misplaced/deleted it. I can post mine when I get back to the computer, if that's any help.

I don't know of any way to enhance the bots' intelligence, although I do know if the game tells you bot 'kyle' not defined it means you have the wrong bot name. Try addbot "kyle katarn", that should work.

When I started playing, I used dual sabers, one purple and one green, because it looked hideous/funny.

Can you be a bit more specific - are you just trying to host a JA+ 2.4 server with the alternate dimension enabled, and force powers enabled? Or are you trying to get force powers enabled in the alternate dimension (I don't recall if that's possible)?

Current build (A budget build out of necessity, not a performance build): Ryzen 7 2700 8 core 3.2 GHz 32 GB RAM Radeon RX 5500 Video Card 1TB NVME SSD Also running Manjaro Linux, I'm done with windows.

If it's on a player model, a portal is not an option - tcgen environment is probably your only option. It's not even truly a reflection, though, particularly on a player model. I don't think you'll be able to do a true mirror effect without a code mod and some hackery.

If you are talking about a true reflection of a room, you need to use a portal as a mirror, which is a bit involved. Ifyou are talking about a general shiny appearance, like what is used in the base JA shaders, tcgen environment is what you're looking for.

As far as I know, on PC that only exists as a "Hack" called Autoaim. Naturally, being a cheat, it is very much looked down upon... So I'm not sure anyone here would be interested, although obviously I don't speak for everyone.

I did a test compile with the new file you just sent, but I don't get the MAX_TW_VERTS error. Are you still getting it on your end? As far as VIS goes - honestly, in this map, almost the entire thing should be detail, except for the outer walls of the shaft. There's just nothing to hide from any viewing angle. It can be done, but I wouldn't worry about it too much on something this small, since the performance gain would be marginal regardless. If your VIS compile takes more than one minute you should poke at it, but otherwise it's fine with whatever. If you're actually interested in in-game performance, you would see a much larger gain on this map from learning various brushwork/patch techniques than you would from VIS. But that's another topic entirely, and quite complicated. I really need to get going on those tutorial videos mumble mumble mumble...