Get The Latest Compile Tools

1246720

Comments

  • Grimm_SpectorGrimm_Spector Join Date: 2002-11-01 Member: 3309Posts: 562
    QUOTE (rebel without a pause @ Feb 14 2003, 05:17 AM)
    QUOTE (^Requiem^ @ Feb 11 2003, 05:24 AM)
    Flayra himself said in the updated map 1.1 thread that software mode is NOT Supported by NS (its obvious if you try to play it, and not one single person has complained since release on here, which shows you how many people use software mode)


    Okay, here's a complaint for you, then. People running software mode (like me) rant and rave in silence and just go to other mods that can run software mode. There are many of us lurking in the gutters under the city. confused.gif

    Back on topic:

    I downloaded the new tools and recompiled one of my maps. Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB, I've noticed NO reduction in r_speeds nor increase in fps, even after running opt_plns 1.2.

    Judging by how everyone rant and raves in this thread about this custom release of Zoners, I must be doing something wrong. (See attached batch file.) Any ideas? Does this custom tools only make a difference for machines running in non-software modes?

    Are you running in software? (sounds like that's what you said), if not, D3D or openGL???
    .:{Grimm Spector - the God of Death}:.
  • Grimm_SpectorGrimm_Spector Join Date: 2002-11-01 Member: 3309Posts: 562
    edited March 2003
    QUOTE (Axehandler @ Feb 8 2003, 03:29 AM)

    %'s are output from WorldCraft. to the bathfile. biggrin.gif  biggrin.gif

    Call the Bathfile instead of the tools. still setup the tools thou.

    have these for Param's in Wolrdcraft/hammer

    $path\$file $bspdir $file

    %1 = $path\$file
    %2 = $bspdir
    %3 = $file
    FileName : Compile-HLNS.Bat


    When I compile my testmap, I get this:

    CODE


    ** Executing...
    ** Command: Change Directory
    ** Parameters: "C:\SIERRA\Half-Life"


    ** Executing...
    ** Command: C:\PROGRA~1\VALVEH~1\tools\hlcsg.exe
    ** Parameters: "c:\program files\valve hammer editor\tools\start"


    ** Executing...
    ** Command: C:\PROGRA~1\VALVEH~1\tools\hlbsp.exe
    ** Parameters: "c:\program files\valve hammer editor\tools\start"


    ** Executing...
    ** Command: C:\PROGRA~1\VALVEH~1\tools\hlvis.exe
    ** Parameters: "c:\program files\valve hammer editor\tools\start"


    ** Executing...
    ** Command: C:\PROGRA~1\VALVEH~1\tools\hlrad.exe
    ** Parameters: "c:\program files\valve hammer editor\tools\start"


    That seems quite odd, since I SHOULD be seeing number tables and such for clipnodes and planes and what not come up....wth is wrong? confused.gif

    Worse when I call the above quoted batch...copied the exact same way as the original post...
    When I call your batch through expert mode like this: compile-HLNS.bat $path\$file $bspdir $file

    I get this:
    CODE

    ** Executing...
    ** Command: Change Directory
    ** Parameters: "C:\SIERRA\Half-Life"


    ** Executing...
    ** Command: C:\Program Files\Valve Hammer Editor\tools\compile_HLNS.bat
    ** Parameters: c:\PROGRA~1\VALVEH~1\tools\start C:\SIERRA\Half-Life\ns\maps start

    * Could not execute the command:
      C:\Program Files\Valve Hammer Editor\tools\compile_HLNS.bat  c:\PROGRA~1\VALVEH~1\tools\start C:\SIERRA\Half-Life\ns\maps start
    * Windows gave the error message:
      "Access is denied."


    ummm...help?? sad.gif

    EDIT: I messed up the code tags...
    .:{Grimm Spector - the God of Death}:.
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    edited March 2003
    QUOTE (Grimm Spector @ Mar 14 2003, 01:36 AM)
    Does this include the texture lights stuff from merl's versions??

    Yes, it's actually derived from the sourcecode of Merl's 1.7 build, so it has all of the features from Merl's last public release.

    I've sent in the sourcecode from all of my changes to Merl for possible inclusion in future versions of his releases.
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • WolfWingsWolfWings NS_Nancy Resurrectionist Join Date: 2002-11-02 Member: 4416Posts: 595
    This may sound like an odd request, Cagey. If it's not feasable for some reason, that's cool. But looking over the 'reason the bugs happen' post, the core reason Bug #2 occurs is that all planes of every brush are expanded, not just the 'inner' brushes.

    I.E. If the 'touching' faces weren't expanded, the problem wouldn't occur either, would it? And the 'correct clipping' would still nip off the too-large point off the end, unless I'm mis-understanding the mechanics?

    Internally, this wouldn't be any different from simply making the two brushes intersect so the faces causing the 'bug' were co-planar with already-existing faces, which would still be clipped correctly.

    So, I guess what I'm asking... would it be possible to make yet another compile-time option to, say, never expand a certain (possibly new) texture? Something akin to NULL but that also blocks the plane from being expanded to generate the clip-hull? Possibly BEVEL for a reason I'll explain.

    Best way I can see to implement it, would be to simply copy the original plane, and as a last step before actually generating the clipping hull use the bevel-textured face to 'bevel' the brush it's attached to, as a sort of post-process. This way, touching faces like the one that causes the bug would automatically work correctly, resulting in the behavior pictured in the attached image.
    user posted image
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    edited March 2003
    QUOTE (WolfWings @ Mar 17 2003, 05:27 PM)
    Best way I can see to implement it, would be to simply copy the original plane, and as a last step before actually generating the clipping hull use the bevel-textured face to 'bevel' the brush it's attached to, as a sort of post-process. This way, touching faces like the one that causes the bug would automatically work correctly, resulting in the behavior pictured in the attached image.

    It's probably simplest to initialize the face offset at zero on clip brush generation rather than use a post processing step, since the clip brushes are generated in a different program than the hulls--BSP doesn't read map brushes, so any referencing must be done in CSG.

    No ETA on a BEVEL texture, but it seems like a viable improvement and I'll see what I can do--I'm currently working on another project to benefit mappers that is NS-specific and will hopefully reach completion this month.



    Removing the offset from touching faces is actually something that I thought about automating when I was brainstorming about possible ways to address bug #2... my thoughts on the technique follow:

    The reason I chose denormalization instead of conditional offsetting is the case where faces touch but one extends farther than the other (see image) -- when this happens, multiple clip brushes must be created (one on each side of the face relative to each edge, for a minimum of N+2 clip brushes, where N is the number of edges on touching brush faces which would cut the other brush if extended), which was more complexity than I wanted to tackle in the initial update. The second part of the image shows the correction using multiple clip brushes in a simple case.

    Even more complexity is added to the clip brush splitting when more than two brushes share a touching face or when two brushes don't truly share an edge but should have mutual clipping anyway (e.g. furnature or boxes 1 unit from the floor and 1 unit apart to prevent extra cuts in faces and drop r_speeds, or bushes that overlap but have a common exterior edge anyway). The extra faces also exist when multiple brush entities share a corner... since they aren't going to be part of the same entity hull, they won't be detected when processing (I could do cross-detection of brushes on immobile entities like func_walls, but that's yet another level of complexity added. Cross detection on mobile entities would be self-defeating since the common corners wouldn't always be common while one object is moving relative to another).

    If a mapper can pick and choose which faces to use when ignoring clip offsets, I'm less worried about the consequences of the first image below, and the problems noted in the previous paragraph are no longer the tools' responsibility. I like the idea of using a texture to manually determine where to do this, and I'll think about implementing it. It would mean changes to CSG (new bevel behavior) and BSP (to remove the bevel texture if it's still exposed in the final visible hull, treating it like the NULL texture).

    I chose denormalization as the original solution because it addresses all of the above cases (by making each face offset from vis edges uniform at clip edges regardless of face normal) without being computationally expensive (it actually skips a step, speeding up the overall process. Denormalization is a misnomer--I simply don't project the calculated offset onto the face normal in the first place) or requiring work by the mapper--the smaller clip hull widths are the penalty for the simplicity of the solution.

    Keep the ideas coming smile.gif
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • WolfWingsWolfWings NS_Nancy Resurrectionist Join Date: 2002-11-02 Member: 4416Posts: 595
    QUOTE (XP-Cagey @ Mar 17 2003, 11:54 PM)
    Keep the ideas coming smile.gif

    Well I'd mention the obvious one of removing the need for those two .DLL files, but that would require someone else compiling the code. :-) If that'd help any, I'm game since I've got a pretty good set of compilers on my system and I can probably get the code compiling with them. I'll dig through Merl's code and see about getting that compiling in the mean-time.
    user posted image
  • A_WseM4n_0nc3_SadA_WseM4n_0nc3_Sad Join Date: 2003-04-04 Member: 15179Posts: 6
    Is there any way you could increase the number of brushes that can be added to a map?
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    QUOTE (A_W!seM4n_0nc3_Sa!d @ Apr 3 2003, 10:12 PM)
    Is there any way you could increase the number of brushes that can be added to a map?

    Sure. It'll be up to 32K (from 8K) in the next release. That should be high enough that you'll hit other limits before running out of brushes. I just tested WC, and it appears to be OK (but slow) running with 24K brushes, so I don't see why the tools shouldn't support higher amounts as well.

    This is a safe limit to increase, by the way, because only CSG actually uses brushes for processing, and there really isn't a logical limit on the total brushes that CSG can handle.
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • A_WseM4n_0nc3_SadA_WseM4n_0nc3_Sad Join Date: 2003-04-04 Member: 15179Posts: 6
    W00T! Thanks dude! I can't really decribe in words how thankful i am biggrin.gif
  • DelarosaDelarosa Naturally Custom Join Date: 2002-11-29 Member: 10214Posts: 4,759
    ok, i understand how to set up the files into the hammer compiler, but with interfacing with batch compiler....

    what exactally does one do with the opt_plns.exe?

    (maybe a tutorial on what you do with it once you D/L could be on your site?)
    NS Custom models, might just be back...
  • A_WseM4n_0nc3_SadA_WseM4n_0nc3_Sad Join Date: 2003-04-04 Member: 15179Posts: 6
    All you do is drop your compiled .BSP onto the opt_plns.exe, or you make it the last task in your batch compile, i think.
  • A_WseM4n_0nc3_SadA_WseM4n_0nc3_Sad Join Date: 2003-04-04 Member: 15179Posts: 6
    Oh yeah, i hope i'm not asking to much, but could you increase the limit on the number of planes again? It would be most appreciated smile.gif
  • XP-KiljoyXP-Kiljoy Join Date: 2003-04-02 Member: 15147Posts: 1
    Cagey is my Hero! tounge.gif




    XP-Kiljoy
    Xtreme Prejudice
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    QUOTE (A_W!seM4n_0nc3_Sa!d @ Apr 4 2003, 12:52 PM)
    Oh yeah, i hope i'm not asking to much, but could you increase the limit on the number of planes again? It would be most appreciated  smile.gif

    Unfortunately, I'll need to change the method HLBSP uses to write face information (and the way that VIS and RAD read it in) before I up the limit again. I originally thought I could up it an arbitrary amount, but the BSP version 30 file format (HL's version of BSP) stores the plane number used by each face as a 16 bit number, meaning the maximum range is 0-65535... I can't change the BSP format without breaking Half-Life compatibility.

    It's definitely possible to store the faces outside the BSP until after the optimizer has lowered the total plane count to get around the problem, but it's not a simple change. I'll look into it, but I'm predicting it won't be in the next release. The optimizer would have to read the extended face list and put it back into the BSP file after the plane count was lowered.

    I'd eventually like to have a toolset without any practical internal limits during processing -- memory management would need to change first to dynamically allocate space as needed, and the tools would have to abandon the BSP format and use a ToolFormat->BSP converter (which is what the optimizer would become) as the last step. Those are pretty major changes, and I'm currently looking at the pros and cons of that sort of approach before I commit to it.

    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • A_WseM4n_0nc3_SadA_WseM4n_0nc3_Sad Join Date: 2003-04-04 Member: 15179Posts: 6
    Ok, no biggie, but, again, Thanks for taking the time to increase the brush limit... I hope i'm not pushing this, but do you know when you'll have the next release out with the higher brush limit in it?
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    QUOTE (A_W!seM4n_0nc3_Sa!d @ Apr 4 2003, 07:56 PM)
    Ok, no biggie, but, again, Thanks for taking the time to increase the brush limit... I hope i'm not pushing this, but do you know when you'll have the next release out with the higher brush limit in it?

    I'm shooting for Wednesday the 9th.
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • rebel_without_a_pauserebel_without_a_pause Join Date: 2003-02-11 Member: 13420Posts: 3
    edited April 2003
    QUOTE (Grimm Spector @ Mar 14 2003, 12:11 PM)
    Are you running in software? (sounds like that's what you said), if not, D3D or openGL???

    Software, yes. Unfortunately laptops can't be upgraded with a nice video accelerator. sad.gif

    I found that Direct3D kind of works as well, but the differences between water (Software vs Direct3D) is so radical that I'm wondering if my video card isn't maybe a bit sick.
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    edited May 2003
    I'm releasing 1.7p5:

    Feature addition: "zhlt_noclip" - adding this key with a non-empty value to any brush entity will cause ALL clipping information for the brush entity to be stripped, making the entity non-solid in the game. Useful for nonsolid func_wall_toggles, func_buttons, etc. Suggested by Yamazaki.
    Feature addition: "zhlt_invisible" - adding this key with a non-empty value to any brush entity will cause the entity to be invisible in the game and not contribute to r_speeds (this is the same as using the null texture for the entire entity). In addition, there is a new command line option, -nullfile, that automatically reads a list of brush object types (specified by classname or targetname) from a file and turns them invisible without needing to specify the key in each entity.
    Feature addition: BEVEL texture - this texture acts like a NULL texture but also doesn't expand when generating clip hulls. Can be used to eliminate exterior corner clipping bugs without using -cliptype precise... -cliptype precise is still the recommended method for removing clipping errors, as this feature is experimental. Suggested by WolfWings -- see page 7 of this topic for discussion.
    Compiler limit change: MAX_MAP_BRUSHES from 8K to 32K. Suggested by A W!seM4n Onc3 Sa!d.
    Compiler limit change: ripents.exe has been updated to support the higher map limits of 1.7p5.
    Optimization: several math functions have been simplified in the code, providing a small boost to HLRAD speeds. Testing showed a ~5% improvement on compiles that weren't using virtual memory. Larger gains are probably possible in the future.
    Optimization: enabled MSVC++ compiler optimizations for speed. Your milage may vary.

    Additional files in the new distribution:
    ripents.exe has been updated to support the 1.7p5 limits.
    zhlt.wad has been updated to include the BEVEL texture.

    Grab the updated tools from this post and the next one. I'd recommend regrabbing all of the tools.

    EDIT: dyslexic moment, sorry Yama smile.gif

    EDIT: bumped to version 1.7p6 - Bugfix (CSG): BEVEL texture code was causing improper clip offsets for normally textured axial faces.

    EDIT: bumped to version 1.7p7 - Bugfix (RAD): texlight handling was removed from p5, p6 during debugging, it's back in now and I've fixed the spam of "too many direct lightstyles" on some maps -- the error now only is written on the first occurance (since it doesn't give the location, additional reports are redundant). This is a stable release, and I probably won't update again for several weeks.

    EDIT: bumped to version 1.7p8 - Bugfix (RAD): added -oldmath switch to HLRAD for those who are having problems with versions of HLRAD after 1.7p4

    EDIT: bumped to version 1.7p9 -
    Bugfix (RAD): fixed problem with newer math routines
    Feature Addition (patch by Nemo1024, CSG): added backward compatability with SDK 2.2 hull file format; change doesn't affect mods using the current format.

    EDIT: bumped to version 1.7p10 -
    Bugfix (RAD): fixed remaining problems with newer math routines and opaque entity shadows.
    Post edited by Unknown User on
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    edited May 2003
    And part two of the DL (since the maximum attachment size is 122880 bytes).
    Post edited by Unknown User on
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • BedwettingTypeBedwettingType Join Date: 2002-07-26 Member: 1001Posts: 315
    Thank you so much, Cagey, I can't tell you how cool this is. =D
    - Guns don't kill people, trigger_hurt's kill people.
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    edited April 2003
    Grr... packaged the wrong version in the download links for the latest version sad.gif

    If you see version 1.7p2 instead of 1.7p5 at the top when you try to run any of the tools, please grab the zip files again -- the 1.7p2 build is an old broken copy of the tools.

    EDIT: and the correct version of 1.7p5 was still having a problem related to the new BEVEL texture code... updated to release 1.7p6, which fixes the bug.

    EDIT: added texlight support back in and incremented to 1.7p7
    Post edited by Unknown User on
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • OlljOllj our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Posts: 3,844
    What does ripent do?
    deleting entities from he void (thoose with mots around them?).
    And how to use it correctly?
    "What are we going to do tonight, Brain?"
    "The same thing we do every night, Pinky, trying to launch Steam."

    I like:
    user posted image
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    QUOTE (Ollj @ Apr 13 2003, 03:08 PM)
    What does ripent do?
    deleting entities from he void (thoose with mots around them?).
    And how to use it correctly?

    Ripent allows you to import and export entites from a BSP to a .map-like plain text format... it's part of zoner's original toolset, so if you google it you should get some instruction pages on its use. I hadn't included it before because the Merl's 1.7 sourcecode version doesn't compile without a few fixes.

    Its a way to update entities without going through the process of CSG -onlyents, and it can allow you to see what settings people used on their entities (although Quark's BSP viewer is probably still the better tool for this).

    The only difference between the version of ripent that's included here and the stock version is the updates to the compiler limits (higher planes allowed, etc).
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • OlljOllj our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Posts: 3,844
    Now I could need an .fgd that includes
    - ZHLT lightflags (blocks light ...)
    - ZHLT flickering and toggleable texture lihghts.
    - NS specific entities with as less bugs and "...has unused keyvalues" as possible.
    - XP-Cageys p7 compile tool Flags.
    - Sorted entities (NS specific on top of list)
    "What are we going to do tonight, Brain?"
    "The same thing we do every night, Pinky, trying to launch Steam."

    I like:
    user posted image
  • OlljOllj our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Posts: 3,844
    edited April 2003
    QUOTE

    ......
    hlrad v2.5.3 rel Custom Build 1.7p7 (Apr 13 2003)
    Zoner's Half-Life Compilation Tools -- Custom Build
    Based on code modifications by Sean 'Zoner' Cavanaugh
    Based on Valve's version, modified with permission.
    Submit detailed bug reports to (webmaster@xp-cagey.com)

      BEGIN  hlrad

    Command line: C:\PROGRA~1\BATCHC~1\HLRAD.EXE -extra -sparse -bounce 4 -smooth 80 -chop 64 -texchop 32 -lights complexlig.rad -chart -estimate -noinfo -low "F:\mapedit\- Maps\selfmade\compile.map"
    [Reading texlights from 'complexlig.rad']
    [5 texlights parsed from 'complexlig.rad']

    13247 faces
    Create Patches : 68692 base patches
    81 opaque faces
    1350262 square feet [194437776.00 square inches]
    1706 direct lights

    BuildFacelights:
    (7481.79 seconds)
    BuildVisLeafs:
    (2014.72 seconds)
    visibility matrix  :  7.8 megs
    MakeScales:
    (1596.85 seconds)
    SwapTransfers:
    (39.11 seconds)
    Transfer Lists :    15524806 :  15.52M transfers
          Indices :    12609460 :  12.03M bytes
              Data :    62099224 :  59.22M bytes
    GatherLight:
    (30.70 seconds)
    GatherLight:
    (26.53 seconds)
    GatherLight:
    (27.36 seconds)
    GatherLight:
    (32.52 seconds)
    FinalLightFace:
    (20.65 seconds)

    Object names  Objects/Maxobjs  Memory / Maxmem  Fullness

     
     
     

    models            157/400        10048/25600    (39.3%)
    planes          42616/65535    852320/1310700  (65.0%)
    vertexes        16124/65535    193488/786420  (24.6%)
    nodes            8909/32767    213816/786408  (27.2%)
    texinfos        6902/32767    276080/1310680  (21.1%)
    faces          13247/65535    264940/1310700  (20.2%)
    clipnodes      30483/32767    243864/262136  (93.0%)
    leaves          4745/8192      132860/229376  (57.9%)
    marksurfaces    16669/65535      33338/131070  (25.4%)
    surfedges      59343/512000    237372/2048000  (11.6%)
    edges          30404/256000    121616/1024000  (11.9%)
    texdata          [variable]      5372/4194304  ( 0.1%)
    lightdata        [variable]    1505529/6291456  (23.9%)
    visdata          [variable]    220794/2097152  (10.5%)
    entdata          [variable]      37058/524288  ( 7.1%)
    122 textures referenced
    === Total BSP file data space used: 4348495 bytes ===
    11298.84 seconds elapsed [3h 8m 18s]


      END  hlrad



    Since I changed from 1.0p4 to 1.7p7 i get this strange light error making my map much more pitch black.
    In this hall are just 1-2 point light entities (used almost all over the map) but instead of making round lights they make it straight along konkarve corners most times or straight light stripes along a long hallway.
    In most other places the ceeling has 2 times as much light while the bottom is pitch black.
    If a few places the light is absolutely correct.
    Some texture lights seem not to cast light anywere.

    Apart from leaf portal saw into leafes i got no errors in the compile log.
    I fixed a few leaf portal saw into leafes and recompiled, getting other leaf portal saw into leafes but still the same light errors.
    "What are we going to do tonight, Brain?"
    "The same thing we do every night, Pinky, trying to launch Steam."

    I like:
    user posted image
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    edited April 2003
    QUOTE (Ollj @ Apr 17 2003, 08:59 AM)
    If a few places the light is absolutely correct.
    Some texture lights seem not to cast light anywere.

    It's probably the changes I made to optimize the math functions in HLRAD -- I'm going to add a command line switch to use the older, slower math functions for now while I try to get a sample case that exhibits the change. I'll have the new version of HLRAD with the switch available in an hour or so unless there's an unforseen delay.

    My own full maps light correctly with the new code, so I'll need to find a bad case before I can do some troubleshooting. If you could PM me a single hallway that has the problem, it'd probably make the debug go much more quickly; I'd rather not have a full map to debug since lighting is such a time consuming process.

    Sorry about the problem sad.gif

    EDIT: took a little longer than expected, I'm testing the update now.
    Post edited by Unknown User on
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • CageyCagey Ex-Unknown Worlds Programmer Join Date: 2002-11-15 Member: 8829Posts: 1,751
    I've posted the updated HLRAD which has a new command line switch, "-oldmath". If you use -oldmath with HLRAD, the older unoptimized math functions are used for BuildFaceLights, which should cause the lighting to appear like it did in 1.7p4. Once I get a sample case of a broken light, I'll work to mimic the old functions more closely. I haven't been able to find a point where the functional results differ by inspection, so I'll need a sample case to proceed. Once I have the new functions mimicking the old math accurately, I'll remove the -oldmath switch, speeding HLRAD back up a little.

    If you've downloaded 1.7p7, you only really need to grab 1.7p8_B.zip from the two attachments above, since HLRAD is the only program that has changed between releases. If you haven't had any problems with the p7 RAD, you don't need to upgrade to p8.

    I've decided that I'm going to work on getting a true support network for the tools in place with an update mailing list, formalized open beta testing periods for each release, public bug tracking, and a message board for discussion and suggestions. All of the above should be available from my homepage one item at a time as I complete the necessary work in the background--I'll also see about getting a unified tool download from my site so there won't be any more of this multiple zipfile nonsense. smile.gif
    XP-Cagey

    Recommended Reading: NS Mapping Guidelines | Mapping Forum FAQ
    Nostalgia: Power Cells Thread
  • OlljOllj our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Posts: 3,844
    Jeah thats much better.
    Backwards compartibility and disabling toggles of new features are essential.
    "What are we going to do tonight, Brain?"
    "The same thing we do every night, Pinky, trying to launch Steam."

    I like:
    user posted image
  • taledentaleden Join Date: 2003-04-06 Member: 15252Posts: 254
    Have you considered using sourceforge to handle the logistics of bugtracking/forums/releases etc? I'm not sure if you want to classify your stuff 'open source', but I imagine the source for somebody's version of these tools is available somewhere, so it's just a question of how you feel about your version of the source. IMHO, open source is always better if you're not trying to make money from it anyway. smile.gif
  • taledentaleden Join Date: 2003-04-06 Member: 15252Posts: 254
    Also, Ollj: looking at those screenshots, it looks to me like the light falloff value is too high - the corners right next to the lights are lit, but the light fades away to black too fast and the rest of the corridor (ceiling and floor) don't get any of it. I think there's a switch to specify the distance at which lights fade away.. maybe until Cagey figures out the algorithmic difference you could use that to work around the problem?
Sign In or Register to comment.