Upvote Upvoted 42 Downvote Downvoted
HUDGEN: A tool for seamless HUD updating and gener
posted in Customization
1
#1
0 Frags +

HUDGEN
A tool for seamless HUD updating and generation written in NodeJS
Github

Years ago I was a maintainer of GIVHUD (Gamemaster's Improved Vanilla HUD). GIVHUD was a fork of IVHUD, meant to accommodate a nicer looking and easier to read stock HUD. The HUD had not been touched in about 3 years time. I recently have released a version 2.0.0 to try and accommodate up to Halloween 2018 (A few bugs are expected).

I originally considered doing so by hand, but found so tedious, especially with my disconnect from the game and various, poorly documented, HUD changes.

As such, I have written a utility to handle HUD comparisons. The utility is known as HUDGEN.

I have written a comprehensive release of it at https://huds.tf/forum/showthread.php?tid=1322&pid=5357#pid5357 along with source code. The tool is written in NodeJS.

In short, what the tool does is takes a custom HUD (any HUD will do, find one at huds.tf). It will take that HUD from VDF and convert it into JSON (JavaScript Object Notation). The user also provides the latest copy of the stock TF2 HUD, this too, is converted into JSON. The two are then deep compared and all output is put back out in VDF (the standard format for HUDs)

Once the utility has two JSON forms of the custom HUD and the stock HUD, two things generated. The first is a diff (additions and edits that occurred in the custom HUD only). This is a fantastic view to see what the HUD creator has done to change this HUD.

Once the above diff is generated, the diff is then compared against the stock HUD. A HUD is outputted as a result. This output is a comprehensive comparison of the diff and the stock HUD.

A deep comparison is done to generate a brand new custom HUD. All values that exist in both custom and stock are added to output, prioritizing the custom HUD values. Any values that do not exist in the custom HUD that do exist in stock, are added to the output. This ensures that any new content not previously existent in a custom HUD will get output--This is powerful, ensuring that no HUD can be outdated.

For a tl;dr perspective:
* This tool extrapolates out changes made in a custom HUD
* This tool can be used to seamlessly update dated HUDs to be compliant with the most recent stock HUD in TF2.
* This tool is great for HUD devs to quickly make releases and iterations on their own HUDs

[h]HUDGEN[/h]
A tool for seamless HUD updating and generation written in NodeJS
[url=https://github.com/mstan/HUDGEN]Github[/url]

Years ago I was a maintainer of GIVHUD (Gamemaster's Improved Vanilla HUD). GIVHUD was a fork of IVHUD, meant to accommodate a nicer looking and easier to read stock HUD. The HUD had not been touched in about 3 years time. I recently have released a version 2.0.0 to try and accommodate up to Halloween 2018 (A few bugs are expected).

I originally considered doing so by hand, but found so tedious, especially with my disconnect from the game and various, poorly documented, HUD changes.

As such, I have written a utility to handle HUD comparisons. The utility is known as HUDGEN.

I have written a comprehensive release of it at https://huds.tf/forum/showthread.php?tid=1322&pid=5357#pid5357 along with source code. The tool is written in NodeJS.

In short, what the tool does is takes a custom HUD (any HUD will do, find one at huds.tf). It will take that HUD from VDF and convert it into JSON (JavaScript Object Notation). The user also provides the latest copy of the stock TF2 HUD, this too, is converted into JSON. The two are then deep compared and all output is put back out in VDF (the standard format for HUDs)

Once the utility has two JSON forms of the custom HUD and the stock HUD, two things generated. The first is a diff (additions and edits that occurred in the custom HUD only). This is a fantastic view to see what the HUD creator has done to change this HUD.

Once the above diff is generated, the diff is then compared against the stock HUD. A HUD is outputted as a result. This output is a comprehensive comparison of the diff and the stock HUD.

A deep comparison is done to generate a brand new custom HUD. All values that exist in both custom and stock are added to output, prioritizing the custom HUD values. Any values that do not exist in the custom HUD that do exist in stock, are added to the output. This ensures that any new content not previously existent in a custom HUD will get output--This is powerful, ensuring that no HUD can be outdated.

For a tl;dr perspective:
* This tool extrapolates out changes made in a custom HUD
* This tool can be used to seamlessly update dated HUDs to be compliant with the most recent stock HUD in TF2.
* This tool is great for HUD devs to quickly make releases and iterations on their own HUDs
2
#2
2 Frags +

nice bro

nice bro
3
#3
whitelist.tf
0 Frags +

Does this support hud files using #base?

Does this support hud files using [i]#base[/i]?
4
#4
0 Frags +
WiethoofdDoes this support hud files using #base?

I feel like there could be a lot of breaking changes if #base was accounted for, ie. two unrelated files using #base on the same file, and stock hud updates it in one location but it would break if added to the other.

If a hud fully uses #base it'd be effectively be doing this anyway though. I'm more wondering about if it can keep track of any intentional removals (most huds removal all minmode values for example) when updating. e: specifically mentions that these need to be null'd out, for anyone wondering

[quote=Wiethoofd]Does this support hud files using [i]#base[/i]?[/quote]
I feel like there could be a lot of breaking changes if #base was accounted for, ie. two unrelated files using #base on the same file, and stock hud updates it in one location but it would break if added to the other.

If a hud fully uses #base it'd be effectively be doing this anyway though. [s]I'm more wondering about if it can keep track of any intentional removals (most huds removal all minmode values for example) when updating.[/s] e: specifically mentions that these need to be null'd out, for anyone wondering
5
#5
0 Frags +

hi clueless gamer here, I copied all the steps except the last one cause im confused.
"Run the command npm run complete"
where do I run this command?

hi clueless gamer here, I copied all the steps except the last one cause im confused.
"Run the command npm run complete"
where do I run this command?
6
#6
0 Frags +
WiethoofdDoes this support hud files using #base?

It's untested and I would go with no at this point. I made use of a pre existing vdf parser library. I only modified the library to support duplicate VDF keys.

[quote=Wiethoofd]Does this support hud files using [i]#base[/i]?[/quote]

It's untested and I would go with no at this point. I made use of a pre existing vdf parser library. I only modified the library to support duplicate VDF keys.
7
#7
0 Frags +
Dylanhi clueless gamer here, I copied all the steps except the last one cause im confused.
"Run the command npm run complete"
where do I run this command?

You would run that in a command prompt window. NPM is a CLI interface tool.

I'd make some tutorial videos but I'm traveling at the moment. I'll make something more comprehensive once I'm back.

You can ask questions in the meantime.

EDIT: If you would prefer, Dylan, private message me here. I'll give you my discord and we can go through a comprehensive setup. End to end. It's a bit complicated if you haven't used these types of tools before. I don't mind going the extra mile to get it out there.

[quote=Dylan]hi clueless gamer here, I copied all the steps except the last one cause im confused.
"Run the command npm run complete"
where do I run this command?[/quote]
You would run that in a command prompt window. NPM is a CLI interface tool.

I'd make some tutorial videos but I'm traveling at the moment. I'll make something more comprehensive once I'm back.

You can ask questions in the meantime.

EDIT: If you would prefer, Dylan, private message me here. I'll give you my discord and we can go through a comprehensive setup. End to end. It's a bit complicated if you haven't used these types of tools before. I don't mind going the extra mile to get it out there.
8
#8
0 Frags +
JarateKingWiethoofdDoes this support hud files using #base?I feel like there could be a lot of breaking changes if #base was accounted for, ie. two unrelated files using #base on the same file, and stock hud updates it in one location but it would break if added to the other.

If a hud fully uses #base it'd be effectively be doing this anyway though. I'm more wondering about if it can keep track of any intentional removals (most huds removal all minmode values for example) when updating. e: specifically mentions that these need to be null'd out, for anyone wondering

Yeah the null values wasn't ideal. Best I could come up with. Empty strings seem to behave the same as null.

[quote=JarateKing][quote=Wiethoofd]Does this support hud files using [i]#base[/i]?[/quote]
I feel like there could be a lot of breaking changes if #base was accounted for, ie. two unrelated files using #base on the same file, and stock hud updates it in one location but it would break if added to the other.

If a hud fully uses #base it'd be effectively be doing this anyway though. [s]I'm more wondering about if it can keep track of any intentional removals (most huds removal all minmode values for example) when updating.[/s] e: specifically mentions that these need to be null'd out, for anyone wondering[/quote]

Yeah the null values wasn't ideal. Best I could come up with. Empty strings seem to behave the same as null.
9
#9
2 Frags +

damn I love this community

damn I love this community
10
#10
2 Frags +

Update for the initial release (Thanks exa_ ) for testing.

A few updates.

* Windows is bugged at the moment. For now, please use OS X/Linux. Windows support will be implemented at a slightly later date.
* Support for #base handling has been implemented
* Support for custom .res files has been added (for files that exist in custom that do NOT exist in stock)

TODO:
* Implementation of supporting copying .bmp, .ttf and other modified/custom HUD images/fonts

KNOWN ISSUES:
* VDF technically supports both quoted and unquoted keys. The community parsers for JSON handling do not support this. For now, all unquoted keys will have to be quoted in community provided HUDs. I am exploring methods on how to resolve this.

Update for the initial release (Thanks exa_ ) for testing.

A few updates.

* Windows is bugged at the moment. For now, please use OS X/Linux. Windows support will be implemented at a slightly later date.
* Support for #base handling has been implemented
* Support for custom .res files has been added (for files that exist in custom that do NOT exist in stock)

TODO:
* Implementation of supporting copying .bmp, .ttf and other modified/custom HUD images/fonts


KNOWN ISSUES:
* VDF technically supports both quoted and unquoted keys. The community parsers for JSON handling do not support this. For now, all unquoted keys will have to be quoted in community provided HUDs. I am exploring methods on how to resolve this.
Please sign in through STEAM to post a comment.