NAB622

Where is the "Origin" point of that model? Is it in the center, or at one of the sides? If it is inside the brush behind it, q3map2 will cull the model out during compile, and thus it will be invisible. Edit: As far as the missing textures, if you flush and reload models and then flush and reload shaders, it usually fixes the issue, but that might be outdated info.

I know that if you teleport a player above a vehicle, the player will fall onto the vehicle and enter it. Maybe the same will work with NPCs and the emplaced_eweb, but I really don't know.

I'm a little late, sorry. The reason MAX_MAP_VISIBILITY exists is to save the user from loooooong looooong compile times. The more portals you have in your map, the compile will take exponentially longer. Judging by what you've said, it sounds like your map is being sliced up so much by the default blocksize that it has tripped the threshold of portals for this error. It is also possible that your map "Leaks" - and if it does, this can also cause the error. It is always a good idea to load up your .prt file and investigate the root cause of the error. It's pretty easy once you know what you're looking for, and could be as easy as making some brushes detail, adding a few hint brushes, or fixing a few leaks. On compile, a "Portal" brush is generated that encapsulates all enclosed areas of your map, and the blocksize value (Default 1024) is used to break this "Portal" up into manageable sections on every axis. Next, every structural brush in the map is CSG subtracted into these sections. Since the sections are small, it confines any rogue slices to a localized area, which prevents them from generating thousands of unwanted slices all through the map. If your map has a very large, open area, then yes, you will need to increase the blocksize to prevent the blocks themselves from tripping the threshold - but if you change the blocksize to 0, you disable the block slices, and therefore you must make absolutely certain to use hint brushes to prevent your brushwork from making rogue slices all over the map, or this error will likely happen again in the future. And even if it doesn't cause an error, you still may suffer unnecessarily long compile times (VIS compiles should take a few minutes at most). On the other hand, if your map leaks, then when the portal file is generated, it will not know the outer boundaries of your map, and portals will be generated all over the place and then sliced, which is also not good and can throw you over the limit. Hope this helps, as there is a lot of bad info floating around out there...

Protip for the future - any shaders that show the gray and white "Missing texture" will throw an error in the game console. Always check there first to see what's wrong, because things like path issues will be very easy to spot. ?

Ohhh, okay. Yeah, that should be pretty easy to do, if you intend it to involve all players. With some advanced techniques, you can make it so players can choose whether to participate or not - so some people can play a casual FFA chatroom, while others play a TFFA match in a secluded area. But that would be some pretty involved stuff. It would require overriding the spawn system for players, and I'm not sure it could tabulate total team scores reliably. Something for me to think about...

If you can mock up some rough MSPaint drawings of what you're doing, it might help us point you in the best direction. Keep in mind that, if it helps, you can have multiple brushes as part of a single trigger, all in separate areas of the map.

Teleporting specific players through a script must be done with a trigger, a target_scriptrunner and a target_teleport. Since a script can fire off a targetname, you just need to have the player fire off the targetname of the target_teleport. To have the script running on the player, though, will require a target_scriptrunner with the "RunOnActivator" flag, and a trigger to fire it. If you're just talking about teleporting multiple players in an area and not a specific player, you can just activate a trigger_teleport or a trigger_multiple that encompasses a specific area instead. Teamscore and individual score should be possible to get, but the only method i can think of at this moment involves a polling system and a lot of work. I think health is freely accessible....(I know it can be set, i just don't know if it can be gotten).

Icarus can run its own timer as the game runs, and thus simulate a time, although with only mediocre accuracy. What kind of player info are we talking about? Player names are definitely out of the question, but score is easily available. I can think of some really advanced techniques that can also find the highest score, the player with the highest score, and a faux location for said player as well, although not without a few caveats. But that's reeeeally advanced stuff, like, takes-a-whole-week-to-get-right stuff. Whereas the things in the previous posts take minutes to do.

Restricting the playable area is very possible, and honestly, relatively easy. Scripts can be triggered by many things - map load, a trigger, a target_scriptrunner, an NPC, and much more. If you're interested in another good example of what scripts can do - check this map out (Be sure to run it in duel mode). It chooses a random area on startup to restrict the players to. But in FFA mode, it leaves the entire map open to be explored. https://jkhub.org/files/file/1448-nar-shaddaa-landing-zone-17/ Since it was a group project from map-craft years ago, the source files should all be in there with it. If not, let me know and I can dig them up.

