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.