Forum posts

Can admin rename this thread to a more suitable name, so someone with the same problem can find this thread and script more easily?
As you wish.
Can admin rename this thread to a more suitable name, so someone with the same problem can find this thread and script more easily?
And it should run on almost any OS. ;)
I have Python 3.5 and 3.7 custom build for Windows XP that works (3.4.4 is the last official version that supports XP). :P
User posted image
Posted 1 day ago2021-12-02 11:05:51 UTC
in Source animation root bone Post #346098
I tried making an animated model with a walk cycle and got stuck in the root bone process. It can be cause the original root bone (Or bip01 that is the father of all bones) merges with the pelvis when the model compiles right?

I could get a model to walk to a destination in the beta engine but in the retail the model teleports to its destination even with 1 forward walk animation. It's the older engine yes but it might not have changed as much with the current releases.

Just some interesting discoveries to share here.
Posted 1 day ago2021-12-02 06:32:45 UTC
in Half-Life Updated (custom SDK) Post #346097
I also only use vs2019+
The vs2017 can be removed.

Thanks Solo, you are doing a great job.
tbh a func_door_rotate would probably work better since pendulums are a bit glitchy
I have a func_pendulum(window) set to a 45 degree and I have a func_breakable(piece of wood) targeting(on break) to the func_pendulum(window) when you shoot the piece of wood the window closes(swings down) so the window sits closed.

issue: it only works for the first round. every other round the window is closed.

what I want: I want the window to be set to a 45 degree position at the start of each round.

I've also considered using func_door_rotate.
Posted 2 days ago2021-12-01 21:22:30 UTC
in Half-Life Updated (custom SDK) Post #346094
For me, personally, the most important thing is to have something that's as close to the original, unmodified Half-Life SDK code as possible, while still being usable with VS 2019 or later. Whether that be through a VS 2019 project file or CMake doesn't really matter to me.
Dr. Orange Dr. OrangeSource good.
Posted 2 days ago2021-12-01 19:29:43 UTC
in Half-Life Updated (custom SDK) Post #346093
I stopped using the VS2017 project files last year. I haven't seen anybody use them lately.
On that note: to use the CMake version of Half-Life Updated you currently have to build the INSTALL target to deploy the libraries, which might be a bit cumbersome and annoying.
Not a problem for me, though I imagine it'd be a bit confusing/frustrating to beginners.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 days ago2021-12-01 18:52:39 UTC
in Half-Life Updated (custom SDK) Post #346092
@Solokiller

Personally, I've already removed VS17 projects from my Spirinity fork. I've got about 4 friends using my repo and they are all working on VS19, and I'm working on VS22 preview.

I'm not that sure about the removal/replacement of v141_xp tools but VS17 project files are probably lying there, unused.

About the CMake, using it could maybe add an additional barrier, but it could also encourage people to learn using CMake, so they could use this "skill" in other projects, too. Apart from that; it would also help to maintain cross-platforming and save from adding new files and build settings into particular projects one by one. So I'd personally side with CMake.

Lastly, making features optional generally give good results bacause some people want lightweight mod without the new asthethisc and concepts. So I'd say It'd be neat to give it a try.
FranticDreamer FranticDreamerR.I.P. Benny Harvey. Miss you big man. Gone but not forgotten.
Posted 2 days ago2021-12-01 16:53:01 UTC
in Half-Life Updated (custom SDK) Post #346091
I've got a question for anybody using Half-Life Updated: does anybody still use the Visual Studio 2017 project files?

The system requirements for Visual Studio 2019 are almost identical to that of 2017, mainly differing in the minimum version of Windows 10 required and the recommended amount of RAM:
https://docs.microsoft.com/en-us/visualstudio/releases/2017/vs2017-system-requirements-vs
https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements

VS 2019 is also more flexible in how much disk space is required due to its different approach to installing it, but that's about it.

If nobody has need for it then i'll remove the 2017 project files. This will simplify development a bit and allows certain newer features to be used (like C++20).

The VS 2019 project files should work out of the box with VS 2022 (it will upgrade the files on first open), so there is no need to maintain a separate set of files for now.

In the long run once the Half-Life Unified SDK has been released it might be easier to use that as a base instead since it will encompass Half-Life Updated, Half-Life Opposing Force: Updated and Half-Life: Blue Shift Updated. At that point i'd prefer to archive the older repositories to focus on developing that version of the SDK instead.

It uses CMake so there is no problem with supporting different versions of Visual Studio, although this does require users to learn to use CMake. I can cover the basics in a tutorial which should get people going, but it does add an additional barrier to new modders.

On the flip side it does automate things that have to be done manually, like setting up the copying of game libraries to the mod directory so there are benefits to using it.

On that note: to use the CMake version of Half-Life Updated you currently have to build the INSTALL target to deploy the libraries, which might be a bit cumbersome and annoying. Visual Studio won't build this target if you try to run a project that needs to be rebuilt and instead launches an older version.

