Thread: [ARCHIVE] Custom ZHLT by vluzacn

Page 15 of 33 FirstFirst ... 511121314151617181925 ... LastLast
Results 351 to 375 of 825
  1. #351
    Ultimate Monster Mapper amckern's Avatar  
    Programmer
    Join Date
    Feb 2002
    Location
    Sydney, Australia
    Posts
    1,282

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by wolf-3d View Post
    Have 6 errors at present - Only 2 are showing problems. One brush (Solid with 10 faces aligned to Face where needed) is see-thro at floor level. Near a different "brush in pairedge error" (Solid with 3 faces all aligned "to Face", i.e. rotated Wedge shape) the two adjoinng brushes are see-thro & non-solid in one direction, the error brush itself appears okay.
    see through would relate more to leaf saw errors then adjoining errors - it sounds like some of your brushes are not aligned to the grid correctly - did you do a map>check for errors and fix them all?
    SC Kicks ass!

    My Maps - SC_28, SC_AVP, SC_AVP10, SC_Duno, SC_Max, Opposing Forts, SC_Massive, SC_Oni
    My Web Sites - AMMAHLS

  2. #352
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,457

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by amckern View Post
    see through would relate more to leaf saw errors then adjoining errors - it sounds like some of your brushes are not aligned to the grid correctly - did you do a map>check for errors and fix them all?
    Thanks amckern, - I am not getting any "Leaf saw / into plane" errors but I have noticed doing the Alt-P, has *in the past* fixed errors, only to find on the next compile "a line across grid [solid 1 face]" appears, which needs to be marked and deleted as this kills the "compile" process.

    Your comment "sounds like some of your brushes are not aligned to the grid correctly" is correct (and I am guessing the probable cause), I am carving and then vertex manipulating and some times rotating (Ctrl-M) after that.

    I will see if I can find any vertex points that have slipped off "grid alignment" in my problem brushes. Thanks for the tips.

    Regards
    Wolf-3D

  3. #353
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,556

    Re: custom version of ZHLT by vluzacn

    Oh god avoid the carve tool at all costs... It is complete rubbish. Does more damage than good.
    It'll take longer but use vertex manipulation and sometimes clipping.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  4. #354
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,457

    Re: custom version of ZHLT by vluzacn

    Arrghh - My bad, I should have said clipping (Shift X) and not carving tool. - Appologies for the inablity to say what I mean.

  5. #355
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Vluzacn, could you please change the model limit to 512 for the next version?
    Sure.
    Also the new func_detail may help save some model slots.

    Update:
    Warning: internal error 1 in PairEdges
    Warning: internal error 3 in PairEdges

    If you know the offending object, this may work:

    I set the grid to 1 unit, managed to copy the arch to a test map and (on the 2nd paste attempt) got a clean compile. Deleted & Pasted back to original map. PairEdge Errors have gone.

    regards
    Wolf-3D
    I know an issue of Hammer which might be related. If you use "smart copy", all vertexes will be snapped to the 1 unit grid.
    Also this warning is not a serious problem (and in the next version I will stop using the word "internal error" for this warning).


    Feature (and possible bug fix) request:

    512 textures pre-HLBSP
    503 textures post-HLBSP

    Looks like there are 9 textures being stripped. Any chance textures due to be stripped out could NOT be included in the 512 limit? That means I would be able to use 9 more textures before hitting MAX_MAP_TEXTURES.
    I have found out that map runs fine even with 2048 textures, and I have no idea where the number 512 is from after inspecting the code of HLSDK and Quake 2.
    So I'm considering changing that limit to 4096.


    What do you think about a texture to block light, just like the one in source?
    You can just use the BLACK texture and make all these brushes an func_wall_toggle with 'opaque' and 'start off' and scale the texture up so that it won't consume much 'AllockBlock's and hlrad's 'patch'es.


    Hello again!
    Thanks for responding vluzacn, helped me a lot!
    But I have other problem, how do I get the light should not be influenced by the texture color? You said this was the last update:

    Quote:
    Now light bouncing and texture light are influenced by texture color.

    See this image:

    The ambience is very bluish and I wasn't wanting this :S
    Do you mean it's too blue? What are your light_environment's settings?


    Another question vluzacn, you're still working on your compilers or that is a final version?
    Sorry for not having the update posted here, because I'm a little bit busy at the time. Actually I have finished the the update a month ago. I will post it within a couple of days.



    Internal Error in PairEdges.

    Anyone have some insight as to how/why these are created AND if they can be fixed without "delete and recreate" or "cut and paste several times into test map".
    I am building a mine/cave like area and getting quite a few.

    Some PairEdge errors cause problems (act like func_illusionary, see/walk thro from specific angles) and some brushes "in PairEdge error" appear to be unaffected. All of the brushes in question are "Solid World Brushes"

    Compile log with -dev 2 (EDIT: one such error) shows:
    AddFaceForVertexNormal - bad face:
    edgeabs=36135 edgeend=1
    e=36132 v0=20962(-2359.269287,684.730652,-464.213654) v1=20963(-2388.000000,684.837036,-487.000000) share0=15035 share1=15067
    e=36133 v0=20963(-2388.000000,684.837036,-487.000000) v1=20964(-2388.281982,684.838074,-486.863922) share0=15035 share1=15037
    e=36134 v0=20964(-2388.281982,684.838074,-486.863922) v1=20962(-2359.269287,684.730652,-464.213654) share0=15035 share1=15068
    e=36135 v0=20962(-2359.269287,684.730652,-464.213654) v1=20965(-2359.000000,684.729614,-464.000000) share0=15035 share1=15035
    e=-36135 v0=20962(-2359.269287,684.730652,-464.213654) v1=20965(-2359.000000,684.729614,-464.000000) share0=15035 share1=15035
    Warning: internal error 1 in PairEdges
    Warning: internal error 3 in PairEdges

    Have 6 errors at present - Only 2 are showing problems. One brush (Solid with 10 faces aligned to Face where needed) is see-thro at floor level. Near a different "brush in pairedge error" (Solid with 3 faces all aligned "to Face", i.e. rotated Wedge shape) the two adjoinng brushes are see-thro & non-solid in one direction, the error brush itself appears okay.

    regards
    Wolf-3d
    I believe the cause is similar to the cause of 'mixed face contents'. It is expected to be solved by converting the cave wall to func_detail.
    Aren't there any 'mixed face contents' problems?

  6. #356
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,556

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by vluzacn View Post
    I have found out that map runs fine even with 2048 textures, and I have no idea where the number 512 is from after inspecting the code of HLSDK and Quake 2.
    So I'm considering changing that limit to 4096.
    Oh wow! Going to change that in my build now.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  7. #357
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,457

    Re: custom version of ZHLT by vluzacn

    I believe the cause is similar to the cause of 'mixed face contents'. It is expected to be solved by converting the cave wall to func_detail.
    Aren't there any 'mixed face contents' problems?
    Correct - Converting to func_detail has removed the Warning messages and the 2 problem walls are no-longer see-through.

    Yes - Have mixed face contents. Had them since inital stages of map development when I put in some cliffs near the map edge (which is a sky box but as far as I can tell they are not touching).

    Anyway I am on-track again, many thanks for the mixed face solution.

    regards
    Wolf-3D

  8. #358
    Registered User
    Join Date
    Sep 2011
    Location
    Brazil
    Posts
    15

    Re: custom version of ZHLT by vluzacn

    vluzacn, the configuration that light_environment was this:

    • YAW: 330
    • PITCH: -25
    • BRIGHTNESS: 48 64 96 200


    I got another example of the problem I'm having, look the pictures:

    In this picture the color of the ambient seems normal, great!


    But that image, the ambient is visibly red and it doesn't match with the sunlight


    Informations of this light_environment:

    • YAW: 330
    • PITCH: -20
    • BRIGHTNESS: 104 96 88 200


    I wished to remove that option of the light being influenced by texture, is there any way?

  9. #359
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,556

    Re: custom version of ZHLT by vluzacn

    I think that looks very good Implies a light film of red desert dust.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  10. #360
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by Truck View Post
    vluzacn, the configuration that light_environment was this:

    • YAW: 330
    • PITCH: -25
    • BRIGHTNESS: 48 64 96 200

    That's it. Your sun is blue. If you want a blue sky but a white sun, try to change the value of 'sky color and brightness' in light_environment's property.

    Quote Originally Posted by Truck View Post
    I got another example of the problem I'm having, look the pictures:

    In this picture the color of the ambient seems normal, great!

    But that image, the ambient is visibly red and it doesn't match with the sunlight

    Informations of this light_environment:

    • YAW: 330
    • PITCH: -20
    • BRIGHTNESS: 104 96 88 200


    I wished to remove that option of the light being influenced by texture, is there any way?
    The de_dust's texture set is quite bright, so the textures should have lower reflectivity ratios than the reflectivity ratios directly calculated from their color.
    To solve the problem, you could add parameter '-texreflectscale 0.5' (say, lower to 0.5) to hlrad. Also I suggest to reduce the brightness of light_environment to no more than 100 (on the presumption that you have left the '-scale' parameter unchanged) in order to get the most realistic result.

  11. #361
    Registered User
    Join Date
    Sep 2011
    Location
    Brazil
    Posts
    15

    Re: custom version of ZHLT by vluzacn

    WOW! It's much better now man, THANK YOU!

  12. #362
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,556

    Re: custom version of ZHLT by vluzacn

    Screen shots pls?
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  13. #363
    Registered User
    Join Date
    Sep 2011
    Location
    Brazil
    Posts
    15

    Re: custom version of ZHLT by vluzacn



    With the -texreflectscale 0.4 and 100 brightness on the light_environment

    PS: When I see these images in my other computer, they are much better because the monitor is more clear and modern, but as I map in the older computer the images are darker, this is so bad

  14. #364
    Registered User
    Join Date
    Nov 2004
    Location
    Europe
    Posts
    2,827

    Re: custom version of ZHLT by vluzacn

    Increase the contrast and brightness a bit. There usually are buttons on the front or under the front of monitors. Press some.

  15. #365
    Registered User
    Join Date
    Sep 2011
    Location
    Brazil
    Posts
    15

    Re: custom version of ZHLT by vluzacn

    Are at maximum level, is a CRT monitor and the problem is that he highlights some colors: S

  16. #366
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,556

    Re: custom version of ZHLT by vluzacn

    CRT screens are usually more accurate than TFT's anyway
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  17. #367
    Advanced Leveldesigner SourceSkyBoxer's Avatar
    Join Date
    Apr 2011
    Location
    Germany
    Posts
    803

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by Truck View Post


    With the -texreflectscale 0.4 and 100 brightness on the light_environment

    PS: When I see these images in my other computer, they are much better because the monitor is more clear and modern, but as I map in the older computer the images are darker, this is so bad
    Yes my Display Led Monitor is ok and it works with heavy powered display card ATI Radeon HD 5770. It has a lot of color profiles like Adobe RGB, Default RGB or sRGB also another Mac-RGB or Windows-RGB. But i have been tried current color of display monitors.

    Same result of LD-Monitors are different because latest monitors have poor energy.

    If your new monitor from year 2005 or early time = this monitor has enough energy ( ca. 100 - 200 watt )
    Or
    If your monitor from year 2010/2011 = it has poor energy ( ca. 15 - 70 watt )

    It is possible because newest monitors will get darker than old monitor.
    Are you using with PS3 Game than in-games will same dark. Because all led display televisions will be limit to 50 - 100 watt.

    Thanks for new version of monitors!

  18. #368
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Update:

    version 25


    Improve hlrad's ability to handle the case of too many dynamic light styles on a face.
    When a face gets more than 3 different dynamic light styles, some of the light styles must be discarded. Now hlrad ensures that the brightest 3 dynamic light styles will be kept.
    The 'too many styles' error will no longer occur. But any style darker than the 3 brightest styles will be discarded without any warnings, because I haven't created a warning for that.



    Add 'func_detail' entity, which is similar in function to the func_detail in Source, though I probably implement it in a rather different way.

    What is func_detail:
    (Brushes that are not in any entities are called world brushes, and brushes in func_details are called detail brushes.)
    Detail brushes are almost same to world brushes. They cannot be distinguished from world brushes once the compile has finished. For example, when viewing the bsp with 'BSP Viewer', func_details don't disappear after unchecking 'render entities'.
    What makes detail brushes different from world brushes is that they don't participate in visibility calculation, which means they won't slow down hlvis.
    A better description can be found here: http://developer.valvesoftware.com/wiki/Func_detail

    Differences between detail brushes, world brushes and func_walls:
    Compared to world brushes, detail brushes don't block vis or slow down vis process, and don't chop faces from world brushes, and don't cause the 'Ambiguous leafnode content' warning.
    Note that detail brushes cannot be used to seal a map, and must not be made of water or sky (but SKIP and CLIP can be used in func_details).
    Compared to func_wall, func_detail don't consume engine's model precache slots (which is 512 max), and will give player mdl (and any other mdl) correct brightness when he steps over it.
    In addition, there is an option that allows a func_detail to chop faces of world brushes in order to reduce face area and produce better lighting.
    But unlike func_wall, the faces in func_detail will be cut if it happens to span across a splitting plane of the BSP structure generated from world brushes and func_details, thus increasing bsp file size and wpoly.

    Usage:
    Convert any brushes, that are not parts of the basic structure of the map, to func_detail. They cannot be water brushes or sky brushes.
    You can leave 'Detail level' to 1. For tiny objects, you might set it to 2, so that they won't chop the faces of other func_details.
    For large shapes such as terrain and walls, you can set 'Lower its level to cut others' to no less than its detail level, so that they can chop adjacent world brushes like world brushes.
    Before compiling the map, hide all entities and func_details, make sure there are no leaks and the structure is good enough for vis calculation.

    Further explanations:
    To add the feature of detail brushes, I introduced a concept called 'detail level', which is a number assigned to each brush, which can be 0, 1, 2, 3,... .
    --I will refer to all brushes that have the same detail level as a 'layer':
    All world brushes are in the layer of detail level 0.
    All brushes in a func_detail go to the layer corresponding to the func_detail's 'detail level' which is default to 1.
    Brushes in brush entities such as func_wall are not in consideration here, because they are in seperated entities.
    --In the CSG process:
    Every layer will not be affected by any more detailed layers (with only one exception).
    Every layer will be chopped by all less detailed layers. That is, if a brush in this layer is embedded into less detailed layers, then the embedded part will be chopped off.
    Brushes in the same layer always chop each other.
    The exception is, if you want a brush from a more detailed layer to chop the faces of a brush from a less detailed layer, you can either set the former's 'Lower its level to cut others' or the latter's 'Raise its level to get cut' to no less than the difference of their detail level.
    --In the BSP process:
    First, the surfaces of the layer of detail level 0 split the space into large leafs, which are also portal leafs that are used in vis calculation.
    And the layer of detail level 0 is not allowed to have leaks, so detail brushes cannot be used to 'seal' a map.
    Then the surfaces the layer of detail level 1 split every leaf into smaller leafs, but they no longer act as portal leafs.
    Then does layer of detail level 2, 3,... .
    Note that number of visleafs reported in the bsp statistics chart is the number of final leafs generated by all layers.
    --In the VIS process:
    The visibility data is calculated only according to portal leafs generated by the layer of detail level 0.
    So, func_details will not increase the time of VIS process significantly. But they may have some impact on the VIS process, because when the BSP program is processing the layer of detail level 0, it has to also try to optimize the total number of faces, nodes and leafs.
    After the calculation, the vis data between portal leafs is then converted to the vis data between final leafs. So adding func_details will increase the total size of vis data.

    Other notes:
    The detail layers uses an advanced method to decide leafnode content, so detail brushes will not cause "Ambiguous leafnode contents" warnings and related problems.
    Usually merely using detail level 0, 1 and 2 is enough. Using too many detail levels may make the BSP process inefficient and increase the bsp file size. For the same reason, 'Detail level of cliphulls' should always be 0 or 1 unless you are trying to solve some cliphull errors by adjusting this value.
    Changing the 'Detail level of cliphulls' to 0 will reduce the number of clipnodes, but the cliphull of this func_detail will not use the new leafnode content method.



    When CLIP texture is used together with normal textures, which is not allowd before this update, the brush will act like a CLIP brush (block players, don't block bullets, grenades or flashlight) while its faces remain visible.
    Note that this brush will also not block light, unless it is tied to an entity with 'opaque' option on.
    A typical usage is wire mesh. Create a thin brush with wire mesh texture, and texture the thin side faces with CLIP. Then convert the brush to a func_wall with appropriate properties. You don't need to convert it to func_illusionary.
    This feature also makes it possible to let bullet pass through wire meshes which are parts of a moving entity.



    Add 'SOLIDHINT' texture which can help create better BSP structure for terrain and other complicated shapes.
    The BSP process is to use planes to split the entire space into convex leafs. On each split, every face which spans across the splitting plane must be cut into two fragments by the plane.
    In most cases, hlbsp can find a good splitting plane for each split, such that only a few faces are cut.
    However, for some complicated shaped surfaces such as terrain and another chimney-like object in the sample map, you may find out that their faces are cut into a lot of fragments, when you view the map in BSPviewer or type gl_wireframe command in game.
    This is because hlbsp chooses splitting plane only from the planes of existing faces on the surface, and all faces that are not on the surface of the object are ignored.
    In the case of terrain, you can see that the surface only contains the triangle slopes, so it's hard for hlbsp to choose a good splitting plane from these slopes.

    SOLIDHINT makes it possibe to manually add extra faces for hlbsp to choose from, in order to help reduce face count and other counts.
    For example, for the terrain created by 'Terrain Generator', the vertical planes on the grid lines cut no faces. So we can place SOLIDHINT faces along these planes.

    There are two ways of adding SOLIDHINT faces:
    1. Like how you add a HINT face, create a brush with SOLIDHINT texture on one face and SKIP texture on other faces. The face with SOLIDHINT texture will become a SOLIDHINT face.
    or 2. Replace the the texture of an invisible face of a normal brush to SOLIDHINT. Then a SOLIDHINT face will be copied from that face.

    The sample map uses the second way. In the sample map, a SOLIDHINT texture is applied to the shared face of two adjacent solid brushes. So it seems that the SOLIDHINT can "seperate" the two adjacent brushes and stop them from cutting each other.
    If you want SOLIDHINT to "seperate" brushes that are part of func_details, make sure the SOLIDHINT is in the same detail level.

    Differences between SOLIDHINT and HINT:
    1. HINT always cause the space to be cut into more but smaller leafs and increase the size of bsp file, while SOLIDHINT can reduce the number of cuts and decrease the size of bsp file. Placing more SOLIDHINT than needed will usually cause no side effect, except longer compile time in hlbsp stage.
    2. There is no need to place HINT inside solid brushes because the purpose of HINT is better vis, while SOLIDHINT faces can be inside solid brushes.



    Add 'AllocBlock' amount report for '-chart'.
    The main problem one may face while building large maps is the 'AllocBlock:full' error that occurs when the map is being loaded by the game engine.
    This new feature can tell the mapper how close to 'AllocBlock:full' error a map is.



    Change the condition of MAX_MAP_LEAFS warning.
    Now this warning only appears if the number of visleafs (leafs formed from world brushes) exceeds 8192.
    The bsp statistics chart can show the number of visleafs.
    I'm sure that having more than 8192 leafs will not cause any problems as long as the number of visleafs does not exceed 8192.
    I'm not sure whether having more than 8192 visleafs will make the game crush or cause any serious problem.

    Increase the limit of different textures from 512 to 4096.
    There are no evidence showing that 512 is an engine limit, and there seems to be no errors when I test a map with 2048 textures. So I decide to increase the limit.

    Replace the 'wad.cfg' system with a new way of configuring wad list, because the old way is very buggy and hard to understand.
    Now every wad config file only contains one set of wad files. The syntax is shown in the 'samplewadconfig.txt'.
    If you have more than one configuration, you should put them in different wad config files.
    To use a wad config file, you must add parameter '-wadcfgfile ' for hlcsg. The '' can either be a full path, or be the relative path from map folder or tools folder.
    For example, the 'samplewadconfig.txt' is in the tools folder, so you can use '-wadcfgfie samplewadconfig.txt'.

    Fix the issue of water brushes leaking light.
    This only affects world brushes with liquid texture. This doesn't affect func_water.
    Now the underwater area will be totally dark unless you add light sources. (As for light sources, turning the water texture into texture light is a good idea)

    Fix the bug that the surface of func_water only emits texture light upwards and fails to emit texture light downwards.

    Remove the old weird and buggy way how hlbsp deals with HINT texture.
    Now HINT will probably work more efficiently than before.

    All 'aaatrigger' texture will automatically become invisible.

    Change hlrad's default '-gamma' from 0.5 to 0.55 and default '-texreflectgamma' from 2.5 to 2.2
    These values are more suitable for Half-Life's default gamma value for lighting and texture and Windows's gamma value.

    Change hlrad's default vismatrix method to sparse, because sparse is often a must for large maps.
    The parameters for each vismatrix methods have been changed to '-vismatrix sparse', '-vismatrix normal' and '-vismatrix off'. (But you can still use the old '-sparse' or '-nomatrix')

    Some other changes:
    Fix the broken '-nullfile' parameter.
    Opaque entities that are beyond sky brushes will not cast shadows.
    Increase the limit of visibility data size.
    The light_surface entity may automatically determine whether the texture light uses fast mode according to its brightness and the '-dlight' parameter.
    Remove hlrad's '-maxlight' parameter because it is useless and a little uncompatible with dynamic light styles.
    '-wadcfgfile', '-hullfile' and '-nullfile' will not require full path.

    The tools are compiled by vs2010. So their sizes are much bigger and they may run 10% slower than the older versions.
    Attached Files Attached Files
    Last edited by vluzacn; 12-11-2011 at 03:20 PM.

  19. #369
    Registered User
    Join Date
    Nov 2004
    Location
    Europe
    Posts
    2,827

    Re: custom version of ZHLT by vluzacn

    Do the tools run slower or the compile of the tools?

  20. #370
    QPU-aligned Silencer's Avatar  
    Contributor
    Join Date
    May 2006
    Posts
    6,078

    Re: custom version of ZHLT by vluzacn

    Thanks for the release! Been wondering when we'd get a fresh new update. =)
    Dynamic light styles prioritization and func_detail sound great!

  21. #371
    The scripter and fixer,quad rulez Maiten's Avatar
    Join Date
    Sep 2011
    Location
    North Zone Of Buenos Aires,Argentina
    Posts
    136

    Re: custom version of ZHLT by vluzacn

    when i try to compile any map i get this

    Error: ReadSurfs (line 2): scanf failure

    ----- END hlbsp -----

    the same with sample_funcdetail_and_solidhint.map

  22. #372
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by Dynamite View Post
    Do the tools run slower or the compile of the tools?
    The compile of the map.

    Quote Originally Posted by Maiten View Post
    when i try to compile any map i get this

    Error: ReadSurfs (line 2): scanf failure

    ----- END hlbsp -----

    the same with sample_funcdetail_and_solidhint.map
    This may happen if hlcsg and hlbsp are from different versions.

  23. #373
    The scripter and fixer,quad rulez Maiten's Avatar
    Join Date
    Sep 2011
    Location
    North Zone Of Buenos Aires,Argentina
    Posts
    136

    Re: custom version of ZHLT by vluzacn

    oh facepalm,bad setup on my batch compiler,other hlbsp linked.working now,thanks!

  24. #374
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,556

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by vluzacn View Post
    Improve hlrad's ability to handle the case of too many dynamic light styles on a face.
    When a face gets more than 3 different dynamic light styles, some of the light styles must be discarded. Now hlrad ensures that the brightest 3 dynamic light styles will be kept.
    The 'too many styles' error will no longer occur. But any style darker than the 3 brightest styles will be discarded without any warnings, because I haven't created a warning for that.
    Nice
    No need to implement a warning tbh, that is a good behaviour

    Quote Originally Posted by vluzacn View Post
    Change the condition of MAX_MAP_LEAFS warning.
    Nice, I have a few maps with >8192 leaves (seems 32767 was the highest I could have the limit), never any issues.

    Quote Originally Posted by vluzacn View Post
    Increase the limit of different textures from 512 to 4096.
    Nice, I saw no problems with >512 textures either.

    Quote Originally Posted by vluzacn View Post
    Replace the 'wad.cfg' system with a new way of configuring wad list, because the old way is very buggy and hard to understand.
    Now every wad config file only contains one set of wad files. The syntax is shown in the 'samplewadconfig.txt'.
    If you have more than one configuration, you should put them in different wad config files.
    Is there an option to revert this? I found WAD configs very easy to understand, and even made a tool to manage them very easily. I don't want yet another set of files along with my map sources just to specify what WAD's it uses -- even though a list of WAD files a map uses are inside the .map itself.
    Also how was it buggy?

    Quote Originally Posted by vluzacn View Post
    Fix the issue of water brushes leaking light.
    Good idea -- full thickness water shouldn't pass light.

    Quote Originally Posted by vluzacn View Post
    Fix the bug that the surface of func_water only emits texture light upwards and fails to emit texture light downwards.
    I hadn't noticed that myself, but I'll recompile a map and see

    Quote Originally Posted by vluzacn View Post
    All 'aaatrigger' texture will automatically become invisible.
    Excellent -- this texture is 100% pointless. I throw salmons at people insisting they use the replace tool for NULL.

    Quote Originally Posted by vluzacn View Post
    Everything else you updated
    Nice

    Quote Originally Posted by vluzacn View Post
    The tools are compiled by vs2010. So their sizes are much bigger and they may run 10% slower than the older versions.
    Can I still compile them in VS2008?

    Also have you tried compiling and using your tools in a 64-bit build? They do compile a map quicker, but they nearly always end up with some small but noticeable lighting glitches.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  25. #375
    Registered User vluzacn's Avatar
    Join Date
    May 2010
    Location
    China
    Posts
    274

    Re: custom version of ZHLT by vluzacn

    Quote Originally Posted by AdamR View Post
    Is there an option to revert this? I found WAD configs very easy to understand, and even made a tool to manage them very easily. I don't want yet another set of files along with my map sources just to specify what WAD's it uses -- even though a list of WAD files a map uses are inside the .map itself.
    Sorry for lack of backwards compadibility. And right, it is easy to understand.
    But I think you may misunderstand my idea. The only difference is that in the old way multiple configs are assembled in one 'wad.cfg' file, while in the new way they must be put into individual config files.

    Quote Originally Posted by AdamR View Post
    Also how was it buggy?
    Although the 'wad.cfg' often seems to work normally, there are some (and I believe there are more) stupid mistakes in the old code that definitely need to be fixed. But I won't go through the code because it is lenthy and disordered.

    Quote Originally Posted by AdamR View Post
    I hadn't noticed that myself, but I'll recompile a map and see
    This bug was reported at http://forums.svencoop.com/showthrea...515#post470515
    It actually only happens in VHLT and is the result of the fix of another func_water bug.

    Quote Originally Posted by AdamR View Post
    Can I still compile them in VS2008?

    Also have you tried compiling and using your tools in a 64-bit build? They do compile a map quicker, but they nearly always end up with some small but noticeable lighting glitches.
    Oh, it is said on the Internet that you need change a few lines of the sln and vcxproj files.
    I don't have a 64-bit computer.
    Last edited by vluzacn; 13-11-2011 at 01:00 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •