a Request for obtaining current blockdetails would be rather nice. A basic version for just <itemname><itemid> And maybe? an advanced version for obtaining all information (everything from model, hp, usuable on, stacksize (etc.. everything from the .ecf file + more)).
The Mod-wrapper should likely look for mods going into an infinite-loop spin, and shut them down. While it in the end is on the modders to prevent it from happening, perhabs it would be wise for the game to play overwatch on it?
A way to register for keypresses; For instance 'register for when user uses scrollwheel' Or 'register for when user press ctrl+a' (Or some other keypress combination). This should be a request, that the mod sends to the game. The mod would then receive a 'kepress event', with the keycombo, if any user presses it. (Effectively like the chatmessage command, but with keycombo, rather than msg) I think a register-scheme would be better, than just flood a mod with every keypress of every player...
Adding users localization to the player info event. (Ie. being able to tell what the user have (his) game's language set to)
This isn't an API suggestion but it's related: Allow modders to submit their mods to Eleon to be included with the server download and add a way to disable which mods your server uses. For example: Create a yaml file in the mods folder that has all the mods set to disabled and the users can enable whichever mods they choose. So that those server hosts that Don't allow DLLs can still use mods.
Doesn't this kinda defeat the concept of 'modding'? Either something is included as part of the game, or it is a modification, no? (An example is EAH: it's effectively part of the game, not a modification)
The mod portion of EAH comes with the server download but you have to move it to the mod folder to enable it, my suggestion would mean the mod comes in the mod folder but it's disabled in a setup file. Since most server hosts block sending DLL files over ftp, most server hosts are blocking mods, even the One that is included with Empyrion. None of my mods would ever pass the approval process, obviously.
Mm, I suppose this is a fair point. Although I'm not sure that the 'most server hosts are blocking mods' are accurate? If so, I see why your approach could possibly be smart.
I've been compiling a list of hosts that support Empyrion AND allow DLLs. I have found or heard about three. All three Say in their support pages that you have to email the DLLs to support in a zip file. I haven't actually talked with anyone at these hosts to confirm yet and haven't heard from anyone working in this project with me so we don't know these three allow Empyrion mods for a fact. I personally have checked 8 hosts, by reading thru their support pages... All their support pages and searching thru their forums.
I'd love having an event, for when a player have *consumed* something. Should return what is consumed (and possibly how it affected the players stats?)
I ask for the event model Api to add the ability to intercept calls with its own processing of events, and then return to the standard handler if necessary
now all the game logic of the player occurs on the gaming client, not on the server, the server processes only the transmitted data from the client, and trusts the client. this of course is not correct, as it opens up opportunities for cheating.
Hey, what do you mean? What changed? Are you speaking of Game-Client or API-Client (since this is the API section). Can you give an example?
it's me about the engine Unity ) the current implementation of the server does not allow you to fully manage the client's data, since they are processed on the gaming client. in fact the server is a proxy server that transmits data between clients. to make the client do something, you need to write in the game client some code that will listen to the command from the server. and on the idea of multiplayer games should be the other way around, the server must process the data, and the client only visualize the situation.
if the client sends a command to the server that he picked up somewhere 999 gold bars, the server will simply record - the client picked up 999 gold bars ... where did he get them from? The server does not store this data. When a player opens inventory, the server does not send data to the client at that time, which should be there, except when the player opens an external box. but even then the server does not control how much of one box was reduced, and how much was added to the player, he simply accepts the data that the client sends. if I'm wrong, correct me)
I'd really like to have a POI discover event. This can ofcourse be accomplished by keeping an internal list, and checking quite often players distance to all POIs, but it seems a little silly to waste this much processing & storage, on something the game already manages. (containing POIentityid, playerid)
Having an event for player consumes could be handy. Player consumes <any consumable> => entityid, itemid / itemname
There is a tradeoff for both approaches. A multiplayer where the server is authoritative, and does ALL calculations (including collision detection, local AI etc) is safer against cheating, but also way slower to respond, and also much more taxing on the server. A rich client, that just reports state-changes is the better (responsive) experience for the player, but also unsafer. (and can lead to desyncronization between two clients doing actions at the same time) Even in WoW, the client does the movement-logic of the player locally, and the server is then just doing a sanity check and transmit that state-change to the other clients. (else the player-movement would feel much more laggy). ..Both approaches work in Unity btw. Its a question what networking solution is chosen.
