kwenga

Ref_tags are not counted towards entity limit AFAIK. At least they don't show up when using /entitylist command, so it shouldn't be a problem using them instead of vectors. It's easier to rearrange stuff when using visible entities in the editor, instead of changing numbers in script everytime. ?

I've never had that problem until today. I wanted to save another 4 entities by deleting redundant target_scriptrunners and using "useScript" key instead. I had a simple script moving objects between ref tags, in specified order and with precise time intervals. For some reason, using "useScript" instead of target_scriptrunner messed up the order in which object had been moving prieviously. It is as you said, loop has somehow rearranged blocks here and there, for example moving "wait" line several blocks ahead, creating longer pause between moves and then speeding up other motions. Then, just to be sure I didn't do anything to my script or my ref tags, I placed target_scriptrunner once more and deleted "useScript" key from my entity. After that, whole thing works again, without any of previously mentioned issues. tl;dr target_scriptrunner ftw, "useScript" might be broken in some specific cases. Be aware of that issue and use target_scriptrunner when designing your scripts, swap for "useScript" at the end, when you're sure that everything works correctly.

I've used your script as a template and I've created very simple worldspawn timer, which would play a sound after each 15 seconds. By doing so I discovered that the source of my problems was the mod I was using. It seems that OJP for some reason won't recognise operators and treats "+1" just like "1". On basejka my counter worked flawlessly. Duh. It's disappointing, but I cannot change that without messing with source code of said modification, which would be an overkill at that point. I had to find a clever alternative to initial idea and so I did. Instead of using one global variable, I had to use four, acting as a 0-1 switches, for each turret. Without the ability to sum values on one variable, I made a whole structure of IFs and ELSEs. Here is the code, for future readers: //Generated by BehavEd loop ( -1 ) { if ( $get( FLOAT, "turret1count")$, $=$, $1$ ) { if ( $get( FLOAT, "turret2count")$, $=$, $1$ ) { if ( $get( FLOAT, "turret3count")$, $=$, $1$ ) { if ( $get( FLOAT, "turret4count")$, $=$, $1$ ) { affect ( "turret1", /*@AFFECT_TYPE*/ INSERT ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } affect ( "turret2", /*@AFFECT_TYPE*/ INSERT ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } affect ( "turret3", /*@AFFECT_TYPE*/ INSERT ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } affect ( "turret4", /*@AFFECT_TYPE*/ INSERT ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } set ( "turret1count", "0" ); set ( "turret2count", "0" ); set ( "turret3count", "0" ); set ( "turret4count", "0" ); } else ( ) { wait ( 3000.000 ); signal ( "endoftheloop" ); } } else ( ) { wait ( 3000.000 ); signal ( "endoftheloop" ); } } else ( ) { wait ( 3000.000 ); signal ( "endoftheloop" ); } } else ( ) { wait ( 3000.000 ); signal ( "endoftheloop" ); } waitsignal ( "endoftheloop" ); } It works in every possible order in which you disable turrets. When all four turrets are destroyed, script deactivates them and resets all variables back to 0. I've also added some "signal" and "waitsignal" lines for loop to end when everything is done. Thanks again NAB622 for your help. I've learned a few new aspects of coding during that little quest, that's for sure.

I'm using script_targetname and /developer 1 indeed helps a lot, fortunately I knew that before. I decided to ignore that issue with triggers and I'll use func_doors and geometry to physically separate triggers from players and block them that way. Everything would work right now if not for another issue - I wanted to use one global variable and operate it by adding value to it, step by step. I made a new variable, flagged is as a FLOAT, but for some reason it's ignoring math operators. Is this some kind of a bug, or am I doing something horribly wrong? definition of a variable, used with spawnScript //Generated by BehavEd declare ( /*@DECLARE_TYPE*/ FLOAT, "turret1count" ); set ( "turret1count", $0$ ); script used after deathScript, should add +1 to global variable //Generated by BehavEd set ( "turret1count", $+1$ );

