Check out Half-Life Re-imagined competition results!
Check out Skewing textures in Hammer, our newest tutorial!
Welcome, kesizewi, our newest member!

logo

Site Stuff

Reference

Maps

Community

ShoutBOX

Poll

Feeling Blue

What's your favourite shade of blue?

Azure

17

Cobalt

32

Turquoise

11

Cyan

12

Royal

11

Teal

3

Onliners

46 secs

Stojke

3 mins

JeffMOD

6 mins

Tetsu0

7 mins

SourceSkyBoxer

21 mins

Solokiller

21 mins

James Luke

27 mins

The Mad Carrot

Affiliates

A gaming and technology blog by TWHL admins Penguinboy and Ant. A music blog by TWHL users Ant and Hugh.

Half-Life Enhanced

1 2 3 4 5 [6] 7 8

Forums > HL Engine Discussion

20 Oct 16, 15:05
By Solokiller
avatar
Member
I've created a Gitter community for the code repo: https://gitter.im/HLEnhanced-Project/Lobby

I'm not sure if that link will let you see it if you aren't already in the group. I've invited you (Shepard) so you should be able to see it.

There's also a badge in the README so anyone else can easily join through Github.

Quote:

What about using Git's submodules function ?


That looks promising, i'll have to try that out sometime.

Quote:

...


Something wrong?

I've implemented lifetimes for plugins, and added a cvar to specify the plugin list file. I've also added console commands to load and unload plugins.

Plugins can also specify their own minimum lifetime now.
20 Oct 16, 16:13
By Loulimi
avatar
Member
Quote:
Quote:
...
Something wrong?

It is pretty clear to me that his message is a call for love and attention.
20 Oct 16, 17:51
By fuzun
avatar
Member
I wrongly posted to this topic instead of other one and I could not delete it :/

You seem to work hard I would want to take a look at your recent commits but I am living in a damned third world country and I have to work almost 10 hours each day.
20 Oct 16, 20:03
By Solokiller
avatar
Member
Sounds pretty bad, i don't know if there's any way to view commits in a lightweight manner but if there is you can use that.

I implemented the #include callback so scripts can now include other scripts. I tested it with scripts located in SteamPipe directories as well, so if the main script or any included script is in another directory it'll still work.

The code for it is pretty crappy because the C++17 filesystem doesn't have any built-in functionality for making paths relative to another, but it should work fine regardless.

The latest Windows build has been committed, including some simple test plugin code. Nothing fancy though.
21 Oct 16, 10:41
By Solokiller
avatar
Member
I've added documentation for the plugin list file, and all cvars and console commands used by the plugin system: https://github.com/SamVanheer/HLEnhanced/wi
ki/Angelscript-Plugins
21 Oct 16, 13:40
By ninja defuse
avatar
Member
can u show me an example of angel script in hl enchanced?
21 Oct 16, 14:49
By Shepard62700FR
avatar
Member
Nevermind Sven-Coop, it works on HLEnhanced
21 Oct 16, 15:03
By Solokiller
avatar
Member
The API is still pretty simple, i've focused largely on making sure the essentials are there. With plugins in place any future additions will account for them from the start, which makes things a lot easier.

I'll be reviewing each entity class that needs to be exposed to make sure they're well designed and documented first, then they'll be exposed. Once i get to CBasePlayer, i can add functionality for players like enumerating all players, so until that time stuff like sending HUD messages won't be possible. It won't take that long though, i don't have to add them in inheritance order so i can expose CBasePlayer first if needed.
21 Oct 16, 16:36
By fuzun
avatar
Member
Here is pvs studio report (I think it is the best analyser): I hope this will help you

I think pvs studio free - standalone viewer can open this without warnings. But it needs to be confirmed I am not sure.

https://transfer.sh/FTAsN/hlenhanced-6310a7
5-pvsreport.zip


