New reading scheme for vbsp, vvis, vrad

[Unusuario2]

(Describe your PR here and then fill out the checklist at the bottom)

This is a PR that aims to make the compile tools more easier to read, both for standart hammer user and hammer++.

Changes:

   New reading scheme:  
      -Green: process done.  
      -Blue: indicates a path.  
      -Purple: indicates a number of a funtion.  
      -Red: process failed.  
      -Cyan: Only for header strings.  
  General:  
        -All the color messages are written in valve custom implementation of color cmd "ColorSpewMessage( SPEW_MESSAGE, &red, "********", );" so it doesnt have an issue with linux users.  
        -All "done (0)" set to green to have a better visualizations.  
        -All the warning and error will be tabulated in the console for easy spot.   
        -Added the date of the build day and the target plataform in the tools headers (Like in source 2)  
        -Fixed some letters not being capital.  
        -Fixed some strings that do not have the "\n"  
        -All the paths now are indicated as +- "blue"  
        -The number that indicates data are in purple.  

Examples:
Stock Hammer (new scheme vbsp)

Stock Hammer (old scheme vbsp)

Stock Hammer++ (new scheme vbsp)

Stock Hammer++ (old scheme vbsp)

Stock Hammer++ (new scheme vvis)

Stock Hammer++ (old scheme vvis)

Stock Hammer++ (new scheme vrad)

Stock Hammer++ (old scheme vrad)

Does this PR close any issues?

• (Optional) Insert issue number(s) and any related info here

PR Checklist

• [x ] My PR follows all guidelines in the CONTRIBUTING.md file
• [x ] My PR targets a develop branch OR targets another branch with a specific goal in mind

[1upD]

It looks like this PR targets the branch master but it will need to target develop instead.

I notice a lot of tab spacing changes in the output. Can you walk through the overall thought process of which lines of output should have tabs preceding vs not?

[Unusuario2]

It looks like this PR targets the branch master but it will need to target develop instead.

I notice a lot of tab spacing changes in the output. Can you walk through the overall thought process of which lines of output should have tabs preceding vs not?

Since standard hammer doesnt support color text, spotting an Error/Warning becomes difficult, so for every Error/Warning that the compilers spells there is going to be an 8 character tabulation for easy spotting. This rule applies for every Error/Warning found in the compilers.

Also for hammer++ users this new format combine with colors makes spotting these things very easy and clear.

[Unusuario2]

this PR should be alright, all the useless files/modifications have been removed

[Unusuario2]

i closed the PR by accident, sorry

[Unusuario2]

How should i resolve the conflict in vscript_squirrel.cpp? changing the code to develop?

[Blixibon]

How should i resolve the conflict in vscript_squirrel.cpp? changing the code to develop?

The conflict was caused by the recently merged save/restore rewrite. Since I was responsible for merging that and causing this conflict, I took the initiative to resolve the conflict for you, although I think a number of the messages you changed in that file were removed by the rewrite.

[Unusuario2]

How should i resolve the conflict in vscript_squirrel.cpp? changing the code to develop?

The conflict was caused by the recently merged save/restore rewrite. Since I was responsible for merging that and causing this conflict, I took the initiative to resolve the conflict for you, although I think a number of the messages you changed in that file were removed by the rewrite.

Okay, i will do a PR adding again the modifications from the overwritten file.

[Unusuario2]