Thanks, that's a lot of good info right here. Totally forgot about "usescript" key. I took some time to follow your advice and figured out how to make global variables and use deathScript to affect them. That part seems to be working good, but I failed at everything else. First, I spent hours to discover that affecting turrets with scripts unables them to be deactivated by func_door AFTER using a script. It just won't work, as long as there is a script affecting these turrets still running (even after passing that line of code which was connected to turrets). Next, I tried making a simplest possible trigger deactivator, using scripts, not entities. Failed again - don't know why, but it's not working. It is hard for me to decide if I'm more angry, frustrated, or just disappointed at the state of scripting in general. Too many strange quirks and unexplained dead-ends to call it even slightly useful... It blows my mind that logic gate made of jawas and func_door made more sense than this. I have a trigger using script posted below. It should affect other triggers, but it does not. Any ideas? flush ( ); affect ( "turrettrigger1", /*@AFFECT_TYPE*/ FLUSH ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } affect ( "turrettrigger2", /*@AFFECT_TYPE*/ FLUSH ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } affect ( "turrettrigger3", /*@AFFECT_TYPE*/ FLUSH ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); } affect ( "turrettrigger4", /*@AFFECT_TYPE*/ FLUSH ) { set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" ); }

Parm count stays even after turret is destroyed. I would have to reset it anyway, but I wanted to answer your question. I'll try to explain what we're dealing here with, if that would help. I have a room with 4 turrets. Each turret is deactivated and hidden behind func_door shutter. After activating trigger by "use" key, player will start one of 4 different scenarios. Each scenario differs in amount of turrets that would activate - option number 3 activates 3 turrets, option number 1 activates only 1 turret, etc. Upon activation, shutters will move, revealing turrets to a player, and activating those turrets. Turrets have to be defeated by saber deflect. When dying, turrets sends a signal to it's shutter, which closes. Signal also leads to another func_door entity, which deactivates turret and lets it respawn silently. After defeating all turrets activated by selected program, AND gate is set true and it opens a door leading out of that room. After leaving the room, whole thing resets and another player can face the challenge. Since I have a lot of combinations here (4 different programs and non specified order in which turrets can be destroyed), I had tu build AND gate manually. I made a slide with trigger on one end and npc spawner in the other. On that slide I put 4 different func_door, acting as barriers. When you activate i.e. program number 2, two of those barriers would move, blocking npc from reaching trigger. That provides a way to have multiple signals leading to the AND gate, which would work in every possible order, since NPC has to wait for every barrier to move to reach its target. Gate is being reset by another func_door, which kills npc shortly after reaching the trigger. As you probably know right now, whole thing generates a lot of entities (80 or so). It's working, but I was trying to achieve something more efficient by using scripts. I need to find a way for my script to register func_door moving or turret dying.

I'm trying to create a script which would wait for an input from normal entities (like func_door or anything with „target” parameter). I know that most scripts rely on something completely different – entities are adressing target_scriptrunner to start a script, script does what it does and it ends. The only input from standard entity in that scenario works as a starter, not as a variable somewhere in the middle of a script. In my case, I have a misc_turretg2 which can fire „target” after exploding and I want that event to be registered by script and counted. I know that I can approach that problem from different angle and not use scripts at all, but I want to reduce my entity count (multiple turrets, part of something bigger which would be optimised by scripts too). I've tried using parm key and it didn't work. I made an additional script, which would be fired by entity only to do one thing - raise parm value of that entity. My main script had an „If” which would check value of that parm in a loop, waiting for correct value. The problem was that using „affect” on same entity in two different scripts would result in stopping my loop. Therefore, parm had a correct value, but main script wouldn't register that, because it was stopped earlier. Icarus is poorly documented, so I would be grateful for any help or any examples of similar scripts. I can provide additional info or quote my scripts here, but this is a very broad question and exceeds way beyond that example. Tl;dr: Can normal entities affect currently running scripts?