I can change this to instead deploy them when building the projects themselves, if this is something that's considered preferable i'll make it do that.

Some people have asked to make certain new features in the Unified SDK optional, like Angelscript for example. I've been pondering how feasible this is and i think i can make it work, although certain features that depend on such features will not work as well if it's disabled (e.g. conditional cfg files wouldn't work).

I'd like to get people's opinions on the matter before i make any decisions.
Posted 2 days ago2021-12-01 16:37:28 UTC
in problems with porting my mod to steam Post #346090
Don't use the change game dialog, that's obsolete and not guaranteed to work properly. The correct way to launch mods under Steam is to launch it directly through Steam or launching Half-Life with the -game parameter.

If your mod isn't loading then there might be a problem with your client.dll file. Follow this tutorial to figure out what's wrong: https://twhl.info/wiki/page/Half-Life_Programming_-_Debugging#h6017c5e17e73f
Posted 2 days ago2021-11-30 22:40:04 UTC
in problems with porting my mod to steam Post #346089
ok so im trying to get my mod working on steam but when clicking 'change game' in the steam version of the game i gte this popup

could not load library E:\_tmp\Steam\steamapps\common\Half-Life\clusterfucklife\cl_dlls\client.dll

i also have a nonsteam version of hte game located in a a completely different folder on that same drive but i dont think it matters in that case
I've updated the script with a fix for the UV offset (it now adds 1 to the result of half_float(t) before multiplying it with the texture height), and added a note about the minimum Python version. It turns out that formatted strings were introduced in Python 3.6. I haven't used Python much the past few years but I figured a Python script would be easier to share (and to analyze and modify!) than an executable. And it should run on almost any OS. ;)
So, here's a Python 3 script...
Python versions 3.5 and below gave me a syntax error with the script, but versions 3.6 and up worked for me.
I assume they changed a syntaxis between these versions, so there is a minimal Python version requirement for your script, it's not like any 3 version will work.
So... it worked for me, everything is done ... Not! :)
Although the model looks OK in the model viewer, I think, there is a slight bug/miscalculation in your code, which misplace one of the UV coordinates :
the one coordinate grow from -maxtexturesize to 0, instead of, 0 to +maxtexturesizethe one coordinate grow from -maxtexturesize to 0, instead of, 0 to +maxtexturesize
Interesting to see about that.
Anyway, thanks!
YOU ARE GOLD!
Barney: Now ... about that beer I owed ya!
Check your PMs!
Posted 3 days ago2021-11-30 06:30:03 UTC
in Swapping between players Post #346086
I need help with this, beacuse I havent been able to figure this out on my own.
This is for a mod im working on (A decay port to PC source code can be found here)
So the set up Ive got so far is this:
Each player when spawning gets assigned a custom m_decayIndex value (from 1 to 2, if its not decay its 0)
I need to figure out how to change both players positions, angles, health, weapons, ammo, etc, with eachother
I alredy have a command that changes the index, but I need it to change players completely.

Help would be appreciated.
Posted 3 days ago2021-11-29 22:48:53 UTC
in TWHL Tower: Source Post #346085
Alright thanks, I just wanted to see if i was doing something wrong before I started digging deep into the map.
NovaDelta NovaDeltantx_cairostation
Posted 3 days ago2021-11-29 22:28:38 UTC
in TWHL Tower: Source Post #346084
Yeah, it applies to everything. If you can't get in permission from the rights holder, then don't use it in your map. And if it's a large corporation behind the game, chances are they wouldn't have let you used their content even if you did get in contact with them. Sorry.
Dr. Orange Dr. OrangeSource good.
Posted 4 days ago2021-11-29 21:46:26 UTC
in TWHL Tower: Source Post #346083
Yeeeah... I'm pretty sure that would be considered straight up copyright infringement. Safest bet: If you cannot explicitly get permission/the right to use an asset, maybe don't use it. :)
UrbaNebula UrbaNebulaGoldSourcerer
Posted 4 days ago2021-11-29 18:09:56 UTC
in TWHL Tower: Source Post #346082
Thank GOD theres an extension lol

I have a habit of sitting on my ass until the last possible moment and I was really hoping I wasnt too late.

Although theres progress! I finally have an idea and I've started importing textures.... my floor might be a bit dialog heavy and I hope its not too much for the mod though lol.

Actually question, I re-read the rules and saw that third party content is allowed as long as it's with permission, does that also apply to content from games that are made by massive studios that probably wouldn't give me a response? My idea is basically to remake a portion of a game I enjoy and I'm using assets directly from it
NovaDelta NovaDeltantx_cairostation
Posted 4 days ago2021-11-29 12:58:16 UTC
in Half-Life Updated (custom SDK) Post #346081
Regarding the work being done on Half-Life Updated at the moment: i'd like to thank malortie for helping to clean things up and fix bugs, it's really helping to make the SDK better.

I've completely eliminated the use of Windows headers in game code now, only 2 files still use it: inputw32.cpp (for raw input and mouse threading, which i'd like to convert to std::thread and related types) and interface.cpp (for loading dlls at runtime).

