Jump to content

kwenga

Members
  • Content Count

    30
  • Joined

  • Last visited

Profile Information

  • Modding Interests
    Mapper
  • Gaming Specialty
    Dueling

Recent Profile Visitors

738 profile views
  1. @@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.
  2. 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?
  3. 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.
  4. 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.
  5. 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.
  6. 750 downloads

    Release Date: 18.11.2016 Filesize: ~12MB Story background: As invasion moves forward, Sith forces had managed to break thin line of Alliance defenses and are directly threating Dac system. Small strike team from local garrison slipped through enemy's security systems. Few Jedi Knights are trying to reach bridge deck, before invasion starts. Eliminating Sith leader just in time might save whole planet from total annihilation... Description: Play as a Jedi (BLUE team) or Sith forces (RED team) on this TFFA map. The fate and the result of this extremely important clash is in your hands. Map was designed for saber dueling and epic cinematics. It has several breakable objects (mostly glass and some cables), traps (huge heat radiators may harm or even kill you) and powerful trigger on the bridge, which completely changes whole room after activating (use your lightsaber or force push to activate it). This is my second map, it was meant to be small and full of lights/effects, but it has developed to be a little bit larger. Although I've added FFA and DUEL gametypes, I would strongly suggest using TFFA gametype, just for the "story" purposes. I placed spawnpoints in distant areas, so fight should occur in the middle section, and later move on the bridge itself. I wouldn't recommend fighting in BLUE team spawn area though. Lastly, I would like to give an advice for current or future mappers. This map was meant to be a short project, but it somehow took me extra months to finish. I've learned a lot during that time, made many changes to initial idea and, for sure, as many mistakes. I wasn't really keen to rush this map, but it started to delay me from different projects. It shows the neccesity of planning everything before you start building it in Radiant. You will save yourself a lot of precious time. Also, check out my previous project: Yavin 4 Riverside Instructions: Put pk3 file to your gamedata/base directory. Choose map from in-game menu (TFFA, Duel, Power Duel, FFA modes) or open your console and type /devmap siege_of_dac Known bugs: If you're having problems with performance (low fps, etc.) turn off dynamic glow. Explosion effects at the bridge sometimes won't play after restarting map and on modded servers. Dunno why. Map will work corectly on base jk3, but more advanced mods/overhauls might override effects. Copyright/License: Feel free to download and play. If you want something different, such as reuploading to different sites than jkhub, contact me here (@kwenga). I do not claim any rights to music/soundtrack. Full credits to original creators and author of the remix.
  7. 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.
  8. Thanks for all your comments, I really appreciate it! Ants. Yep, ants. Don't step into ant-hill. There might be more of them across whole map. That's major flaw for me too. Tried to fix that by cutting culldistance as much as I could, but it's mostly because of rocks and all those trees, plus grass. I think I could gain few more fps, but it would require much time, which unfortunately I don't have. Might upload source file one day, maybe someone would be brave enough to go through all of that. Next map will be much, much smaller. Soontm.
  9. Version 1.0

    1,118 downloads

    Filesize: ~7,2MB Description: This is my first fully-developed (riiiight...) map. It was created for roleplaying or cinematic purposes, so it's basically focused on terrain design. I was trying to capture that specific "Yavin 4" mood, with lots of rain, moisture and greenery. It has a very dense flora, which surrounds muddy paths sculpted by water. Terrain was generated using Easygen, after that I've manually added mountain pass and flat terrain on the other side of the river - which might look like natural transitions to other maps of your choice. As I said, map was designed for roleplaying, so there isn't much to do, unless... FFA! Because of that, I recently added several spawnpoints, so now you may use it as a harsh environment for jungle combat. Trees and bushes will provide extra cover, and potentially may help you ambush poor souls beneath you. Unfortunately, map has several flaws - it could be more optimized, but I simply cannot pour more time into it, so I am releasing it as it is. Sorry! Huge thanks to @Thrust for all that stupid questions he had to answer... and he did it flawlessly. Without his support, this map couldn't be completed. Also, shoutout to all my friends from yavin4.pl, for their unaware beta-testing and opportunity to release this map as a part of our mappack. Enjoy! Instructions: Put pk3 file to your gamedata/base directory. Choose map from in-game menu (FFA mode) or open your console and type /devmap y4_riverside Copyright/License: Feel free to download and play. If you want something different, such as reuploading to different sites than jkhub, contact me there (@kwenga).
  10. Also, you can use q3map_tcGen ivector. You have it under terrain_base section, which btw should be at the top of your .shader file- it could be the reason of your problem! Then, you can change ivector values. Instead of 512, put 256 or 1024 - one of those two should enlarge texture scale, I cannot remember right now. If you still have any questions, ask here or on the messenger. I know a thing or two about struggling with easygen.
  11. Guys, I know a little bit about creating terrain, because it's not first map I'm making. Thanks for your advices, but I'm interested in finding solution for this perticular problem. Btw, making terrain with patches isn't the best idea, if you're aiming for huge maps, in terms of performance and general efficiency. Even converting them to .ASE won't beat good ol' brushes.
  12. Hello jkhub, I was wondering if there is a good, reliable method for aligning textures on certain brushes. Basically, I'm trying to make a good looking terrain, but texturing brushes is very time consuming at this point. I'll show you an example. As you can see, I've created a basic shape for my terrain, but textures are rotated by 90 degree or even mirrored. I was wondering if there is any other method to fix that, apart from doing it by surface inspector. You know, setting default alignment for all brushes or something like that? It would be really frustrating, tweaking with surface inspector all the time, when I have, lets say, 3k of those shapes.
  13. I'm not sure if it's even possible, since your terrain is covered by huuuuge shader. It's not "printed" on perticular triangles, it's more reference to .prt or .srf file (cannot remember right now, basically it's not in the Radiant itself). My advice - use some sort of references. For example - place some posts or blocks on your map in even distances between eachother. Compile your map, use high cull distance, take screenshot from far distance and use it as your major reference. Or just leave your game running, minimize it and check it when needed. Kinda sloppy method, but I can't see any alternatives. Edit: Lol, I was joking about that title. Ok, let it be ultrathread then! We should feel superior.
×
×
  • Create New...