eldewrito / dewrecode Goto Github PK

I wonder what's the best way to do this. We should probably include Packet / PacketSender / PacketHandler etc in the SDK for plugins like ChatPlugin to use, but I wonder about people who might be missing plugins. If a server is running the ChatPlugin and sends our custom chat packets to a client that isn't running the plugin I'm guessing it'd cause issues.

It'd be nice if we could mark certain packets as optional / required, maybe patch stuff so that if a packet isn't registered it'd just skip the packet, and have a custom packet built into ED's dll that sends a list of the clients registered custom packets to the server, then the server can check if the client has the required packets and drop them if they don't.

I'm thinking of this mainly because chat isn't exactly required, and some people might not want ChatPlugin enabled for whatever reason, so chat packets should be optional. But if we started work on an anticheat which would send data back and forth to the server then the client should be required to have those anticheat packets registered.

Then there's the issue with packet IDs, eg. if the server has ChatPlugin packets registered as ID 0x10 and anticheat packets registered as ID 0x11, but the client only has anticheat loaded as ID 0x10 then that'll probably cause some problems.

Not sure of the best way to solve it, but we should probably figure something out since plugins should be able to register packets imo, and users could be using any combination of plugins in any kind of load order so we can't really rely on the packet IDs much...

Maybe the custom packet I talked about earlier could be used for this, the client would send a packet to the server listing each custom packet ID/packet name/originating module, then the server would match up the packet based on the packet name and temporarily change the packet ID just before sending to that client. (not sure if I explained this well enough.. probably be hard to do anyway)

Another way I'm thinking of is the reverse,

Maybe when a client connects to the server then the server would send some sort of info/meta packet which details the servers replicated cvars, loaded mods etc, and the servers registered custom packets in order (with each packets ID/name/isOptional etc).

Then when the client receives that it would go through each one and see if there's a packet registered in our custom packets stuff under that packet name, if it is then it'd register it properly with the game, otherwise if we don't have it and it's optional it'd just register some sort of null packet for that ID, but if it's not optional then the client would drop connection (should probably check this on the server side too though). For this we'd need a way to deregister custom packets from the game after clients disconnect though.

Any thoughts?

As far as I know there's only the VoIP UI, RCON/WebSockets and HTML5/CEF menus left to port over, and any changes beyond commit ElDewrito/ElDorito@61e497c.

The issue with the VoIP UI is that it used a lot of the same functions as the console/chat UI did (eg to draw boxes and such), and since the VoIP stuff is now in a different module to the console UI we can't simply call those functions.. we could always just copy them into the chat module, but then we'd have duplicated code in the codebase.

Does anyone know if the VoIP UI was actually functional in ED? From looking at the code it didn't really seem to be, but I hadn't really tried it out ingame yet.

Is it even necessary now we have HTML5 menus?

When using Connect iphere the check that trys to check if your on the mainmenu ALWAYS says your not. Also, when using host commands like Server.Cheats it doesn't seem to understand when you are the host/or in the lobby like it asks.

(Probably just unfinished code but I thought I would report it anyway)

Halo online disables a lot of HUD strings for weapons and equipment, but they are still there, even for the DMR. Thing is, this bug will become more of an issue in the future, because this is what's preventing the dual welding weapon pickup/swap text from appearing and the same for equipment. The text that does display on the right is handled by the weapons CHDT and can easily be removed so that it doesn't clash with the old dual welding text.

Doesn't allow you to even move I think this is just the rest of the code isn't there yet but I guess i'll post it anyway

Switching to Online. Sometimes crashes the game. (Release build)