This has cut down on compile time some more. I've also reworked a ton of code to properly convert between bool and other types which should make it easier to tell when something's a true/false value or not.

I've switched the C++ language version from C++14 to C++17 which provides some useful additions like inline global variables.

I've enabled clang-tidy as part of the code analysis feature in Visual Studio, so you'll get more warnings now. A fair number of warnings are being shown because of the SDK's tendency to include headers only in source files so there are false positives, i'm going to try to fix those as much as i can.

Clang-tidy is configured through a configuration file in the root of the repository, i'm going to systematically enable more of those as i work through the remaining warnings.

I've also added a clang-format configuration file to the root of the repository which Visual Studio uses to format files. This ensures that formatting files is done consistently rather than depending on individual developers' text editor settings, but i'm still working out the kinks in the settings. The issue for this change provides more information on how it works, and how to mass-format all files: https://github.com/SamVanheer/halflife-updated/issues/84

I've been doing lots of code cleanup as well, removing duplicate forward declarations, using inline to avoid the need to declare globals as extern separately and otherwise improving the quality of the code.

The long-term goal is to have 0 warnings at the highest warning settings with as many clang-tidy warnings enabled as possible to enforce stricter and more correct code.

Note that due to recent changes existing save games will not work with newer updated builds. If you update your fork to include these changes, or if you use the next pre-built libraries you'll need to delete the save games to prevent problems from cropping up.
Posted 4 days ago2021-11-29 12:45:42 UTC
in Half-Life Updated (custom SDK) Post #346080
In regards to scripting, and assuming scripting allows for creating custom monsters and entities, I believe this could definitely be a plus.
Yeah that's certainly a possibility. I implemented custom entity/NPC/weapon support in Sven Co-op using Angelscript before.

I worked out some of the details for a scripting system last week. Since this is derived from Sven Co-op's scripting system (aka "previous system") i'll be comparing it to that. Note that this is all conceptual, i haven't written any code for this yet so it could change if it's not feasible.

Plugins and map scripts are virtually identical, unlike the previous system (somebody should update that page though, custom entities have been allowed in plugins for a long time now). The only difference is how long scripts stay loaded for.
Plugins normally get loaded on server startup and stay loaded until the server shuts down, unless the scripts are explicitly unloaded or reloaded.

Map scripts are loaded when a map references them, and are unloaded if the next map does not reference it. Some option to keep a script loaded regardless by extending its lifetime is required so you can have for example a script that runs in the background of every map, like a stat tracker or something.

The simplest way to do this is to use the configuration file system to list a script for use in multiple maps, or every map by listing it in the server config file. Then it'd just be a plugin loaded as a map script, with the option to conditionally include it using the Condition key.

One of the problems that popped up was that multiple scripts would be written to be the main script, with initialization code in the automatically called functions MapInit, MapActivate, MapStart and PluginInit. So if you then included multiple scripts those functions would conflict with each-other.

To solve this problem each script listed in the config file, and each script referenced by trigger_script would be loaded into its own Angelscript module. A module is basically a C++ library in terms of scope, so these API functions wouldn't conflict unless you mark them as shared.

In the previous system shared entities weren't allowed because it could interfere with the reloading of plugins. If you have a script that defines something as shared, include it in 2 or more plugins, change the shared code and then reload one of the plugins it'll fail to load because the shared code is now different.

I'd flip this behavior on its head now. Allow shared stuff, even between plugins and map scripts, but disallow making API functions shared to prevent one script from monopolizing them.

This approach makes it much easier to design things like AFB, which is a plugin manager written in Angelscript. To work around the lack of shared entities you have to add your script to a function to initialize the system: https://github.com/Zode/AFBase/blob/acd7ba7e1248538d9b660638915dc91a7da59deb/scripts/plugins/AFBaseExpansions.as

With shared entities each plugin can be its own module, referencing a shared Plugin class. Plugins then need only register their plugin class, which the plugin manager can query from the shared code to manage each plugin instance.

Such registration can be automated to this point:
AFBRegister register(@MyAFBPluginClass());
The AFBRegister class registers the plugin in its constructor and unregisters it in its destructor, thus tying the plugin lifetime to that of its containing module. You won't even need to write a PluginInit function anymore. AFBRegister would be a shared class.

The API functions should also be improved, there are too many of them. Each module should get exactly 2 of them: an init and shutdown function. Everything else should be event-driven:
void ScriptInit()
{
    //Called when the script is first loaded.
    //Subscribe to the MapInit event. All events define a unique event type associated with it, even if they don't have any data or methods.
    Events.GetEvent<MapInitEvent>().Subscribe(@MapInit);
}

void ScriptShutdown()
{
    //Called when the script is about to be discarded/unloaded.
    //Don't need to manually free event handlers because they'll be removed automatically, but it can be done manually like this.
    Events.RemoveAllEventHandlersFromCallingModule();
}

