sigmmma / vulpes Goto Github PK

We will also want to replace the default banning commands with commands that ban IPs because no one who plays this game has a legit key at this point.

These would be good to have.

• v_sv_ball_delete
• v_sv_ball_reset
• v_sv_ball_spawn

These objects should not be able to score.

The build script should take a config file so it's more easily customizable. Things like auto installation paths and toolchains shouldn't be hard-coded

We can fix the shader transparent z-buffering issue by giving them a z-offset. We already started on this, but we're going to need to disable this for camouflage shaders as it breaks the fade. Once this is fixed we can make it a default feature.

AI don't have infinite ammo in multiplayer, which results in them eventually just clicking their guns at their empty mags

All future lua important structures need to be converted to yaml. And there needs to be code to convert this yaml to cpp

Syncronize the Motd when a server administrator changes it.

This thing is big and perhaps a little messy. And thus it actually is broken in unexpected ways.

Every little thing needs to be tested.

Perhaps we could compile the mod as a standalone program that exists just to run it's tests.

Don't be like SAPP, front load all object updates on projectile spawn.

This is because of the game trying to look for an invalid scenario vehicle block. Instead, make it use the respawn info in the unit part of the object.

This respawn info can be used to make custom vehicles in custom maps respawn properly.

Synchronize all biped movement using their existing network objects.

Sync scenery object locations and permutations. (Mismatched permutations cause bump lag)

static PlayerTable** player_table_ptr = reinterpret_cast<PlayerTable**>(sig_player_table.address());
In some places you use static to cache values, but then reassign to that value every time, thus negating any benefits you'd get from caching.

SAPP did it, and it improved hit registration by letting the server get more accurate ping timings.

These things all need hooks (Some are also listed because of completion's sake.)

• Incoming Packets
• Bipeds
• Vehicles
• Weapons
• Equipment
• Garbage
• Projectile
• Scenery
• Machine
• Control
• Light fixture
• Placeholder
• Sound Scenery

Will allow for better assault gametypes and fix a lot of bugs.

When there is a heavy amount of object spawning in a halo game they might not be cleaned up properly and stay in the client's game.

Do NOT copy an existing API.

designing a permissions system that we'll eventually use for chat commands and rcon.

A good way to differentiate between player commands, moderator commands, admin commands. Potentially also for things other than commands.

Something that can be sanely set up through commands and has sane defaults.

This also involves saving permissions to a file inside the Vulpes folder.

Blacklist people who try to brute force the rcon password from using rcon commands.

When you throw a grenade and die before it gets released it does not sync.

Add a command to enable anisotropic filtering with an adjustable level of anisotropic filtering.

When there are no netgame flags for flag locations in CTF the game/server crashes and burns.

https://github.com/gbMichelle/Vulpes/blob/5d0f7545748e71d124f630111f1576728167c5b2/halo/memory/gamestate/object/object_device.cpp#L10

v_sv_hill_move
v_sv_hill_timer

I caused this. This issue is just so I have an issue to point towards. I might fix this one day. Might.

Syncronize the detonation effects of projectiles that detonated before they could be synced.

Synchronize all fired projectiles and turn off client-side projectiles.

I dreaded this, but this seems to be the best idea for keeping our source files less messy.

Currently it only prints one argument. This is because of the old implementation of colored printing. Which is removed now and could also be implemented better.

Set a max amount of packets per second, per ip address.

Right now console_out directly executes game assembly to get the console text to appear on the screen. Recently in the code cleanup we mapped out the console memory structures which should allow us to directly write these outputs to the table in memory that handles them.

This will also allow us to more efficiently take formatted input, as right now all formatted console messages use snprintf to a buffer on the stack of the function that needs to make the print.

Respawn them whenever they end up outside of the BSP bounds.

There is a lot of bad things going on in there that need to be addressed.

It was written when I only barely understood the parts of the language that I was using.

We should use std::filesystem or something similar.

Right now @gbMichelle can't use std::filesystem because it requires a newer version of mingw, which isn't available on her current operating system. And in her (my own) words "Building this fucking sucks."

Basically the same functionality as the -execute startup argument. Except for you can execute as many as you want.

Note: Make it so that a file can't execute itself. That would be bad.

This will require the implementation of a permission system too.

Certain characters or sequences in player names can screw up the scoreboard or other related things. Block/remove these characters on join so this cannot happen.

After a while, the server will stop announcing multi-kills.

We need both a way to store lua scripts in map files. And we need to sandbox those lua scripts so the require function in lua only looks in the map file.

The user input used to execute the command does not end up in the history buffer, which ends up being an inconvenience when needing to execute the same command multiple times.

Weapons can get stuck on scenery objects and that fucks with the existing sync.

When damaging a vehicle with a player in it it does not register as the player inflicting the damage onto the player, similar issue with vehicle destructions.

Maybe like a second arg that is of type bool* (bool pointer) since we can only return one thing at a time.

Forcefully kill these bipeds and clear the player slot.

Simple system to set and retrieve values.
Some settings are global.
Some settings are per user.

Needs to save somewhere in the vulpes folder. Vulpes folder can be found in vulpes/memory/global.hpp profile_path() + vulpes/paths.hpp VULPES_PATH. Feel free to add your own sub folder in there.

I am fine with inputting a string for user so your system doesn't need to handle that part. If you do feel interested, the current profile name can be retrieved from vulpes/memory/global.hpp through active_profile_name()

Unit tests can be done with catch.hpp. When adding it to the project I'd put it in util/

Right now we've disabled many characters that could pose a threat when loading lua scripts. But as a result map lua scripts that are outside of maps cannot share scripts as they can only read them from the current folder.