Note: Replace "G:\XashWorks\hlenhanced-new" this according to your setup.
24 Oct 16, 16:39
By Solokiller
avatar
Member
I found some time to try this out. The standalone was able to open the file and display filenames and line numbers, but i don't see any file paths related to the repository location anywhere.
25 Oct 16, 12:04
By Solokiller
avatar
Member
I've reported a race condition in the engine that no longer affects HLEnhanced (no operator int): https://github.com/ValveSoftware/halflife/i
ssues/1755


If you use EHANDLEs and have implemented NEW_DLL_FUNCTIONS::pfnOnFreeEntPrivateData,
make sure to check that your code cannot have this kind of problem.

This is the probable cause of a crash in SC, i've been aware of it for some time but only now investigated the engine's code to confirm my suspicions regarding the serial number not being incremented.
26 Oct 16, 19:58
By Solokiller
avatar
Member
By request, i've implemented trigger_random. I was planning to add it anyway, but since it was requested i added it right away.

It works just like SC's trigger_random, and none of its code was based on it in any way. The random selection logic is based off of UTIL_RandomTargetname, which comes from several entities that had RandomTargetname methods.

There's a test map for it called test_random.
There's a random time instance that fires ambient_generics that play Human Grunt sounds. One of them is listed several times so you'll hear it more often.
You can toggle it with the button on the left.

The second instance triggers one of 4 doors. It will trigger all 4 before triggering one of the doors that was already triggered before. It resets every time all 4 have been fired.
You can trigger it with the button in front of the doors.

I've also fixed some of the issues that were found by PVS Studio. Some of them can't be fixed due to various reasons, such as VGUI1 classes not having virtual destructors. Adding them could change the layout of the class's vtable, which would cause crashes.
27 Oct 16, 16:33
By Solokiller
avatar
Member
I've added the trigger_script entity. It allows you to call script functions in map scripts and/or plugins. I've added the documentation for it here: https://github.com/SamVanheer/HLEnhanced/wi
ki/trigger_script


As usual the SC team or anyone else can use it as they see fit, but i do have to ask in the case of the SC team to credit me for the work if it is used in any way.

I've also fixed a problem with map scripts not being loaded when a saved game is reloaded. That explains why the script wasn't available before, since the code that loads it wasn't being called. It was a stupid mistake, but it could have caused greater problems if left undiscovered for a while longer.
27 Oct 16, 17:30
By Shepard62700FR
avatar
Member
I improved some formating on the new Wiki pages and also did a little overhaul of the Home page.
28 Oct 16, 16:15
By Solokiller
avatar
Member
The wiki is looking good, great work.

I've implemented support for custom entities. It's bare bones, but the essentials needed to get inheritance working for any entity class is there now. Further changes may be needed depending on problems that are yet to be encountered, that remains to be seen.

The test map test_custom_entities defines a very simple entity that outputs to the console to indicate when it's created and destroyed.

I'll have to add support for overriding every virtual method in CBaseEntity, that's not too difficult but is rather verbose. Once that's done i should be able to port the func_vehicle script to make it work. Keen requested it which is why i prioritized the implementation of custom entities.

There are some changes planned for vehicle control, so the script will eventually be updated. It shouldn't affect any maps that use it.

Plugins are also able to use custom entities. If the plugin's lifetime is not at least MAP, it will be promoted to MAP automatically to prevent any issues.

Once i've got CBaseEntity's interface properly set up, i'll start writing documentation for the existing API and will start adding required functionality for func_vehicle_custom to work. That should be relatively straightforward.

If you need to see what the CCustomCBaseEntity class looks like, use the server command as_outputbaseclasses <filename> to write it to a file. It will be placed in the game directory.

This is what it looks like right now: http://pastebin.com/WdWSYLBR

EDIT: i've added a bunch of virtual methods, and added the ability to set Think, Touch, Use and Blocked methods. You can set both script class methods or methods that belong to the self member class type. This makes it easy to use existing methods.
01 Nov 16, 09:12
By ninja defuse
avatar
Member
i have seen angel script examples on svencoop forums and it is amazing... it will be possible to create some serious mods...

