Seto

Hi there. It's a somewhat old thread, I know, but I happened to stumble across this and was extremely curious about it, so much so that I couldn't resist coming back to JKA modding to examine it. I would love to know if a solution was found, but I am sure if one was found it was probably different from the workaround I am about to describe, so I am going to continue to post anyway. First I replicated your problem by simply extracting the entities and doing the onlyents recompile on q3map2, making NO changes. The problem you describe happens as described. Since no changes were made, this can only be caused by q3map2 doing something strange (also you can tell that the light entities are properly linked and it is just the surfaces not lighting properly). Or perhaps we can say that some data related to lighting is somehow being disrupted within the bsp format when q3map2 recompiles the entities and changes the size and memory positions of other things within the bsp. Now, there may be some combination of switches to adjust the compiler which will resolve this issue, but I felt this would take a long time to figure out, plus my memory of how q3map2 works isn't what it used to be. So instead, I used a hex editor to directly modify the entities block of the bsp, which is possible since entities are stored as plain text, and this method should remove all the possible reasons for why this lighting issue occurs from the equation. Now, normally this is not the best way to edit entities because you are essentially limited to only overwriting what is there already and cannot readily change the actual size of the bsp in this way or it will break other things. However, as I recall, all light entities that are not specifically linked to other entities (i.e., lights without targetnames) are only used during the lighting stage of the compile, and after the lighting is already compiled, the entity itself no longer serves any purpose. Since we are already dealing with a compiled bsp, this means we can just find some existing lights (they must not have targetnames!) and simply overwrite them with the hex editor to insert a couple new entities to achieve the desired result. Below is an example of the change I made (I used HxD as my hex editor of choice). I just did a search until I found a grouping of a few unlinked lights and started overwriting them, being careful to preserve syntax and not touch any other entities. Do note that the characters that appear as dots (.) are infact hex 0A (line separator) and should be inserted in the left side this way; the rest can be typed normally on the right side where plain text is displayed. I purposely made it a little bit more complicated than necessary (using target_relay) just to provide some margin for space where you might want to customize the specific behavior or conditions by which this triggers (this is also what the "emptyfield" keys are accomplishing, and taking up space so that we reach where the next ent begins seamlessly). Also, I only downloaded part1 and not part2 of this map for testing, so I had the levelchange point to another SP map just so I could confirm that it worked. The end result is that the lighting in the section in question works exactly as it should, and upon killing the AT-ST at the end, the level immediately changed (based on the "cin1" targetname which I figured out from browsing the map entities). For full disclosure, I will say that for testing this workaround, I did noclip through the map to get to those sections and didn't play through the whole thing. Also, I tested on openjk, although I would expect this kind of change to work perfectly fine on base jasp.exe too.

Bmodel limit of 512, I think. 256 rendered entities per client snapshot (if there are more than 256 entities in a client's view, some of them will simply not render). 32 global vars total in Icarus, if I recall correctly. Also there is a memory allocation limit due to g_newstring being fail... I forget the poolsize offhand, but if you have a map with a lot of strings (target_prints, targetnames on ents, and stuffs), especially if they get used repeatedly like a target_print or something, you can reach this and cause a crash. Offtopic, I am interested in things like the above that OpenJK changes from JKA. Is it all documented somewhere?

lol Sorry if I haven't responded to any messages anywhere. Lately I've been away from all online communications except Steam and Xfire. As for what you saw on School of War, I made that... it's basically a hack of JA+. I learned a long time ago (many years) that slider left some beta testing commands inside JA+, and me and BobaFett (well, he did most of the work at that time) once did the same thing for JA+ 2.3 beta 1 on linux only... then a couple years ago, I decided to go back and check the newer versions on windows, and lo and behold, things were still in there. In simple terms, JA+ has some "locked" admin commands that slider made for beta testing (he told me this himself once) that he didn't remove from the game, but simply made them impossible to use... unless you use a little reverse engineering. It's actually not too difficult and would probably make for a nice tutorial on codecaving, BUT the noclip feature was not a part of this and took more work on my part to accomplish (and my method is not that elegant or versatile, but it served my purposes). For that I basically just figured out where in the assembly code the game would check for admin permissions on any command and had the noclip code jump to that spot instead of going to the code that checks for cheat protection (or maybe I rewrote the admin check ASM... I don't remember :/). At any rate, what you saw on my server was most likely a combination of noclip, invisibility, and efx-playing commands used simultaneously, to give the appearance of a teleport, rather than an actual "new" teleport command (although I like how it turned out because it gives you full control of where you want to "reappear"). In any case, you can't do it without some kind of coding, either adding to an existing mod or hacking something already there. IIRC, you can almost do it in JA++ now, but I don't remember if there was an actual playefx type of feature being added, or if it was only entspawn.

^ You got it. Use some light-emitting bmodels for the job. Note that clients need to have dynamic light enabled to see the difference (NOT dynamic glow). Also, IIRC the light generates from the origin value vice the bmodel position, which makes placement easier but occasionally means you have to consider various rendering limits like portals and whatnot because the entity rendering depends on the bmodel position itself.

Somehow this off-topic argument brought me out of lurk mode o.o... 1. Simplest way to make a toggle using entities (or otherwise) is to use a proxy func_door 2. Entity limit isn't an issue unless you know you're going to approach it... if you know your map will never use enough ents to get there, then there is some wisdom to NOT using scripts because it will introduce unnecessary modularizations (people with engineering degrees are allowed to make up words!) to your map content, which increases the risk of incompatibility or other issues and also makes development versioning a tad trickier to keep track of. 3. Effective scripting DOES make things easier, especially for large event sequences, and having mental access to the logical basis of scripting lets you think more efficiently and may increase development productivity... if you are intending to utilize such complexities to begin with. In other words, personal preference . inb4lock