NAB622

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

Changing the samplesize during compile is one way to solve this. Another way, which I find a lot more precise, is to use func_group and the lightmapscale key to reduce the number of lightmap samples on areas of your map that don't need much precision. For instance, if you have a large terrain area, make the brushes/patches into a func_group together, then set the lightmapscale on it to a higher value (1 is 100% scale, 2 is 200% scale, 5.5 is 550% scale, etc). I don't know exactly how high it can go, but a lightmapscale of 10 on terrain would likely be unnoticeable unless you need crisp shadows - and for that, you can separate those terrain brushes/patches into their own func_group, and give them an appropriate lightmapscale of their own. (You can also use decimal values to increase the lightmap samples on brushes/patches that you want to look more crisp) This same process is useful on exterior building walls, large signs, movers, or any large brushes or conglomeration of brushes. Hope this is helpful too!

Keep looking. Any place where you used a 12-sided brush or larger, the end cap pieces will cause this error. I only pointed out the three that I saw, but I'm sure there's more. (MAX_TW_VERTS can be caused by other things, but I didn't see any of those conditions when I was looking.) If you don't have any luck I'll take another peek, but I don't have time right this second.

One more point of interest on the MAX_TW_VERTS error. This brush will also be an offender: http://storage.nab622.com/MAX_TW_VERTS_8.png And since the above post had a broken link in it - this thing, in fact the entire platform attached to it and the railings, should also be detail: http://storage.nab622.com/MAX_TW_VERTS_7.png

Okay. I'd just rather have this posted publicly for people google searching it later on. I identified three brushes that are likely to be causing your MAX_TW_VERTS error. I have them selected in the image below, and outlined the offending faces in green: http://storage.nab622.com/MAX_TW_VERTS_1.png There still may be other offenders, but these are definitely causing a problem. The pillars should be simple, just use the clip tool to split those two brushes into 4 smaller ones each. The glass is easy to fix, just make it a 4-sided brush like this: http://storage.nab622.com/MAX_TW_VERTS_2.png Since it's less triangles, it's more efficient on the renderer anyway. As for MAX_MAP_VISIBILITY...ultimately, this is being caused by the way you're using CSG subtract, but it's fixable without too much trouble here. In the future, though - when you CSG subtract something with a lot of edges into a gigantic brush, you should do two things as good technique: Split the large brush so you have a smaller brush that encompasses JUST the areas you are subtracting, so you don't get any rogue slices that span great distances. Make the larger brush a func_group before subtracting. This way it is easier to edit later. With these in mind, here's what you have now: http://storage.nab622.com/MAX_TW_VERTS_3.png And if you use step 1 above, this is what it should look like: http://storage.nab622.com/MAX_TW_VERTS_4.png http://storage.nab622.com/MAX_TW_VERTS_5.png Visually in the game, these two techniques are identical. But the second method prevents huge slices from creating extra geometry over long distances. This will help with your visibility error because there will be far less portals generated. As for what is actually causing your MAX_MAP_VISIBILITY error, I'd wager this little thing is singlehandedly the cause: http://storage.nab622.com/MAX_TW_VERTS_6.png Make the entire thing detal. EDIT: The metal framework across the window is also not detail. You should make it detail as well, that's a lot of slices. EDIT2: Also, make this thing detail, and the entire catwalk and railings attached to it: http://storage.nab622.com/MAX_TW_VERTS_7.png Also, I did notice you have a large, open area outside the playable area - if making that pillar detail does not help, you might need to increase the _blocksize in your worldspawn to 2048. Just be very careful how you use CSG subtract, or rogue slices will cause the error again. ;)