//All event handlers follow the same structure: void return type, one parameter taking the event by handle.
void MapInit(MapInitEvent@ event)
{
    //Called when the map is starting for any reason, map scripts could be in the process of being loaded right now, so inter-module communication isn't advised at this time.

    //Equivalent to Source's logic_auto outputs: https://developer.valvesoftware.com/wiki/Logic_auto
    switch (event.InitType)
    {
    case MapInitType::NewGame:
        //The map is being loaded for the first time, like when the map or changelevel console commands are used.
        break;
    case MapInitType::LoadGame:
        //The map is being loaded from a save game, which means the player is loading a save game or a map is being returned to through a trigger_changelevel.
        break;
    case MapInitType::NewRound:
        //For game modes that use round-based gameplay, a new round is starting.
        break;

    //More types if needed.
    }
}
The event system replaces hooks and allows for compile-time compatibility checking of events. The previous system had to rely on variable parameters because hooks could have any number of parameters, so you could technically pass in an integer into a function that's expecting a function handle. You'd get an error at runtime, so it's not as obvious that you've made a mistake.

On the C++ side you'd publish events like this:
Events.GetEvent<MapInitEvent>().Publish(MapInitType::NewGame);
This would then internally create the event object:
//Curiously Recurring Template Pattern-based base class
template<typename TEvent>
class Event
{
public:
    //Reference counting code omitted for brevity.

    template<typename... Args>
    void Publish(Args&&... args)
    {
        //Event is created with reference count 1, ownership transferred to smart pointer.
        //Event constructor is invoked with template parameters.
        as::SmartPtr event{new TEvent{std::forward<Args>(args)...}};

        //Event handlers are tracked by the Events global and will invoke all handlers.
        Events.PublishEvent(event.Get());

        //Smart pointer releases event, usually destroys it if no script holds on to it.
    }
};

