NAB622

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.

ParaTracker 1.4.3 released today. https://pt.dogi.us A method to choose levelshot transitions has been added. Users can decide which individual transitions to use, or none at all. Also a few bug fixes. @@Circa - you can remove the transition hack-stuff from your CSS file if you like. The new method is cleaner and allows more options. Due to how this was implemented, any existing trackers will be restricted to simple fade transitions. Users will have to go through the setup process again if they wish to have more transitions.

Updated again today. At some point the setup page was broken, and we were not aware of it. The setup page is now fixed. Also, some time recently, Chrome updated, and now both Chrome and Firefox do not allow Javascript to read CSS rules. Due to this, the scroll bar on the player list had to be permanently removed to prevent the column headers from misaligning. Users may need to clear their browser cache to reload the CSS and Javascript files, but everything should work now. Please let us know if anything is still broken!

The database will be down for short time to upgrade the database software. Nothing to worry about.

I looked at it briefly on Steam. It's okay......but I have some issues with it as well. They're more personal nitpicks than anything. At least it's more effective than ShaderEd. The source code is on GitHub, yes. https://github.com/cagelight/jaownt I'm just coming off of Christmas overtime (I work in parcel shipping), so I need a few days/weeks to recover, but I have no intention of giving up on this project. It will just be veeerrrryyy sloooowwww going.

Testing blending modes was always the strong point of ShaderED, and highly useful. Viewing animMaps is useful as well. My main point is that if you're doing the shaders by hand and then viewing them in ShaderED, then obviously something is wrong with the editor, whether it is bugs, missing functionality, or a clunky interface. At this point in time, over 15 years after the release of Q3, shader editing should easily be reducible to point and click. Yet it is not. I'm not opposed to typing them manually; I'm just saying that the tools have not stood the test of time and are sorely outdated. A fully visual editor would save a *lot* of time. Neither of you have had any frame rate issues? I've never seen ShaderED render higher than about 15 FPS on any computer.