@@Apprentice Yep, MAX_ORIGINAL_EDGES and MAX_EDGE_LINES are very similar, but after several tests (again, trial and error, so it took hours), I somehow found the real reason. MAX_EDGE_LINES error was connected to that limit of total unique edges, which is 65536 or so. I was wrong in my previous reply, when I counted total verts, which is not the cause of said error. Its the sum of two values from FixTJunctions stage - axial edge lines and non-axial edge lines. Hitting the total limit would result in MAX_EDGE_LINES. My error, which was MAX_ORIGINAL_EDGES seems to be the indicator of another limit - and I'm pretty sure that it is non-axial edge lines limit. Nearly every diagonal line will be counted to that value, and hitting total of 25874 or above that, will interrupt FixTJunctions stage. Ah, and other important thing - only textured surfaces (not caulk, hint, triggers etc.) will add to that values. As my whole map was a original - and tricky - idea, I had rooms which were rotated by default. I was sticking to the grid, building everything with 45 degree offset, cautiously and precisely - and It paid off, because there are no other bugs, everything runs smoothly. But that limit for diagonal lines, which is 1/3 of maximum value, kinda ruins it all. It seems that you should stick to the grid, building everything with squares and rectangles, if you want to make a huge map, not making the mistakes I did, by designing jk3 map in unorthodox way... Using shaders may be a good idea, but it would be really time consuming - and to be fair, I don't have that many rectangular ceilings and problems similar to that on your screenshot. But thanks anyway, especially for the shader bit, It might come in handy later, if everything else fails. @@Langerd As I said before, I build everything manually, without cutting, rescalling or rotating brushes. Everything is clean and smooth. Thank you both for your replies, this topic might pop up years later for someone with similar problem, and those answers will definetely add more light to this matter. For now, I'm busy, so I won't be experimenting with radiant for a while - what I did, just before I was interrupted with other stuff, was replacing many of diagonal brushes by ase objects. It saved me a lot of non-axial and axial edge lines and I think it is the way to go... as long as another error emerges from the darkness of q3map2.

Rotating brushes in Radiant often creates deformed shapes, with vertexes placed completely out of the grid, so I avoided that in all of my projects. If I had to rotate something, I would do it manually or by creating ASE, if really necessary. I also avoided brushes with too many sides, with cutting too complicated shapes into smaller brushes, with 3 or max 4 sides per brush, so that shouldn't be the case. I spent last night researching similar kind of stuff. Patches are not that bad in terms of original edges, which I will explain at the end of this reply. Spawnflags are mess. I'm only using spawnflags 4, which is for lightmapping ASE models. Since this error is connected to BSP stage, not VIS or light, it shouldn't affect it. If I had to make a model solid, I used simple brushes with clip texture. And yes, I saw both topics you've linked here, but none of them really gave me the answer I was looking for. Using the best method of fixing anything, which is "trial and error", I've managed to test several diffrent scenarios. Error occurs at --- FixTJunctions --- , which is calculated during BSP stage. Since most of what precisely happens during compilation is still black magic for me, I had to delete some brushes, just to reduce overall number to 9k. With reduced brushcount, compiler did its thing and produced bsp without an error. This is FixTJunctions part. Map WITHOUT patches and WITHOUT ASE models. --- FixTJunctions --- 18488 axial edge lines 21528 non-axial edge lines 0 degenerate edges 28650 verts added for T-junctions 143729 total verts 22346 naturally ordered 4524 rotated orders 1633 can't order 0 broken (degenerate) surfaces removedWith some solid numbers, I began adding and removing different fragments of the map, compiling and comparing numbers from logs. First, I added previously deleted patches. Map WITH patches, WITHOUT ASE models. --- FixTJunctions --- 18642 axial edge lines 21642 non-axial edge lines 0 degenerate edges 28742 verts added for T-junctions 143841 total verts 22377 naturally ordered 4488 rotated orders 1643 can't order 0 broken (degenerate) surfaces removedAs you can see, total verts count is higher, but not that much. It is even less than 1% of the whole value, and I'm talking about 30-40 patches added to the map, some of them, like pipes and cables, were complicated shapes. It seems that patches are affecting this stage minimally. Map WITH patches, WITH ASE models. --- FixTJunctions --- 18642 axial edge lines 21639 non-axial edge lines 0 degenerate edges 28742 verts added for T-junctions 143821 total verts 22327 naturally ordered 4535 rotated orders 1641 can't order 0 broken (degenerate) surfaces removedAgain, adding 450 models, both ASE and md3, had marginal effect on FixTJunctions stage (total verts count is even lower, lol). It all comes down to regular brushes, both structural and detail, which are responsible for that error. This might be a problem, because I wanted to add more sections to my project, making it into a regular, proper map. At this point, I need to make a decision - investing more time in sunken project won't be a good idea, and it is still possible to change few things, simplyfing whole map. There is also an idea to change some internal, non essential brushwork to ASE models, reducing brushcount to bare minimum, but that will obviously raise amount of models used in the map, which might be a problem - if not on the FixTJunctions stage, it might come out later, during different stages of compilation. The error also might return, when adding additional rooms, even with ASE models everywhere - I still need solid brushes, for walls and stuff... What do you think? What should I do? Ah, one more thing. As I said before, Atlantica is a curious example, with complicated geometry and high brushcount. Using source files, which were available on jkhub, I've tried to compile that map - and it ends up with an error, not same as mine, but also on the FixTJunctions stage. How is this possible? Maybe Szico used different compiler or has found a solution to fix or to get around that problem?