class EventSystem
{
public:
    template<typename TEvent>
    void PublishEvent(TEvent* event)
    {
        //Probably a std::unordered_map<std::reference_wrapper<type_info>, as::SmartPtr<asITypeInfo>>.
        asITypeInfo* type = GetScriptTypeFromCppType<TEvent>();

        if (!type)
        {
            return;
        }

        auto context = ...;

        //Finds or creates the list of handlers for this event type.
        const std::vector<as::SmartPtr<asIScriptFunction>>& handlers = GetEventHandlersForType(type);

        for (const auto& function : handlers)
        {
            //Context setup and error handling omitted for brevity.
            context->SetArgObject(0, event);
            context->Execute();
        }
    }
};
Custom entities require a fair bit of work to support. You need to expose the class you want custom entities to inherit from, expose the API to call base class implementations (e.g. calling CBaseMonster::Killed from your NPC's Killed method) and you need to write a wrapper that forwards calls to the script for any virtual functions it has.

The C++ side also needs to support custom entity creation by implementing the custom function. I haven't quite figured out how to save and load them since the save game system doesn't use custom. I could hack it by saving custom entities to have the custom class, and then saving the actual classname separately. That solves the problem, but there is still the issue of scripts changing the custom entity implementation.

One map could have a script A.as that defines a custom entity foo, and the next map could have a script B.as that also defines a custom entity foo. When such an entity is transitioned between maps its composition can change dramatically, including changing base classes.

Custom weapons could be restored as an NPC for example, and the pointer to the weapon would now be invalid since CBasePlayerWeapon* isn't compatible with CBaseMonster*. There are no safeguards in the save game system against this and it would take some doing to support it, so the initial version of the scripting system wouldn't be able to support it.

Custom entity support thus needs to be disabled in singleplayer with an error message in the console if you try to register them anyway (since saving the game and loading it would make it disappear).

I'll work this out more once i've completed work on the first version of the unified SDK. There's still a lot of work left to be done in all of the existing repositories to clean things up.
Posted 5 days ago2021-11-28 20:14:56 UTC
in Half-Life Updated (custom SDK) Post #346079
@Solokiller

In regards to scripting, and assuming scripting allows for creating custom monsters and entities, I believe this could definitely be a plus.

For example, Garry's mod provides a Lua API which allows clients to override the game's default behavior. This mainly has the following advantages for clients:
  • Hide internal game code complexity
  • Reuse custom entities in multiple projects (No need to recompile)
  • Easier way to manage modularity (Depends on script language used)
  • Abstraction over game update (No need to recompile or merge changes in code base)
  • Write minimal code
In addition, this would probably encourage more people to contribute to a common SDK rather than maintaining a fork separately.

On developer side, the following must be taken in consideration:
  • Maintenance of script library (Additional work)
  • Ensure scripted language updates do not break client scripts (Unit tests)
  • Require to manage a wiki for clients and update documentation
I knew I had some model-loading code lying around but that turned out to be far from finished, so this took a bit longer than intended. It's indeed just a normalized half-float to absolute integer conversion, so I think I misinterpreted the .smd coordinates format, but working with mdl files directly is more accurate anyway so I didn't investigate the smd approach any further. So, here's a Python script (requires Python 3.6 or higher) for converting Xash models to GoldSource's format (be sure to change the input_path and output_path variables on lines 6 and 7 before you run the script):
import struct


def main():
    # Change these paths depending on which Xash model you want to convert:
    input_path = r'C:\your\models\folder\bpop2.mdl'
    output_path = r'C:\your\models\folder\bpop2_converted.mdl'

    # Read texture sizes:
    print(f'Reading \'{input_path}\'.')
    with open(input_path, 'rb') as file:
        data = bytearray(file.read(-1))

    texture_sizes = read_texture_sizes(data)
    if len(texture_sizes) == 0:
        # No texture information? Let's look for a *t.mdl file:
        try:
            texture_file_path = input_path[:-4] + 't.mdl'
            print(f'Reading \'{texture_file_path}\'.')
            with open(texture_file_path) as file:
                texture_sizes = read_texture_sizes(file.read(-1))
        except Exception as e:
            print(f'Failed to read \'{texture_file_path}\', unable to obtain texture size information.')
            raise e
    print(f'Texture sizes: {texture_sizes}\n')

    # Convert UV data from Xash' normalized half-float format to GoldSource's absolute int16 format:
    converted_count = 0
    print('Converting UV coordinates.')
    bodypart_count, bodypart_offset = struct.unpack_from('<ii', data, 204)
    for bodypart in range(bodypart_count):
        model_count, model_offset = struct.unpack_from('<ixxxxi', data, bodypart_offset + (bodypart * 76) + 64)
        for model in range(model_count):
            mesh_count, mesh_offset = struct.unpack_from('<ii', data, model_offset + (model * 112) + 72)
            for mesh in range(mesh_count):
                vertex_offset, skin = struct.unpack_from('<ii', data, mesh_offset + (mesh * 20) + 4)
                texture_size = texture_sizes[skin]
                offset = vertex_offset
                while True:
                    sequence_length = abs(struct.unpack_from('<h', data, offset)[0])
                    offset += 2
                    if sequence_length == 0:
                        break

                    for vertex in range(sequence_length):
                        s, t = struct.unpack_from('<HH', data, offset + 4)
                        struct.pack_into('<hh', data, offset + 4, round(half_float(s) * texture_size[0]), round((1 + half_float(t)) * texture_size[1]))
                        offset += 8
                        converted_count += 1
    print(f'Converted {converted_count} UV coordinates.\n')

    # Save the modified data to the output file:
    print(f'Writing \'{output_path}\'.')
    with open(output_path, 'wb') as file:
        file.write(data)
    print('Finished.')
#

def read_texture_sizes(data):
    texture_count, texture_offset = struct.unpack_from('<ii', data, 180)
    return [struct.unpack_from('<ii', data, texture_offset + (i * 80) + 68) for i in range(texture_count)]
#

def half_float(value):
    isPositive = (value & 0x8000) == 0
    exponent = (value & 0x7C00) >> 10
    fraction = value & 0x03FF

    if exponent == 0:
        if fraction == 0:
            return 0.0
        else:
            return (1 if isPositive else -1) * pow(2, -14) * (fraction / 1024.0)
    elif exponent == 31:
        if fraction == 0:
            return float('inf') if isPositive else float('-inf')
        else:
            return float('nan')
    else:
        return (1 if isPositive else -1) * pow(2, exponent - 15) * (1.0 + (fraction / 1024.0))
#


if __name__ == '__main__':
    main()
EDIT: Fixed the UV offset issue.
Posted 6 days ago2021-11-27 21:13:55 UTC
in Post Your Photos Post #346077
I have a DVD player that I use to view my burned DVDs.
Posted 6 days ago2021-11-27 17:02:03 UTC
in Post Your Photos Post #346076
Name of the equipments:

Sony system (WIP)
Aiwa system (WIP)

Sony PT-D3 - databank timer - released around '82-'84

Aiwa ZM-2700 - minisystem - released around '96

I use them to listen to music, alongside a quirky and weird Garrard/JVC clone.
Posted 6 days ago2021-11-27 16:59:58 UTC
in Post Your Photos Post #346075
Posted 6 days ago2021-11-27 16:58:38 UTC
in Post Your Photos Post #346074
Well, as promised, I was asked to post my photos. Here goes.
@fresco You are welcome. Thanks for having made a great mod.

Releases are now available on ModDB. For more information, please see the following post.
Posted 1 week ago2021-11-21 08:02:27 UTC
in TWHL Tower: Source Post #346072
Something of a TWHL tradition to have an extension or two. :D
UrbaNebula UrbaNebulaGoldSourcerer
Posted 1 week ago2021-11-21 01:43:01 UTC
in TWHL Tower: Source Post #346071
Ah an extension. Good 'cause I'm dragging my feet a bit and getting sent out of state for two weeks the beginning of December.
AndyG47 AndyG47Don't cite the deep magic, I was here when it was written
Posted 2 weeks ago2021-11-18 18:51:12 UTC
in eXperiment HL horror mod Post #346070
User posted image
hp version of the headcrab replasement
That probably means I guessed the wrong texture size.
Nope.
Or there's something else going on.
I strongly and sadly suspect this.
Perhaps you could share this model so I can do some proper testing?
Here is the model and the latest Paranoia 2 MV, so you can see for yourself what the opposite conversion do to the texture coordinates:
https://www.mediafire.com/file/m55rw1nnxtdbkin/attachment.zip/file
Thank you for your time (like... for 1000000th time helping me)!
Posted 2 weeks ago2021-11-17 15:13:26 UTC
in Sum Un-Downloaded Maps Post #346068
Civo isn't the only map series that I had planed. There's also something called Maran which is (Obviously) Marathon related/based.

I can't make custom entities so I had to skip enemy combat all together for this one and go over with puzzle solving instead.

EDIT:
DollyDolly
EDIT2:
Civo's 4 directional spriteCivo's 4 directional sprite
I fixed up my previous post so the code is now proper Python, instead of Python-esque pseudo-code.
For example, how to interpret 32.03125 ? It's not in the 0.0-1.0 range.
That probably means I guessed the wrong texture size. Or there's something else going on. Perhaps you could share this model so I can do some proper testing?
Note:
The ? symbol is an inline if.
This line here:
result = condition ? a : b;
...is the same as:
if ( condition )
   result = a;
else
   result = b;
Admer456 Admer456If it ain't broken, don't fox it!
Thank you for your answer!
However, there are two problems:
1) I need a PRACTICAL way to automatically convert ONLY all UV coordinates inside the .smd file, which have its own syntax and other data/digits as well.
I'm NOT even a beginner programmer!
I used M$ Excel to open the .smd and apply primitive functions to only the coordinates data.
To practically use the code you proposed, I need it converted as M$ Excel worksheet formula.
Or converted as Free Pascal code, so I can write my own program that read the .smd file and convert only the UV coordinates.
I can't "program" on anything else, anything new or anything the masses use nowadays :(
(The Python mark the ? symbol in isPositive ? 1 as an error and don't even compile, BTW.)
2)
Xash3D uses a new "half-float" UV texture coordinates inside the smd/mdl, while goldsource uses the old "fixed-point" UV texture coordinates.
Disclaimer: This is the only info I found, it's not my statement!
I'm not sure if it's true, or if there is more functions involved than just simple conversion from "half-float" to "fixed-point" (which I strongly suspect).
For example, how to interpret 32.03125 ? It's not in the 0.0-1.0 range.
In the latest Paranoia 2 MV, in the EDITOR tab, there is a button, that is supose to convert an old .mdl file with fixed-point UV texture coordinates to the new half-float .mdl (the opposite of what I want).
I observed what happened to the coordinates in the TEXTURE tab after such conversion, but couldn't figure-it-out/reverse-engineer-it.
Some enlargement/multiplying and 90-degree-rotation/U<->V-exchange and crazy shit like that may be involved :(
Due to 1) I can't test what you proposed for now.
I was hoped, that someone, who knows the exact process of conversion would post the true solution, someone who codes model viewers, like Solokiller for example.
Not a solutions based on my ASSUMPTION!
So, I'm stuck for now :(
Posted 2 weeks ago2021-11-16 11:28:48 UTC
in Adding a bit more enemies Post #346064
Editing existing map is a good way to learn.

