Initial Integration of DAPI #7983
Conversation
This commit adds the DAPI server,the ProtoClient that the server uses to communicate with a front end client, and the supporting SFML networking files, with the necessary CMake file changes to integrate the new files. Some code was moved from anonymous namespaces in DevilutionX to the devilution namespace so that DAPI server can access them. This builds, but crashes at the SFML initialization.
Change to newest SFML and fix linkage, additionally fix the DAPIProtoClient to be SFML 3.0 compatible.
Loop crashes (in debug build only somehow?) for selecting monster types when playing Diablo mode due to less monster types being available. Fixes Griswold data not being sent client side due to extra blank entries in Towners struct.
Fixes compatibility for the inventory manipulation functions for DevilutionX.
This allows DAPI to interact with the menu in game.
| if (devilution::gbIsMultiplayer || !devilution::gmenu_is_active()) | ||
| return; | ||
|
|
||
| devilution::gmenu_presskeys(SDLK_DOWN); | ||
| devilution::gmenu_presskeys(SDLK_KP_ENTER); | ||
| return; |
There was a problem hiding this comment.
DevilutionX has quick save:
if (devilution::gbIsMultiplayer)
return;
gamemenu_save_game(false);There was a problem hiding this comment.
Does it make the menu sounds though? I could just add a menu sound in like I did for 1.09 though. 😆
Edit: I also like the "saving game" notification that pops up, just like it would for a human player.
There was a problem hiding this comment.
The human player can do this, it's bound to one of the F-keys by default (F2 i think).
It shows the notification, but no it doesn't play the sound.
Frontend uses the custom defined windows message values that 1.09 uses internally. This translates the equivalent DevilutionX messages back to the expected values.
Fixes CMD_OPOBJXY and CMD_DISARMXY which are sent with a different NetSend command in DevilutionX.
Fixes Inventory pasting and refactors it based on how DevilutionX works internally. Also fixes Adria's sell window storing wrong OldActiveStore.
Adds an enum and to the frameupdate message so the frontend can know what backend it is attached to. Needed since DevilutionX has some differences such as TileIDs and Pepin auto healing, etc.
This makes placing items from cursor functional as it fully accounts for how DevilutionX handles item graphic cursors (the cursor point is considered in the middle instead of top left)
Store options are built even if quest test is being displayed, so this prevents a DAPI AI from using a store while a quest text is up.
Enable compiling SFML from source
Fix towners to that cows don't get squished into one entity.
Fixes the Monster Name passed to client and fixes buying items from Adria.
Fix quest text by adding a space between the line breaks.
Fix issue where magical items can have repair cost under 1 gold, and thus not be eligible for repair.
Need to explicitly check if HoldItem is empty in DevX
This actually fixes repairs (and selling), using CurrentItemIndex correctly and doesn't double dip into the players gold for repairs. Also fixes Cain identifies as before the store wasn't being re-ran after identifying an item.
Fixes issue where player information was being given when players were not on the active floor.
Add CMake option to opt-in to DAPI
Moves three chat log items to devilution namespace and adds commands for reading from and writing to chat.
|
Hrm.. maybe the clang-format check shouldn't be looking at the protobuf files? |
|
Indeed, competition of the API for AI agents! :) For this protocol approach, it's unfortunate to have massive duplication of data and types. @NiteKat, have you considered generating protobuf from the current structure definitions? I'm not sure if SWIG is the right tool, but there is probably something available. However, considering the age of the game, the fields won't change that frequently, if at all. Anyway, looking forward to either of the variants being merged. |
| { | ||
| "name": "DISCORD_INTEGRATION", | ||
| "value": "False", | ||
| "value": "True", |
There was a problem hiding this comment.
Which commit is that from? When I build I don't have the patch.exe or whatever is needed so I typically don't build with discord integration. I leave out that change in the CMakeSettings.json when I push, but maybe it slipped in on accident on a push?
There was a problem hiding this comment.
I reverted this when I introduced the DAPI configuration into CMakeSettings.json. Instead, the DAPI configuration disables Discord integration, for NiteKat's benefit.
There was a problem hiding this comment.
Thanks! I think it makes sense to have that integration disabled on the DAPI configuration, seems like you wouldn't really need (want?) the discord features for the AI clients.
Probably not since those are generated, though in the long run they may not be included in PR. Since they get generated when you build, they could be generated directly into the build folder and referenced there, but it would be weird to then look at the code before that build is run because all of the protobuf generated functions will give the IDE heartburn until those files are generated. |
I see no reason why there can't be room for both! The data duplication is due to stuffing the 1.09 backend into DevilutionX to get things working. I could probably convert it to work more directly with the DevilutionX data. But I don't want to give the full information as I want the server to be acting as the mediator determining what a connected AI agent should and should not know. In 1.09 it was nice to duplicate the data being sent to the AI since then when executing commands or needing to check things I don't have to reinterpret_cast in every function. With more direct access to the code and variables, that may not be as much of an issue. Something I'll revisit toward the end of this integration I think. Item tracking though I assign IDs to items that don't exist in game, so I need to do some duplication there, but technically I could only track the three fields the game (and I) use to unique identify an item, since they don't exist as unique entities themselves and are instead just data passed around to different "buckets" so... I dunno. Something to look at down the road I think. 👍🏻 |
I'm not sure I understand. The C++ files are generated from the proto files, but are the proto files generated from something else? Also, are you saying they may not be included in the PR because you're considering deduplicating the data based on your discussion with rouming? FYI, the |
|
clang-format does support The easiest way to do this is to probably add a |
| @@ -0,0 +1,73 @@ | |||
| #pragma once | |||
| #include "Item.h" | |||
|
|
|||
There was a problem hiding this comment.
This is missing #include <map>, hence all the clang-tidy warnings
Oh sorry, I thought you meant the C++ files that get generated from the .proto files, but it looks like I'm confused as I don't see those files in the project so I think they got removed already, or generally aren't committed? I'll look into it a bit more, but I thought you were saying to not apply the clang-format check to those generated files, not the .proto files. |
This will need to be changed again to fix longer chat messages, but as long as a message doesn't trigger wordwrap in the message log this works.
Adds Map Include to Player.h to remove clang-tidy warnings
This commit adds the DAPI server, the ProtoClient that the server uses to communicate with a front end client, with the necessary CMake file changes to integrate the new files.
Some code was moved from anonymous namespaces in DevilutionX to the devilution namespace so that DAPI server can access them.