imagine a machine in a game which let u buy items. Imagine inventory system or dialogues system even... however knownledge of programming is required

Welcome to Half Life Enchanced Edition! smile - :)

ps. angelscript reminds me C#ish style
01 Nov 16, 09:19
By Shepard62700FR
avatar
Member
Imagine if there was no map size limit : a Half-Life MMOFPSRPG (like Borderlands).
01 Nov 16, 09:41
By Solokiller
avatar
Member
Quote:

imagine a machine in a game which let u buy items. Imagine inventory system or dialogues system even... however knownledge of programming is required

Welcome to Half Life Enchanced Edition! smile - smile - :)

ps. angelscript reminds me C#ish style


Once the client side API for VGUI(2) is working that will be pretty easy to do.

Angelscript's syntax is based off of C#, so it should be familiar.

Quote:

Imagine if there was no map size limit : a Half-Life MMOFPSRPG (like Borderlands).


One day that may be possible, but a lot of things need to change before that's an option. (everything from Hammer to the engine, to game code)

I've been putting together the Angelscript API for enginefuncs_t, as well as some related features. Once it's done and tested i'll commit it, then i can see what's left to do for vehicles.
I know that i'll have to add hooks, and that system is due for an overhaul. I'm going to rename it to events, and it'll be a bit easier to use them as well.

I'm also going to make it possible to use these events on a per-entity basis so they'll behave like Source's outputs, it'll have some limitations due to how it handles the definition of the funcdefs used to add hooked functions though. I'll figure that out when i get to it, hopefully i can get it to be flexible enough to use any funcdef.

Once it's done, it'll be easier than ever to deal with entity specific events. I'm thinking something like this:
Quote:

pEntity.HookEvent( "OnKill", OnKillHook( someobject.KillHook ) );


Where OnKillHook is defined as:
Quote:

funcdef void OnKillHook(CBaseEntity@ pSelf, const CTakeDamageInfo& in info);


This will be a real pain in the ass to save/restore, it might not even be possible due to how Angelscript works. It'll still be very useful in multiplayer though.
01 Nov 16, 14:49
By abbadon
avatar
Member
Hi!, this is not related to Angelscript, but... how about an script_sequence or sentence entity that does not need to be triggered to start?, like the trigger_auto entity that fires itself at a certain time and targets other entity.

This way the scripted sequence is already working in the game before it is triggered and also the script could start at a certain time without to have a targetname. It could be cool that the entity has a certain number of animations and a time to perform them, domething like:

Quote:
anim1:
anim1 duration: (the animation could last 30 secs but you can play only 10 secs if you want, 0 means that it will loop)
anim1 break: (a time to stop it if you loop it)
anim1 target on end: (the animation, if ended triggers something)
anim2:
anim2 duration:
anim1 break:
anim2 target on end:


wink-wink - ;)

Will it spare us some multimanagers and trigger_once entities? wink-wink - ;)

Also the script entity should work with npcs that has not any code behind them, I mean, code like barney.cpp, or hgrunt.cpp, just a model with its animations to play under the orders given by the new script entity.

I saw ages ago this tutorial from Thewavelenght:

http://articles.thewavelength.net/212/

Should it be a good base for all that?
01 Nov 16, 16:09
By Solokiller
avatar
Member
Well, you can use Angelscript to trigger arbitrary numbers of things, and change keyvalues at will. Eventually you'll be able to make your own scripted_sequence classes too, so you can implement your own script logic for monsters.

You can use the scheduler to call functions on a delay, so you don't need multimanagers at all, just set the functions to execute in MapActivate.

monster_generic should work with scripted_sequence, though i don't know if that's in the SDK or not. I think that's from Opposing Force, if not i'll have to invent a new implementation for it.
01 Nov 16, 22:04
By Instant Mix
avatar
Horton hears a who?
Out of curiosity, why was Angelscript chosen as the language to implement?

I know i'm in the minority for not knowing anything C /C# / C++ related (that sentence alone probably proves that) , but I'm surprised something more along the lines of Python / Lua / Javascript.. hell, even java, wasn't chosen instead.