For example, I adapted a map from the official Half-Life 2 single player campaign into a deathmatch map in *dm_tidal*
satchmo satchmoWhat you can do today should have been done yesterday.
Posted 2 weeks ago2021-11-15 20:57:39 UTC
in Adding a bit more enemies Post #346063
Yes, it's possible to change entities in existing maps. One tool that you can use is BSPEdit, which lets you edit the 'raw' entity data in a bsp file. Editing that data by hand can be error-prone, so you may find it easier to copy-paste it into an empty .map file and then modify the entities with Hammer or JACK, then copy-paste them from the modified .map file back into the bsp file (.map and .bsp files use the same format for entity data). Oh, and it's also a good idea to make a backup before you're going to modify a bsp file.
Posted 2 weeks ago2021-11-15 16:28:17 UTC
in Adding a bit more enemies Post #346062
Is it possible to edit the maps of half life 1 to include more enemies? I was thinking of doing that, since i wished there were more enemies in some parts
Posted 2 weeks ago2021-11-15 12:37:00 UTC
in eXperiment HL horror mod Post #346061
Awesome work so far on this, getting a real Deadspace vibe from it. Looking forward to seeing more
Posted 2 weeks ago2021-11-15 09:27:42 UTC
in Sum Un-Downloaded Maps Post #346060
Here's Civo in my style. Might turn this project into a 3DS game in the future.
User posted image
(Being in a Doom House for over 5 years can give you an itch)
Posted 2 weeks ago2021-11-14 18:52:17 UTC
in Half-Life Updated (custom SDK) Post #346059
I've been working to add a few new systems to the Unified SDK to make modding easier to do through configuration files instead of relying on hard-coded settings so much.