I checked the "overwritten file" and all the Error("\t Warning("\t are found in the vscript_squirrel.cpp so it is good to go. Is PR is able to merge right now.

[Blixibon]

I'm really concerned about the fact this adds tabs to libraries used by the game without any demonstration or mention of what effect this has in-game. Have you tested that?

[Unusuario2]

I didn't test it in game, even if it worked it would mess up the scheme in the console, to acknowledge this i will use the next format (only in the shared code between the tooling and game):

#if defined(MAPBASE) && defined(SDK_TOOLS) // For the tooling, we use a different printing format
    Warning("\tlight has _fifty_percent_distance of %f but no zero_percent_distance\n", d50); //tools
#else
    Warning("light has _fifty_percent_distance of %f but no zero_percent_distance\n", d50); //game
#endif

The SDK_TOOLS preprocessor directive will be included in the tooling VPC scripts.

[Unusuario2]

Now, VBSP, VVIS, and VRAD will use the SDK_TOOLS preprocessor directive to enable specific features from the shared code between the game and the tools. Since the tools do not link against tier1, there is no need for a separate build for them. However, mathlib does require this adjustment. VBSP, VVIS, and VRAD will now link against mathlib_sdktools.lib instead of mathlib.lib. See the new VPC file (mathlib_sdktools.vpc), which includes everything from mathlib with an additional SDK_TOOLS preprocessor directive.

This is now ready to merge since there is no contamination between the game and tools code.
(NOTE: The changes only affect printing formatting (tools Warning/Error("\t game (without the \t)); there are no logic changes.

[samisalreadytaken]

My input on the colours from what is visible on the screenshots is that it is too colourful without a purpose. I don't think successful actions ("done") should be highlighted, they are expected. User input (files) and input data (light count, texinfo etc) can be coloured, though perhaps not as dark as they are there. Colouring each character of RGB is gimmicky and childish, it doesn't provide any value. I didn't check what every compiler output looks like, but think about what information needs emphasis and how it will improve mapper experience.

The overeaching output edits seem completely useless. The blind search & replace in even debug comments doesn't give me confidence that you knowingly applied them. There isn't even any tabs visible in the screenshots you shared apart from a couple of compiler specific lines, so why edit irrelevant files? Instead of adding horizontal space to every output, it might be better to print more to highlight.

Error is a terminating call, they don't even need any formatting at all since they will be the last output.

I don't think text such as **** leaked **** and AREAPORTAL/MAP LEAK should be changed, they have been the same for over 20 years, changing them will only make troubleshooting more confusing.

I don't think usage of arrows (->) instead of colons (:) is appropriate for what the text is trying to convey. Again, seems like a change for change's sake.

I don't understand the comments on StandartColorFormat files. Besides being duplicated between header and code files, why mention ANSI at all? Does ColorSpewMessage not work for all colours, what works then, why is there colours declared that don't work? You have VT enabling code commented out in a couple of places, if colours don't work without it, why is it commented out; if they work without it, why is it there?

"Standard" in "StandartColorFormat" file name is is misspelt.

[samisalreadytaken]

If it doesn't change anything, why change it?

[Unusuario2]

Because when calling ThreadSetDefault(); the funtion will print the number of threads before vvis prints the header of the tool, this is a incossitensy. That is why i changed it.
before:
16 threads
Valve Software - vvis.exe (__DATE__)
now:
Valve Software - vvis.exe (Build: pc32 __DATE__)
(Threads: 16)

The comment will be removed, as it could lead to confusion

[samisalreadytaken]

I don't understand, is there some out of order buffer flushing or time travel with the execution order of Msg? ThreadSetDefault was always called after the "Valve Software" header print. When does what you said happen?

[Unusuario2]

I don't remember how i have got this error, i will try to recreate it and post it

[Unusuario2]

My input on the colours from what is visible on the screenshots is that it is too colourful without a purpose. I don't think successful actions ("done") should be highlighted, they are expected. User input (files) and input data (light count, texinfo etc) can be coloured, though perhaps not as dark as they are there. Colouring each character of RGB is gimmicky and childish, it doesn't provide any value. I didn't check what every compiler output looks like, but think about what information needs emphasis and how it will improve mapper experience.

Hammer++ cmd system doesn't fully support 8-bit RGB colors, so I am limited to using colors that contain only two primary components. For example, 255,128,128 wouldn't work, but 255,128,0 would, That's why the colors appear 'strong'. To acknowledge this issue, I can add a command-line option to disable color highlighting: "-NoColorHighlighting".
Regarding ('done'), these have been placed in most cases at the end of a function so the mapper/coder can easily determine where the function fails. These actions, while expected, do not always happen, so extra information about the crash is helpful.

The RGB color format is meant to be prettier, but I will remove it if it becomes an inconvenience or is disliked.

The overeaching output edits seem completely useless. The blind search & replace in even debug comments doesn't give me confidence that you knowingly applied them. There isn't even any tabs visible in the screenshots you shared apart from a couple of compiler specific lines, so why edit irrelevant files? Instead of adding horizontal space to every output, it might be better to print more to highlight.

Could you explain more your point? I dont understand it fully.

Error is a terminating call, they don't even need any formatting at all since they will be the last output.

Even though is a terminating call is easier to spot in very large .log files with this new format.

I don't think text such as **** leaked **** and AREAPORTAL/MAP LEAK should be changed, they have been the same for over 20 years, changing them will only make troubleshooting more confusing.

The change will be reverted then.

I don't think usage of arrows (->) instead of colons (:) is appropriate for what the text is trying to convey. Again, seems like a change for change's sake.

This change was made because all the paths are referenced with : so using -> makes the log more clearer.

I don't understand the comments on StandartColorFormat files. Besides being duplicated between header and code files, why mention ANSI at all? Does ColorSpewMessage not work for all colours, what works then, why is there colours declared that don't work? You have VT enabling code commented out in a couple of places, if colours don't work without it, why is it commented out; if they work without it, why is it there?

Valve doesn't use ANSI codes; they use ColorSpewMessage with the Color class. So, what I did was provide a 1-to-1 equivalent to Valve's format using all the ANSI colors, in case Hammer++ fixes this issue in the future or if someone implements a Windows-specific function to address it.

"Standard" in "StandartColorFormat" file name is is misspelt.

Will be fixed.

[Unusuario2]

Changes:

1. Removed RGB coloration in VRAD.
2. Standardized number formatting in messages: Any function containing a number now wraps it in brackets ([number]) across all strings. For example, "Token too large on line 158" is now "Token too large on line [158]". (This was previously implemented but did not apply to all strings.) (common)
3. Added support to disable text highlighting in the tools. (common)
4. Improved message categorization: Some functions previously using "Msg" were changed to "Warning" or "Error" for better clarity for mappers. (common)
5. Reverted the new format for "leaked" and "AREAPORTAL/MAP LEAK". (VBSP)
6. General cleanup of older ANSI-based implementations. (common)
7. Now all the strings of vbsp,vvis,vrad follow the new path format (Message: +- path). (common)
8. Some Typos fixed.

Note: These changes do not apply to VMPI, as no one actively uses it.

[arbabf]

Standardized number formatting in messages: Any function containing a number now wraps it in brackets ([number]) across all strings. For example, "Token too large on line 158" is now "Token too large on line [158]". (This was previously implemented but did not apply to all strings.)

I'm apprehensive about this change. While it provides the benefit of better readability, newer mappers who run into compiler errors may use the Interlopers error checker as a debugger, which can fail to read some of the newly-formatted errors.

An example is shown below, where the old format string can be read and produces a search result:

However, with your proposed format string, the error doesn't get flagged in the compile checker:

The error checker has been a useful tool for many people, and I don't think we should expect newer mappers to be able to trawl through the compile log to find out what problems exist with their compile, nor should we expect Interlopers' error checker to be able to parse these new error strings.

[Unusuario2]

Your concern is reasonable. These changes to the compiler's printing format should be documented in the Mapbase wiki (https://github.com/mapbase-source/source-sdk-2013/wiki/Map-Compilers). This should also be one of the main points in the announcement for Mapbase 8.0 since it is a big change. While new mappers may initially struggle with the new reading format in some cases, this can be easily addressed by providing proper documentation in the Mapbase wiki. Additionally, adding a link to the wiki in the tools description would help guide users to the information found in the wiki.

One possible fix would be to add a command-line option like -DisableNewPrintingFormat to revert to the old scheme. However, this will make the source code a mess . With clear and concise documentation, these issues can be addressed for new users.

[Unusuario2]

New printing formatting (VBSP, VVIS, VRAD)

Color sheme:

-Green: Process successfully terminated.

-Blue: Indicates the path to a file.

-Purple: Indicates the number of a function (used to highlight information).

-Red/Warning: Process failed or bad process.

-Cyan: Only for header strings.

Printing scheme:

1. Errors and Warning will be tabulated.
2. Paths now will have a standard format, give by the next structure: (Message : +- path).
3. The pacifier process will now use -> instead of : (colons are now reserved only for paths and string information, e.g., Brush [3] : no visible sides on brush).
   
4. Header strings will highlighted in Cyan, format: Valve Software - tool_name (Build: target plataform, arquitecture, date of the build)(Threads: number of threads)
   
5. Most functions will display done(seconds) in green to indicate that the process has ended successfully.
   
6. For functions that include numeric information, the number will be displayed in the following format: Message [number].
   
7. When the tool finishes the process, a string starting with '-->' will be displayed.