Is it due to the APIs or whatever are available?
01 Nov 16, 22:25
By Solokiller
avatar
Member
Well, i'm using it because i'm very familiar with it and because it's very efficient. I'm familiar with it because i had to implement it for SC, and it was chosen because another programmer was familiar with it. So you'll have to ask that guy why he's familiar with it tongue - :P

Angelscript directly calls C++ code, so it'll have much higher performance compared to a language like Javascript, where string lookups occur all the time. In a performance critical program like a game, that can make a real difference.
01 Nov 16, 22:35
By Shepard62700FR
avatar
Member
If people prefer Python or Lua over Angelscript, they can write their own "wrapper", just copy/paste the Angelscript implementation and tweak it for Python/Lua.
02 Nov 16, 21:04
By Solokiller
avatar
Member
I've implemented the API required for vehicles to work. The script has been added and a test map that uses it has also been added, it's called test_func_vehicle.
It works just like Sven Co-op's version, which is identical to Counter-Strike's version with the exception that the sound handling is a bit better so it's less likely to break.

EDIT: forgot: func_vehiclecontrols can be set to remotely control the vehicle.

The test map enables chat based debugging options to let you try out some things more easily:
Quote:

vehicle_speed <vehicle targetname> <speed>: Sets the maximum speed for the given vehicle. Note that speeds above ~1500 are likely to send the vehicle flying out of the map.
vehicle_accel <vehicle targetname> <acceleration>: Sets how fast the vehicle accelerates.
vehicle_restart <vehicle targetname>: Respawns the vehicle at its initial start point.


Just say it in chat to use them. The vehicle that is used in the test map is called "vehicle1".
No clamping or sanity checks are done so if you enter insane values or negative values, it'll happily use them.

See this page for more information on how this entity works, as well as a link to a tutorial (which should be archived!): http://twhl.info/wiki.php?id=231

The script will probably be changed a bit soon, so expect scripts that use it to stop working.

I'll be documenting the script API that's been exposed before adding anything else, otherwise nobody will know how to use it.
04 Nov 16, 17:36
By Solokiller
avatar
Member
I've uploaded the Doxygen documentation for HLE and put up a Github Pages website: http://samvanheer.github.io/HLEnhanced/

It links to both Git repositories, the wiki, the Doxygen documentation, this thread and the Gitter chatroom, so it's a one stop shop for all things HLE.

It was a real pain in the ass to get working, i forgot to make gh-pages an orphan so SourceTree went nuts with the commit messages and froze. I hope the documentation is useful, because i'll be referring to it from the Angelscript documentation whenever possible.
05 Nov 16, 00:00
By Solokiller
avatar
Member
I finally figured out what was causing melee weapons to play their animation twice in close succession when weapon prediction was disabled: melee weapons actually check if they hit something twice in close succession, and when prediction is disabled that results in the event that handles the animation being played back twice.

The code is the same on the client side, with one important exception: the client doesn't run think functions, which are used to handle the second swing. Now that this is fixed, all weapons should work fine at all times, barring excessive ping that goes beyond the 64 frame rollback ability of the engine's prediction system.

I've also been dealing with some minor issues, like the shotgun using hardcoded values for the maximum shell count. The fewer TODO items, the better.
06 Nov 16, 00:49
By Shepard62700FR
avatar
Member
I heavily improved the look of the GitHub Pages and Solokiller merged my work. The pages look much better and more complete.

See for yourself
06 Nov 16, 02:19
By Strider
avatar
Tuned to a dead channel.
Seems to be shaping up nicely! Great stuff.
07 Nov 16, 19:31
By Solokiller
avatar
Member
The website looks great, much better than anything i could've ever made. Great job Shepard!

I fixed another weapon bug: the Gauss gun could use up 2 ammo when you only had 1 left, and leave you with -1 ammo. This could then cause the game to constantly switch between the Gauss and Egon guns.