I'm not really sure that the ModuleBase class is very helpful from a design perspective. Basically, from what I understand, it looks like it gives you access to the "main" ElDewrito interface objects, but it shouldn't be doing this through inheritance. Inheritance is intended to model "is-a" relationships, but we're only using it for code reuse (in fact there's nowhere in the codebase where a ModuleBase pointer is even used). You could argue that it indicates that a class "is a" module, but the term "module" is extremely vague and just covers up the fact that "modules" have way more responsibilities than they should. The problem with this, then, is that it leads to things like ModuleConsole.cpp having over 1k lines of code in it or ModuleForge having a disgusting-looking hook function inside of it. What if another piece of code wants to trigger a Forge delete operation, for example? It shouldn't have to execute a command to do it, which is clunky and requires string manipulation. We should never have to run commands internally to accomplish something which could easily be done if we had a properly-structured codebase.

In order to maximize reusability and keep our code simple, we need to clearly separate the different layers of the system instead of combining everything into "modules":

• Hooks should be objects which are completely isolated from the rest of the codebase (because they're nasty) and have very few dependencies. They should simply either be event sources or provide public methods which can be used to control them. Hooks should never ever have to know about the command system being present. (Though whether they should be able to access named variables is debatable.)
• The command system should just be a layer on top of everything else. (That is, you could take away the command system and have everything still work.) Each command should only be a few lines of code long and use classes/functions lower in the hierarchy (parse arguments, call function, output result). Additionally, we should be using std::function for command function callbacks so that commands can access non-global state. Commands could be created through an "ICommandRegistrar" interface of some sort which takes care of putting commands in a namespace corresponding to the plugin name.
• If we want to keep the variable system the way it is currently, we need to separate the variable and command systems such that the variable system is much lower in the hierarchy. We can have something like an IVariableStore which stores variable names and values, and then the command system can access that when the user requests to get/set a variable. When a variable is updated, the store would fire an event. This would decouple variable accessors from the command system.
• Any UI code (drawing the console, etc.) needs to be completely separated from everything else so that it can easily be disabled all at once in a dedicated server environment. I've thought about possibly using some sort of 3rd-party library (e.g. librocket) for stuff like the console and chat until we get further with the embedded Chromium renderer.
• There needs to be a class whose sole responsibility is to provide interface objects to a plugin (and to internal code as well). We can pass a pointer to it to the InitializePlugin() function and leave it up to the plugin to use it how it likes. In its simplest form, it could just have a pure virtual CreateInterface() method, but I'm not necessarily sure I like that because then you lose type safety by having to cast a void*. I'd rather see it expose a function for each type of interface that can be retrieved.

TL;DR, frankly what I'm getting at here is that we need to stop making this so monolithic that it's impossible to reuse code outside of modules. The current system still makes things way too difficult to extend easily if we want to add business logic like variable synchronization that isn't tightly coupled to the console. Granted, it's a step in the right direction compared to the original codebase, but there's still a lot that needs to be done before I'm comfortable using it.

Any thoughts?

All(?) of the equipment items still seem to be around, with mods they can even be thrown/activated by throwing grenades, so we know they still work.

Seems like the code which auto-pickups / asks if you want to swap is removed though, and it's likely that the action/event/button handler for throwing them is gone as well. Would probably take some work to add these back in.

It shows in the mainmenu. And even when you use the forceload command but when you create a server from the lobby it doesn't.

Eg. binding F1 to "Console.Show Console" will show the console fine, but if you close the console and press F1 again nothing happens, but when you press it once more it shows up.

Same with "Game.SettingsMenu" or "Console.InputBox" etc, pretty much any command which hooks KB input and stops the game from receiving keyboard events.

Using the equipment branch, if you pick up equipment and then walk over a different type of equipment it'll cause a crash.
Throwing equipment and then walking over the same type of equipment will also crash.

Both crashes happen at 0x5399BC, this func gets called every tick though and seems to interact with object globals, not sure what it's doing with them though.

Running the 'help' command (and others I'm sure) overflows the 4kb buffer in the DebugLog::Log function and crashes the game. Will need to stream or perform multiple passes over that buffer when writing text to the debug log.

Players always spawn with 2 grenades, no matter what options are set. I also heard that you can't make people spawn with no weapons, but I can't confirm that.

DX9 is still inited/used in dedicated server mode, trying to run it on a WinServer box with no graphics card stops it from running, with the last message in the log file saying "Core.Direct3D.Init event triggered"

If we want proper dedicated servers we'll need to stop D3D from being used somehow

Not much of an issue, unless you consider the assassinations an issue. But having a toggle for assassinations would be nice. Maybe 3 states 1. Assassinations allowed 2. Only beatdowns. 3. No insta kill from the back. I know an edit has already been made to disable assassinations so I don't know the difficulty level.

Not sure what could be causing this, but seems to happen 100% of the time with dedis.

ChatCommands is pretty hacky atm, the code for defining commands is really ugly too, and there's nothing for multiple arguments atm.

It'd be better to change them so commands are similar to Commands from CommandProviders, maybe we could even extend CommandProviders to support chat commands in addition to console commands... Not sure if that could be contained in a plugin, but if we built that core ChatCommands functionality into DR then plugins can easily add their own chat commands too, any thoughts?

I know that this isn't required as the current one works fine, but I've had a lot of requests for this now and it's currently beyond me. The scoreboard seem to be having an issue listing players but everything else seems to function, everything else being team scores, winning team display and titles.

Edit: This'll likely be the best way to handle the scoring with multi-team if that ever comes back.

When the game starts up I get a weird squeak through my headphones, only lasts less than a second but it happens every time the game starts.
Also seems to happen with latest ED, not sure if it was something added to ED recently (and ported over to DR) or if it's maybe Win10 related.

Some strings get prefixed with "@_":

• If you get negative score it'll be shown on the podium as "@_-1"
• Editing strings in the SSL files can sometimes make "@_" appear in front, eg editing "ingame_ui_leave_game" to "HALO 3 MENU" shows up as "@_HALO 3 MENU"

Seems like it tries looking it up as a string ID, if it can't find it then it puts "@_" in front for some reason.

I'm aware that the respawn counter was removed very early on because it came with all the loadout stuff, but a dev told me that the Halo 3 counter alone was still in the game. Hopefully if it can be enabled it'll fix some other bugs related to the death camera.

Game crashes when changing resolution, luckily the resolution gets saved first so restarting will change it.

Likely something to do with the DirectX hook, not sure if ED has the same problem too but I think I can remember it happening once with it.

The crash seems to happen when the UI_MenuUpdateHook is called, after the Tick function creates the UIData struct and sends the notification etc.

Not really sure what could be causing it, I remember that hook used to crash in ED because we were calling the UIData stuff from a different thread, but after making it use the same thread as the game loop it worked fine. AFAIK it should be using the game loop thread in ED too, so I'm not sure why it's crashing.

Also not sure if it might just be my environment, if someone can test a release build and report back it'd be appreciated.

Maybe we should mention that it's required to make the mods\plugins\ folder.

Also,

1>------ Build started: Project: DewRecode, Configuration: Debug Win32 ------
1>     Creating library E:\Projects\DewRecode\Debug\mtndew.lib and object E:\Projects\DewRecode\Debug\mtndew.exp
1>ModuleMain.obj : error LNK2019: unresolved external symbol "public: __thiscall Modules::ModuleDebug::ModuleDebug(void)" (??0ModuleDebug@Modules@@QAE@XZ) referenced in function "public: __thiscall Modules::ModuleMain::ModuleMain(void)" (??0ModuleMain@Modules@@QAE@XZ)
1>E:\Projects\DewRecode\Debug\mtndew.dll : fatal error LNK1120: 1 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Some people might not understand "Press ENTER to confirm", and having a button there would let us get rid of that text too.

In infection Hide and Seek the zombies have radar enabled while humans have it disabled, is this how it was in Halo 3? Doesn't seem right imo since zombies shouldn't be able to find where humans are.

It's partly done, got a flag for replicated cvars and code that writes them into the info server JSON, just need to find a way to know 100% that the client connected to the server so we can make sure we apply these cvars only if we need to (ie. only if we've connected)

Also maybe a way to rollback the cvars once the player disconnects, not sure how necessary that'd be though.

Weapons still seem to have the required flags set, not sure if the game is actually reading those flags though.

Not even sure if the game still has code to print the second "Press X to dual-wield" text on the HUD. I'm pretty sure I heard early on that HO was having dual-wielding as a special ability / P2W option though, but I can't find anything about it anywhere.

So we should finally discuss this properly, in the public eye instead of behind closed doors. Most people probably know I'm against a login-based system, while I know most others are for it. I think we should come to a decision before people spend time on things that might not be used (eg the entire stats portion..)

The way I see it, a login-based system provides authentication (proving a user is who they say they are) along with authorization (being able to check if the user has special access to certain permissions/things). A key-based system would only allow us authentication, which IMO is all we really need.

I know some people are wishing for a "dew ID" kind of system where you can claim your ingame name and nobody else can use it, along with permitting special things for this ID (such as special armor effects for devs etc), I'm not really for that -- I do this work because I enjoy doing it, not because I want to be rewarded in any way. For ingame names I always wanted a system sort of like steams, where players are identified by some other unique attribute other than their name, so their ingame name could be anything they want even if it's already taken.

The beauty of ED right now is that someone can easily take our code, edit a single int and they'd have their own fork of ED running fine separate from our main ED. In seconds they could spin up a master server with Docker and even have a server list for their game up and running.

If we were to make it use a login-based system I can see the server setup being a lot more complicated, you'd have to make sure that your server is secure and there's no way for anyone to steal the user database, and I doubt many people would be able to make their servers reasonably secure enough.

The main issue I see with a login based system is that no matter what we'll need a central server to store the user database, maybe this could be supplemented with other servers sharing the same data etc, but then that brings the risk of the data being stolen up by quite a lot.

I don't see why we should have to worry about keeping data secure when we don't even need that data in the first place, like said above we only really need to authenticate the user, and with a crypto based system we can do that easily without needing to store any data ourselves. Master servers put up by the community wouldn't need us to share any secret key with them or anything, they'll be able to work as a single unit without needing any connection to us.

The only real issue I can see with a crypto based system is key loss, and that could easily be solved by allowing master servers to store the users private key (encrypted with a password) tied with their email address. This way masters won't be storing any sort of password hash, only an encrypted version of the players private key. If the user loses their key they can request the master to send it to them, and the master could send that encrypted key blob to the users email (which makes sure the only recipient is the actual owner of the key), the user would copy this blob as "keyrecovery.txt" into the ED folder, and then ED would ask them for the password for the key (ensuring the key is decrypted by the client, instead of having the password sent to the server for decryption).

I'd be fine with this way, it's a lot like a login-based system except there's no passwords or password hashes stored, and all the masters could hold these encrypted private keys instead of needing to rely on a central server. With reasonable enough encryption it would make bruteforcing/decrypting these encrypted keys very hard and CPU heavy compared to simply cracking a password hash, meaning if a dump of these encrypted keys got out they'd have a much lower chance of being cracked versus a dump of password hashes.

Anyway I don't want to push my views on people, this is a community based project so I'd like to hear peoples thoughts on this.

Refer to the following article to restructure the interfaces for better usability and expansion. CTRL+F to "Finishing polish" for the good stuff. Any thoughts/concerns?

http://accu.org/index.php/journals/1718

I see you've "fixed" displaying the Media\Settings menu. Are any of these settings really needed? It seems like most of the options available just crash the game.

Game crashes on exit with a debug assertion error: http://i.imgur.com/POm7cDz.png

Might be to do with the way the VirtualKeyboard class is allocated, from the CreateKeyboard func (which gets called by the game at startup):

// Does this need to be allocated properly by using the game's malloc?
return new VirtualKeyboard(file, line, unk2, unk3, unk4, unk5, maxLength, unk7, unk8);

Strange how we never had this issue with ElDewrito though.

It works in the sense it resets your camera in first person but third person for vehicles it breaks. What it normally did was fix the view for both now it doesn't.

At the end of the json http://i.imgur.com/eoxfmEF.png
probably from a copypaste