Here are most of them in action:
User posted image
These are all of the systems i've added, though some are not entirely finished:

String pool

This replaces the engine's ALLOC_STRING engine function, and changes behavior to allocate memory once per string, so calling it multiple times with the same string doesn't allocate more memory. Very efficient, this change also frees up a little memory in the engine's available memory pool.

It also no longer performs escape character parsing which required game_text to be changed to perform this parsing by itself. This behavior was inconsistent and could cause difficult to debug problems otherwise.

Better support for writing code that works on both client and server

The server's engine functions interface now has better support on the client which makes it easier to write code that works on both sides.

This also includes helper functions like Con_Printf which will unconditionally print to the console, and supports all of printf's format options (the engine's version is limited to C89 printf options).

Access to the engine's filesystem

The engine has a filesystem interface used to load files from game and mod directories. I've provided access to it, as well as a couple helper functions to easily load files without the risk of leaking memory.

You can use this to load files from the mod directory only if needed, for example server configuration files should never load from other directories to prevent custom and downloaded content from overriding it. Conversely you can also load files from all of those directories if needed, such as map configuration files.

Support for creating console variables and commands using unified syntax on client and server

The server requires you to create cvars whereas the client has the engine create them for you; i've created an abstraction that does this for you. This abstraction also prepends an sv_ or cl_ prefix automatically so you can have the same variables and commands on both sides.

You can set variables created this way using the new command line syntax :command_name command_value or :(sv_|cl_)command_name command_value.
If specified without the prefix it will apply to both the server and client versions. This also works properly for server variables which the engine will not initialize from the command line if you launch a listen server manually through the main menu.

Command functions can also be object methods by using a lambda to wrap it:
g_ConCommands.CreateCommand("my_command", [this](const auto& args) { MyCommandHandler(args); });

void MyClass::MyCommandHandler(const CCommandArgs& args)
{
    Con_Printf("%d arguments:\n", args.Count());

    for (int i = 0; i < args.Count(); ++i)
    {
        Con_Printf("d\n", args.Argument(i)));
    }
}
CCommandArgs is a thin wrapper around engine functions that makes it easier to work with commands by indicating which functions are available in all libraries.

Improved logging

I've added the spdlog library and set up the functionality to create loggers for subsystems. This allows you to log output with more control over how much is visible and what kind of output it is. As you can see in the screenshot above you can easily distinguish which system is logging something, and what kind of information it is.

This system loads settings from a configuration file. You can specify default logger settings so you can enable more debug output for all loggers, or even disable them all. You can also configure each logger individually.

There are console commands to list all of the loggers that exist, as well as to manually change the log level at runtime.

Angelscript-based scripting functionality