I've also discovered the purpose of the client's filter mode setting; apparently it's designed to filter out colors to give it a kind of CS nightvision look. It's kind of like de-saturating an image but leaving a specific color in it.

Note that CS doesn't use this, it overlays a transparent color on top of the viewport instead. Similar end results, except the filtering system changes how some rendering operations behave, like dynamic lighting not being applied in some cases.

I've also done some minor cleanup in some areas, and i've fixed a problem with func_guntarget not being able to toggle if triggered. This will probably break some singleplayer maps that relied on its original behavior, but that's easily fixed with some ripenting.

The test map test_guntarget tests all 3 trigger states. The leftmost button toggles, the middle button turns it on and the right button turns it off.
09 Nov 16, 20:15
By Solokiller
avatar
Member
I've pushed a new branch called vgui2. It's a mostly complete implementation of VGUI2, but there are probably a lot of crashes that haven't been encountered yet in there.
I've updated the main interfaces to be compatible so those should be fine, but a lot of code depends on Source engine features and might not work correctly.

It compiles, links and runs on Windows, i don't know about Linux but that'll probably require some special handling. This codebase isn't too good about filename case sensitivity so it will crash and burn hard on that.

I'll continue working on it, test to see if the main features work properly before getting the Linux version up and running.

This would all be much easier if Valve would just release their version, but since that one's tied into the engine's mess of a codebase, they'd have to release most of their engine code along with it, and you'd see just how bad it is in there. This is all we're going to get for the time being.

EDIT: got it to work pretty well, i now have a fullscreen frame that will be used as the viewport:
14 Nov 16, 09:19
By Solokiller
avatar
Member
I've worked on the VGUI2 implementation some more, i figured out that the code used by official Valve games is near identical to that of Source 2006's VGUI2 code, so i was able to use that to understand the implementation much better. The current setup has a viewport with support for viewport panels that can be shown at will.

I've also refactored the existing Hud code to use a better approach to defining and using Hud elements. Each Hud element is now registered statically, and is given a render depth. This allows you to precisely control which elements are drawn first and which are drawn last. This removes the need for hud.h to include all of the element classes and means that direct access is no longer provided.

I'm also close to allowing the entire Hud to be replaced at will with different implementations, which should make it easy to have completely different Huds for different teams/classes/etc. I'm talking about differences like one team having the regular Hud, while another would have different Hud elements in different locations, with different color schemes and sprites. (That's a lot of different)

Once i'm done with the refactoring of that code, i can get some new Hud elements set up for VGUI2, which should suffice for anybody wanting to use it for their own mod. Then i can merge this into the main branch.

I've also sent another mail to Valve asking for support for important issues, asking for a way to let the community work on the engine and official games, and i let them know that i've been implementing VGUI2 in HLE. I haven't informed them about that before, so that might make a difference.
I sent the mail to all 4 addresses that i sent the other one to before, so here's hoping i get a response this time.
14 Nov 16, 22:23
By Trempler
avatar
Member
Nice smile - :)
14 Nov 16, 23:26
By Loulimi
avatar
Member
Let's hope so!
16 Nov 16, 11:29
By Solokiller
avatar
Member
I've received no response from Valve, no surprise there. They must be well aware of what i'm doing by now, so they clearly don't care.

I implemented Angelscript in the Source 2013 SDK. This was to show the people at Empires mod how it can be done, what can be done with it, and how easy it is. It was also a great way to test if it would work in a codebase that uses an older compiler.
Sadly it didn't work, and upgrading the codebase turned up some problems in the SDK that i can't fix. Valve's memory allocator hacks are currently beyond my ability to fix, i'll need some time to investigate that.

Instead i backported my utility code to work with the v120 toolset, which means that once the HLE codebase is updated, you'll be able to compile (part of) it with v120.

The Angelscript implementation is bare bones, but already more powerful than HLE's in some ways. Source has the necessary callbacks to load and free the map script at the right time; before any entities are created and after all entities have been removed, respectively.
It also loads the list of scripts from a Keyvalues text file, which represents the map config file.