Hi everyone. After a long break, I started to experiment with Radiant once again, making some preparations for future projects and ideas. Long story short - I ended up with really complicated map, mainly in spirit of testing the limits of q3map2 engine. I was confident enough to keep on adding stuff, since brush count was still around 10k. I divided my experimental project into several .map files, so I could manage everything easier. Segments were optimized - detail and structural brushes were used, some .ASE objects were added in place of rotated and often broken brushwork, I also avoided patches and autoclipped models. I tested each .map file, looking for errors and stuff, so I made sure that those parts were made correctly. The problem showed up when I gathered all the parts together, into the single .map file. Previous experiments showed no issues, but as I tinkered with parts of the map, the amount of brushwork obviously increased. Preventively, I doubled some segments of the map, just to round up the potential number of brushes at the end of my project and compiled whole project today. At this point, the MAX_ORIGINAL_EDGES error comes up. The map is uncompilable, at nearly 10-11k brushes, with bunch of patches (but less than 50, and not very complicated, mostly bevels), 50+ ase and md3 models. No 'substract' or 'hollow' used, details mostly made of models, not dozens of small brushes. How is that even possible? There are other huge projects, where brushcount was way above that level, Atlantica may be the best example. How do you get rid of that problem? Is there any way to fix that issue, so I could continue with my work? Please let me know. An answer from @@Szico VII himself would be a blessing, or from anyone who had managed to avoid that error in the past. Happy holidays.

The error was a source of your problems (maybe not the only one, but still). I had that before, it looked exactly as you described. MAX_TW_VERTS will disrupt compiling, which results in skipping lighting stage. To avoid this, clean your map - make all non-essential brushes detail, use structural brushes for boxes, do everything as IrocJeff said.

As far as I know, You would have to make a new npc file. jedi_random.npc (assets1.pk3\ext_data\npcs\) has several models written in it, which makes that file different from other npc files. It's not difficult. Just copy random npc file, name it whatever-you-want, open it (use notepad or other txt editor), delete everything inside. You have a blank npc file. Open other files of your choice, copy whatever is inside them, paste it all to your blank file (don't mess up txt formating). Every time you use /npc spawn whatever-you-want, game should use one of your npcs. Remember to put your file back to assets1.pk3\ext_data\npcs, or create your own pk3 file with appropriate directory. EDIT: Or do what @@JaceSolarisVIII said.

You can also use func_door on your button/brush, select tickbox "force_activate" and give it timer, so It would return to its starting position after defined amount of time. Then, use "opentarget" key, so your bridge (another func_door) will move just after button reaches it's open (pressed) position. Simple solution.