I don't know anything about battle royale (Haven't played a game in like 14 years now), but brushes moving on a timer is VERY easy, and teleporting players is also possible, but with some limitations. It is also possible to activate and deactivate triggers at will, so that might do what you want. IIRC, the only downside to moving brushes is that things like corpses will block them, even if they are set to crush (Just for a moment, but enough to break some things). So if you were planning on making a specific area shrink, it may be a bit trickier than it looks, but it can still be done with some clever brushwork.

Weird, I don't remember that map at all.....and yet I'm glowingly credited in the readme. I might have to give that a look. Edit: Just loaded up Malevolence, I still don't remember it at all but it's really cool. Not to downplay it, but that's some pretty basic scripting stuff overall. Most of it is pretty easy once you know what you're doing. Scripting in MP is HIGHLY limited compared to SP, yes, but there is still a lot you can do with it. Is there something in particular you're looking to do? For starters, brush entities can be moved to arbitrary locations, and basic logic is possible, as well as putting data on players. At one point, I had a working prototype of a cutscene "Engine", so to speak, where all players would be made invisible, and snapped to a specific place in the skybox to watch an animation play. Never did use it for anything useful, though. Too many bugs in the base game to make it polished and properly functional.

Nah, fog should still work with a skybox. But yeah, that's a decent idea too.

YTP before it was cool!

Another alternative that might be a bit easier to deal with - you can use a nonsolid brush for the visuals, and use physics_clip on a patch mesh facing the outside to prevent entry from that direction. If you want the physics_clip to be switchable, you can attach it to a func_wall entity, and target a trigger_multiple at it. (Make sure somewhere nearby there is a brush, ideally a tiny one covered with caulk, as part of the func_wall entity or you'll get "sv_setBrushModel: null" on startup.) Every time the func_wall is fired, the wall will toggle in and out of existence. But because the visuals are attached to a nonsolid brush, they are always present. Sounds like that's what you're looking for, I think?

I believe @@Ramikad is correct. Distancecull should get you there. I believe there is still a hard upper limit on distancecull, though. It won't render an infinite distance, but it will certainly go much farther than the default. Many of the popular maps of yore had issues with it. Naboohills2.1 comes to mind. The entire map was a very very large open field, but the renderer still cut out just before the halfway point.

Do you have a link to the map file? The offending brush shouldn't be too difficult to nail down, and that might help to determine the cause. Unless you've already found help, in which case ignore me.

I can promise you, from experience, that the 1022 entity limit is a hard limit. All other limits are meaningless when you are talking about the total entity count, as they are merely smaller limits in limited areas of the engine inside of the larger overall limit. The maximum entity limit includes things like saber clash effects, players, NPCs, weapons, movers, triggers, target_ entities (Target_speaker, target_relay, target_print, target_position, etc). Anything included during compile time, AND everything generated at run time. It does *not* include some entities, like info_null and lights, as these are removed during compile. Vis has it's own cap on the limit of simultaneously visible entities at 256, but this is completely unrelated to the total entity count. Both limits are important if you want your map to run well, however. This limit also incorrectly includes things like target_speaker, target_delay and target_relay, which are not visible entities. If you want to get more mileage from your existing entities, use scripts liberally. Specifically, using usescript on a trigger instead of firing some target_relays or target_delays will save you a lot of entities when applied across an entire map. (Scripts can even be substituted for a target_print!). If you can use them, scripts are your best friend on an entity-filled interactive map. As far as trigger_space - I'm pretty sure the "Inside" shader is for weather. Could be wrong on that, though. When I used trigger_space, I just CSG subtracted it into a nightmarish rat's nest of messed up brushes. But don't do that unless you have no other choice.

Ya, that test was Cagelight. Ignoring physics for now (They're still a thing). Just focusing on renderer. Because reasons.

I can only imagine how powerful of a rig one would need to raytrace JA in real time, 60fps....

Sssshhhh. Everything is possible. Nothing is forbidden.

Noted. Ashura, to be honest, I never even thought about the minlight issue..... I guess I took it for granted. That sounds like the easiest suggestion so far.

Actually, if I recall correctly, in base JA SP, it does not fade to black when you kill an NPC boss for this reason. Instead, when their health is gone, it instantly cuts to black, and fades the cutscene in. In MP, I'm pretty sure SET_UNDYING does not work.

Yo, I'm just curious what you all think - what would you like to see added to the JA renderer? (Ignore everything about Rend2, I'm talking about rd-vanilla, the base game renderer.) Don't worry about what's possible or not, I'm interested in a complete list.

I can't give any info at this time, I'm really not the one holding that stuff. Cagelight is the boss here. I can say that great efforts are being made, but I don't want to say anything specific. Definitely want to see what pans out first.