Having the code needed to do all of this available in Source makes things a lot easier, since you don't have to build entire parsers, work around missing engine features, etc. I can probably implement client side scripting just as easily, and network data between scripts too.
Basically, everything i want in GoldSource is already there in Source.

This implementation isn't going to be expanded any time soon, since it's just an example. If anybody finds it useful for their own mod, have at it. Remember that it uses a bunch of utility code that i wrote, if you don't want that then you'll need to write your own code to manage startup and script loading.

You can find more details, as well as the link to the code repository and a test mod here: https://forums.empiresmod.com/index.php?thr
eads/angelscript-in-source.20654/


I've also refactored my Angelscript utility code a bit to decouple the manager classes. You can now use them separately without needing to use a CASManager class, and the event manager is optional now.

I've also added logging support that can be implemented by the library's user. It uses a system similar to that of the game where messages have a log level.
This can be used to decide whether a message should be logged or not. I've got some more refactoring to do there to make the code more reusable, but it's all working properly at the moment.

Once i've updated HLE i'll be able to overhaul all of the logging code in existing Angelscript code to use the same logger, which will direct output to a log file with all relevant information. I'll also be adding diagnostic output so you can more easily debug it if a problem occurs.

The VGUI2 implementation should be functional right now, i'll need to make that test Hud element to confirm that. I also need to reverse engineer the new HTML code classes so you can use the CEF1 stuff.
I'll add an MOTD window pointing to TWHL's site to see how powerful it is. Maybe you'll be able to post from inside the game when this is working grin - :D
16 Nov 16, 13:38
By Loulimi
avatar
Member
That would be grand! "TWHL HUB, it's HLE, do you copy?"
25 Nov 16, 00:28
By Merz
avatar
Member
Hey, I wasn't sure where to post this issue so I thought I'd leave it here. I tried running the HLE Master on Visual Studio 2015 and got these errors. Not sure if I'm maybe doing something wrong.



Also tier1 and vgui_controls failed to load if thats related.
25 Nov 16, 00:36
By Solokiller
avatar
Member
You need to use CMake to generate the project files. The old project files are outdated and won't work. The Github repository's wiki has a guide on how to do this.
25 Nov 16, 08:26
By Merz
avatar
Member
Ah alright.

Using the guide though, I'm really confused about Step 5. If someone is using the GUI and runs Configure, how would they set the path to Common? Thats the part I'm stuck at, I've never used Cmake before so I'm confused about how it works.
25 Nov 16, 09:10
By Shepard62700FR
avatar
Member
If you are using the GUI, press "Configure", CMake will show an error but you should now be able to see the "STEAMCOMMON" variable.

If you are using the Windows Command Prompt, assuming you are in a folder called "projects_vs2015" in HLE's root, you would do :

cmake -DSTEAMCOMMON="C:\Program Files (x86)\Steam\steamapps\common" ..

If you want Opposing Force entities, just add -DUSE_OPFOR=1, -DUSE_ANGELSCRIPT=1 for Angelscript support, etc...
13 Dec 16, 21:06
By Solokiller
avatar
Member
Someone asked me how much effort it would take to allow weapons to occupy the same position in a bucket. So i figured i might as well implement that feature:



Guess i'll have to make it draw the list a bit different to show weapons near eachother. All weapons have the same bucket and position in this screenshot.

The list is sorted first by position, then by weapon ID. This ensures consistent sorting order as long as the weapon ID remains the same, which for built-in weapons it always will be.
Once custom weapons have been added, weapon registration order will dictate sorting order due to assigning weapon IDs in that order.
14 Dec 16, 20:18
By abbadon
avatar
Member
That´s one of the coolest screenshot I have seen for a long time!!! I like the way all weapons are placed this way!.
02 Jan 17, 18:19
By Solokiller
avatar
Member
I finished the VGUI2 Linux port, it now fully compiles and links with no errors or warnings. I haven't tested the client yet because my VM's OpenGL support breaks when i suspend the VM itself, so i'm currently waiting for the game to recompile.

