es3n1n / portal2-internal Goto Github PK

https://github.com/es3n1n/portal2-internal/blob/multiplatform/portal2-internal/sdk/enums/e_cmd_buttons.hpp#L5

should most defined be a uint32_t

The air control fix thing that removes the speedcap Only seems to work for vanilla portal. Doesn't work on portal stories mel or Portal reloaded just crashes when you try to enable it

why?

https://github.com/es3n1n/portal2-internal/blob/master/portal2-internal/hack/cfg/cfg.cpp#L154

if the user of the api forgets to add the type to the macro defined above we get an unhappy customer and a bunch of uc threads

I say we use a std::map or something, and let the user define whatever the fuck he wants; after that the serialization goes automagically with iterators thru the map..

the first time i injected it with cheat engine everything was fine but after that it never worked again

https://github.com/es3n1n/portal2-internal/blob/master/portal2-internal/util/mem/mem.cpp#L12

possibly would be better to use memcpy_s

https://github.com/es3n1n/portal2-internal/blob/master/portal2-internal/util/logger/logger.hpp#L17

std::format is constexpr; explicit string formatting vs vsnprintf seems like a good deal

a modern sdk should have cmake support, because vcxproj is xml bullshit.

gcc has the -Wno-attributes flag..

gcc doesn't seem to support attributes for shit anyways (at least not for struct members, that is).. less macros = good, but more compiler flags = bad.. your call, man

This should be a truth table, with the values assigned at the top. A temporary color_t construction would be clearer, imo:

[[nodiscard]] color_t from_hsb(float h, float s, float b) {
   color_t tmp{};
   //
   //
   //: do stuff..
   
   switch(h):
      case 1:
         tmp.r = ...;
         tmp.b = ...;
         tmp.g = ...;
         return tmp;
      case 2:
         tmp.r = ...;
         tmp.b = ...;
         tmp.g = ...;
         return tmp;

et cetera.

• done / fixed / invalid

Those should be uint8_t. So should be the parameters in member functions.

• done / fixed / invalid

This is highly unsafe. This probably should just error out on shit data.

• done / fixed / invalid

I suggest this:

    std::uint32_t get_hex() {
        auto get_hex_byte = [&](std::uint8_t field, unsigned shift_amt) -> std::uint8_t {
            return (field & 0xff) << shift_amt;
        };
        
        enum {
            ALPHA = 24,
            RED = 16,
            GREEN = 8,
            BLUE = 0
        };

        return  get_hex_byte(this->a, ALPHA) |
                get_hex_byte(this->r, RED) |
                get_hex_byte(this->g, GREEN) |
                get_hex_byte(this->b, BLUE);
    }

• done / fixed / invalid

Throughout the project you use #pragma once directives.

These were not supported by GCC. (Yeah, it was a long time ago. Poor little GNU compiler). Still, the #ifndef MY_SHIT is highly preferrable.

• done / fixed / invalid

• Why not using create_client_class_fn? more modern shit, looks cool, LSP's love them.

• Should these be publicly available?

• done / fixed / invalid

Clang optimizes these away. This just restricts the usage availability.

• done / fixed / invalid

There's probably a lot more that needs to be done, but these are the only ones that i've found.

performance is cool

heres some food for thought i definetly wrote myself:

https://godbolt.org/z/5jnE34v16

you're using static_cast's on floats a lot here, would be cool to handle the edge cases.

the greatest p2internal cheat needs to have a (SEH/VEH/stack unwinding) little thing to handle da crashes so that the crash log might actually be useful in the github issues...

you're already using nlohmann's json, you probably should license the code provided..

rn the _dir is c:\\portal2-internal which, well, fucking sucks for a lot of reasons

1. can we force the configs to a user folder, so that in unix-like systems down the line the config doesn't just create a folder in root directory?

2. can std::filesystem resolve paths in compiletime? if so, resolve in compile time we should

https://github.com/es3n1n/portal2-internal/blob/master/portal2-internal/util/hash/fnv.hpp#L34

^^^

Doesn't the __forceinline here suck?

Should we inline this in the first place, even? I assume this is going to destroy the optimizations of clang/msvc once we get a lot more config variables.

We/you probably should avoid compiler extensions.

Good work, big man.

When you press insert and open up the menu mouse cursor stops working.

e.g. https://github.com/es3n1n/portal2-internal/blob/master/portal2-internal/util/input/input.cpp#L19 can be written as

`[[clang::stdcall]] unsigned long wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) {

https://github.com/es3n1n/portal2-internal/blob/master/portal2-internal/util/math/base.hpp#L12

the "double" is being implicitly used under the hood already.

if we force the users of the api to use the double precision type our customers will be much more happier.

DWORD vs uint32_t (u32). should be a no-brainer.

how do you download and install/inject it