Bare bones Angelscript support has been added. The creation of script engines, contexts and modules is provided with error reporting for failure, as well as engine message logging, exception logging and proper handling for C++ exceptions including problematic behavior regarding longjmp (essentially C's version of exceptions), which could put the game engine or the script engine in an invalid state otherwise (note that longjmp does not seem to be caught by catch-all statements in VS2019, this used to happen in VS2012 but fail-safe logic should prevent the problem from occurring).

There is currently no scripting support for plugins and map scripts, but it's something i'd like to add if there's interest.

JSON-based configuration files

I've added support for loading JSON configuration files and parsing them. Error handling is done for you so if there's invalid JSON it'll be reported automatically.

I've also added JSON Schema-based extended error reporting for debugging purposes. This provides additional information when needed to indicate which part of the given JSON is invalid. It's only enabled with a debug cvar since it adds a lot of overhead.

Here's an example of the errors it will log (given an array instead of an object):
[startup] [error] Error validating JSON "/Defaults" with value "[{"LogLevel":"trace"}]": unexpected instance type
The JSON schemas can also be written to a file and used as input to tools that can generate JSON editors. This makes it easier to edit JSON and shows what kind of options you have.

I've also allowed the use of comments in JSON. This is a non-standard extension to the format, but is supported in most JSON libraries and the benefits are too good to ignore.

Game configuration files

Building on JSON support, there is a system for loading game configuration files. These are files that contain configuration data that needs to be applied every time a new map is loaded. This replaces server.cfg, listenserver.cfg and map change cfg files, which are mostly handled by the engine.

Additionally maps can have a config file as well. A file called cfg/maps/<mapname>.json will be loaded if the map with that name is started.

Here's an example of such a file used to configure the server for a new map:
{
    "Includes": [
        "cfg/shared.json"
    ],
    "Sections": [
        {
            "Name": "Echo",
            "Message": "Hello World!"
        },
        {
            //Commands to configure multiplayer server
            "Name": "Commands",
            "Condition": "Multiplayer",
            "Commands": [
                "echo Hello World from command!",
                // disable autoaim
                "sv_aim 0",
                // player bounding boxes (collisions, not clipping)
                "sv_clienttrace 3.5",
                // disable clients' ability to pause the server
                "pausable 0",
                // maximum client movement speed
                "sv_maxspeed 270",
                // load ban files"
                "exec listip.cfg",
                "exec banned.cfg"
            ]
        }
    ]
}
The Includes value is a list of files to include before the current one, and makes sharing settings between servers and maps very easy. You could for instance make a map series where each map includes a file that contains the shared configuration before changing some for specific maps.

Here are the contents of the included file:
{
    "Sections": [
        {
            "Name": "Echo",
            "Message": "Hello World from shared.json!"
        }
    ]
}
The Sections value is a list of section objects that apply to the game. Each section can have a condition associated with it evaluated at load time to determine whether the section should be used or not.

This condition is evaluated using Angelscript by wrapping it in a function:
bool Evaluate()
{
    return condition;
}
To prevent abuse this evaluation will time out after 1 second, so the server won't lock up due to some clever infinite loop trick.

There are currently only two conditions to check: Singleplayer and Multiplayer. I plan to expand on this with gamemode detection (deathmatch, coop, teamplay, etc) as well as checking the map name and the value of cvars.

The Echo section simply prints the message to the console, useful for debugging to see if your file is getting loaded properly.

The Commands section provides the same functionality as the cfg files this system replaces. It lets you provide a list of console commands to execute.
For security purposes map config files are checked against a whitelist to limit the commands that can be executed. This prevents maps from doing things like changing the RCON password or the listen server host's name.

This whitelist is loaded from another JSON file:
[
    "sv_gravity"
]
So server operators can manage this whitelist themselves if needed.

Though the configuration files for servers, maps and map changes are currently identical they are actually defined separately. Some will get sections exclusive to one or two of them in which case trying to use them in a format that doesn't have them will cause an error to be logged the console, but otherwise it will continue loading the file.
With this stuff implemented i can get to work implementing skill.json functionality and its map-specific equivalent. There are also a few changes needed to support things like Xen aliens fighting with Race X aliens (they're treated as allies by the game's code). Black ops have the same problem when it comes to fighting human military types (also allies).

I've also been updating the other SDKs to include bug fixes and improvements. There are some mistakes i made in Opposing Force that should be merged into any other projects that use that code.

There isn't much more work to do before a first release can happen. Since this is a lot of work i'll be doing an alpha release first to get some feedback, then at least one beta before a full release can be done.

That's all for now, feedback and suggestions are always welcome.
Posted 2 weeks ago2021-11-14 18:01:07 UTC
in Half-Life mods reimplementations updates released Post #346058
Thanks for posting and happy to see my mod (Times of Troubles) in the list. Will make sure to link you on my homepage.

(Yes, I just registered only to post this answer :D).
Posted 2 weeks ago2021-11-14 16:04:54 UTC
in Cowboy Up! Post #346057
I made a cowboy mutant for some sort of Lovecraft related mod.
User posted image
(The mouth bone is completely wrong tho)

When I go back to the mod then I'll replace this guy with something more original.
Posted 2 weeks ago2021-11-14 08:52:24 UTC
in eXperiment HL horror mod Post #346056
just some test of npc spawn methods
caption text
btw do you guys want me to upload more WIP stuff here ?
Nice. This must have taken a lot of work.
During 2015-2017, I released several projects that involved recoding Half-Life 1 mods from scratch. These projects are mostly known as Half-Life mods SteamPipe patches, which will now be referred to as Half-Life mods reimplementations.

The projects source code was released in the following repository with a branch for each mod.

Lately, a lot of restructuring has been made to the source code and after months of work, I am happy to announce that work on updating each project is finished.

For each project:
  • Source code has been reviewed and reworked for some parts
  • Almost if not all features were retested
  • All found issues were fixed
  • CMake support has been added
  • Project has been moved to its own repository
  • A Release is now available
In addition, a base repository has been created and will be used as a reference for each project.

Projects: If people wish to download and play the latest version, it would be appreciated. Any issue should be reported on the corresponding project repository.

Note: Each release does not include the full mod. You must install each original mod, and apply the release files on top of the original mod files.
Posted 3 weeks ago2021-11-12 21:39:10 UTC
in eXperiment HL horror mod Post #346053
Just few shots from the new maps ;)
User posted image
User posted image
User posted image
User posted image
User posted image
So i don't keep the thread empty for too long ;) hopefully will manage to upload another teaser video soon ;)
Posted 3 weeks ago2021-11-12 21:31:32 UTC
in Goldrc Horror FPS Project - Volunteer Post #346052
seams ambisius good luck ;)
Posted 3 weeks ago2021-11-12 20:56:39 UTC
in Sum Un-Downloaded Maps Post #346051
Ok so the CIVO project files wasn't gone and I can go back to where I ended. If someone has something to say about my mappack then go ahead and comment on the vault item, I'm eager.