Shepard also fixed a duplicate function issue so that should eliminate all warnings coming from the Source SDK code for the time being.
This code will need to be refactored since there's a fair amount of duplicate code, and i've also spotted some unfinished code in the Source SDK codebase (KeyValues doesn't support wide strings properly, etc).

With that done i can finally get that test element working to see if it all works properly.
03 Jan 17, 21:08
By Solokiller
avatar
Member
I updated the AngelscriptUtils codebase with some pending changes and merged them across to HLE. The Linux version was using outdated libraries so it wasn't working.

VGUI2 now works on Linux as well, so all i have to do now is fix case sensitivity issues in the codebase. It only works for me because i'm using a shared directory that points to a Windows filesystem, so it seems to be translating the filenames.
04 Jan 17, 19:27
By Solokiller
avatar
Member
The case sensitivity issues have been resolved, VGUI2 now compiles in a cloned repository as well as one that uses a VM shared folder. We're getting there.

EDIT: OSX builds are now successful as well.
05 Jan 17, 01:42
By Trempler
avatar
Member
pretty nice, have to test this again smile - :)
05 Jan 17, 20:16
By Solokiller
avatar
Member
I'll try get some new builds committed when i'm done fixing the warnings that each compiler emits. I'm currently fixing Clang warnings, then i'll have to check GCC again.
MSVC warnings are trickier because some of them involve missing debug symbols for MariaDB, so i'll have to compile the client library myself to get those.
That probably won't be done today, but it is something i want to get done so i can enable the highest warning level and treat warnings as errors.

I'm going to make 5 test elements for VGUI2, that way i can show VGUI2's resolution independent scaling combined with coordinates being relative to a side of the screen. One of those will be centered on-screen.
This build will be committed to a separate branch in the game repo so it can be easily tested.

I'm also going to make the Source SDK utility code available to non-VGUI2 builds so it can use things like CUtlVector (dynamic array), CUtlDict (efficient string->object binary tree), CUtlSymbol (string->integral mapping for constant time string comparisons), etc.

With that done i can make some of these available for save/restore as well. CUtlVector can replace multi_manager's list of targets, reducing memory usage for most cases (unless you're using the maximum number of targets every time you use them), and expanding the maximum number of targets to theoretically infinite, though practically it's limited to what Hammer, the .rmf and .map formats, the compiler, and the engine will handle.
Hammer has some limits, but i don't recall any hard limits on the number of keyvalues being present.

I can also get rid of the dependency on mariadb.dll since mariadbclient.lib is a static library, not an import library. This means that either one provides the interface, and it explains why the delayload warning kept popping up.

EDIT: All warnings are now fixed with the exception of the use of the "register" keyword, because that keyword was deprecated in C++17 which isn't out yet.

Some of these warnings were actually bugs, such as an MD5 hash result not properly being zeroed out or an infinite loop in some string code. All in all the codebase is now doing pretty well, once i've dealt with the other warnings from symbol files i can dial up the warning level and fix what gets reported then.

Then i can run code analysis and fix those issues as well.

EDIT2: I was able to get a hold of the OSX tier0 and vstdlib libraries using SteamCMD so the OSX build is working again. Requiring tier0, vstdlib & tier1 as dependencies showed that it was missing those libraries for Travis builds.
06 Jan 17, 10:54
By Solokiller
avatar
Member
It's working:


The locations and sizes are defined in the resource file:
Quote:

"ui/scripts/HudLayout.res"
{
center
{
"fieldName" "center"
"xpos" "c-25"
"ypos" "c-25"
"wide" "50"
"tall" "50"
}

topleft
{
"fieldName" "topleft"
"xpos" "50"
"ypos" "50"
"wide" "50"
"tall" "50"
}

topright
{
"fieldName" "topright"
"xpos" "r100"
"ypos" "50"
"wide" "50"
"tall" "50"
}

bottomleft
{
"fieldName" "bottomleft"
"xpos" "50"
"ypos" "r100"
"wide" "50"
"tall" "50"
}

bottomright
{
"fieldName" "bottomright"
"xpos" "r100"
"ypos" "r100"
"wide" "50"
"tall" "50"
}
}


It automatically scales with resolutions and can position relative to any side and the center of the screen.

You can set panel properties using these files as well, and that extends to user defined properties too so you can use this to define strings, booleans, floats, integers, etc.
06 Jan 17, 18:21
By Solokiller
avatar
Member
Did a little digging to figure out how VGUI2's resource files work:



At 640x480:


Quote:

center
{
"fieldName" "center"
"xpos" "c-25"
"ypos" "c-25"
"wide" "50"
"tall" "50"

"image"
{
"ControlName" "ImagePanel"
"fieldName" "image"
"image" "gfx/vgui/1024_timer"
"xpos" "12.5"
"ypos" "12.5"
"wide" "25"
"tall" "25"
"scaleImage" "1"
}
}

topleft
{
"fieldName" "topleft"
"xpos" "50"
"ypos" "50"
"wide" "50"
"tall" "50"

"image"
{
"ControlName" "ImagePanel"
"fieldName" "image"
"image" "gfx/vgui/640_banner_small"
"xpos" "10"
"ypos" "10"
}
}


No code support required.

Image extensions are checked automatically (tga first, bmp if not found), you can scale the image to the panel or scale the panel to the image. All other properties are also available.

You can create entire panels like this without ever touching the code, though you will need code support to update them.

Combined with Angelscript i figure this will allow for fully customizable HUDs, though i did encounter a problem: https://github.com/ValveSoftware/halflife/i
ssues/1767


I doubt they'll fix it, so i'll just have to work around it.

This is the code used to show those 5 elements:

Quote:

class CTestHudElement : public vgui2::EditablePanel, public CHudElement
{
public:
DECLARE_CLASS_SIMPLE( CTestHudElement, EditablePanel );

public:
CTestHudElement( const char* pszName )
: BaseClass( g_pViewport, pszName )
, CHudElement( pszName )
{
SetVisible( true );
SetActive( true );
}

void ApplySchemeSettings( vgui2::IScheme* pScheme ) override
{
BaseClass::ApplySchemeSettings( pScheme );
SetBgColor( SDK_Color( 255, 255, 255, 255 ) );
}
};

REGISTER_NAMED_HUDELEMENT( CTestHudElement, center );

REGISTER_NAMED_HUDELEMENT( CTestHudElement, topleft );
REGISTER_NAMED_HUDELEMENT( CTestHudElement, topright );
REGISTER_NAMED_HUDELEMENT( CTestHudElement, bottomleft );
REGISTER_NAMED_HUDELEMENT( CTestHudElement, bottomright );


34 lines of code including headers, not much for so much power.

EDIT:





I've backported Source 2013's image scaling, tiling, centering and draw color support.
Centering support isn't actually enabled in 2013 because they never bound the variables to script keys, so this is actually a bit of a bonus.

The image on the top left is just a regular image, no scaling or center applied.
The bottom left image is centered.
The top right image is scaled.
The bottom right image is scaled and centered, scaling to 0.5 of its normal size.

The center image is set to tile both horizontally and vertically.

To achieve consistent scaling the image panel's size should be set to its desired size, with scaling enabled. It'll scale the image to the panel's size.

The third image shows the center image with the draw color set to red (255 0 0), and alpha set to 128.

EDIT2:


Overridable colors, and the top bar is set to take up the full width of the screen, with the exception of the last 100 pixels.
07 Jan 17, 09:34
By SourceSkyBoxer
avatar
Member
Wow modem vgui panels on in-game! Nice wortk SoloKiller! smile - :)
08 Jan 17, 22:49
By Solokiller
avatar
Member
So i spent the weekend backporting the (old) new CEF1 based HTML MOTD code, and after fixing a bunch more interface issues, i succeeded:
1 2 3 4 5 [6] 7 8

Forums > HL Engine Discussion

Login to Reply

You must be logged in to reply.