Possibly make most, if not all, types have defaults. (null / something that would make sense to be the most default used). Usecase: (one of many, I'm sure): If you don't define one of the buttons for the popup, it simply assumes 'null', but if neither, it sets one of them to null, and the other to 'close' (or something along those lines)) Furthermore, allow all types to pass a dummy object, that is returned upon completion: Rather than having to have temporary lists galore, that keeps track of what was sent with a certain request, allow to pass an object, in all of the types. This object can assume any size, and any type, but is default null. Usecase: You want to pass a playerobject, you have obtained, to be used on the event return; Rather than saving that object, and then trying to fetch it again, just have the event contain the object, in addition to whatever data it should by default (Request => 'attach' object => event => 'return object')
Request+event: List of all music ;; Request+event: List of all sounds Request: PlaySound (Plays music / sound / soundfile from a directory) Purpose: Being able to make things more responsive feeling. Additionally, can be used to make a 'music player' / 'sound discovery', to make third party tools able to reference these (ie. the player is able to, via a mod, to view all sounds/music availible, and then in a tool, specify which, knowing what it does (/sounds like), without having copyright issues with having third party tools shipping the music/sounds (the sounds/musics is still in the game, so that solves that issue)
I would love having an event fire, whenever a player removes a waypoint (ie. the waypoint was remove on approach, and the player got close enough). Should pass the data the waypoint was created from, aswell as the player entityid. Possibly, when setting waypoints via command, allow for a distance param? (Ie. remove when you are 1meters away, 10 meters away, 1000meters away (...)) This could be used for some relatively optimized 'when player is in area' checks
Would you kindly give Autominers their own Type number in Event_Playfield_Entity_List or could you possibly add a way to identify the coordinates of the Voxel resource nodes either way... I'm trying to come up with Some way for my ActiveRadar mod to identify the locations of the Voxel Resource nodes.
Having a way of sending 'additional information' to the server info window could be rather neat. (like user clicks for info; Event gets sent to mod(s), mod(s) have possibility to send request with info, info gets async added, if received, clientside.. If a mod sends data multiple times, it will overwrite what is currently displayed.. If multiple mods sends, it will be displayed after eachother, after the main description) This could make for some usefull bits, such as showing mods server is running directly, more flexible information, status on different things, etc. (I'd use this to show availible spots open on a server for instance)
I'd like to include, in the player_info event, if the player is using a drone, and if so, the entityID of the drone. (Ideally, also including the XYZ and ROT of the drone, but I can live with it being under an 'entity information' request, given we get one )
Please make the API available to single player as well. I don't want to be forced to run a server to get mods added to the game.
Could the ItemStack[] objects always be max-length by default? After working with them, it seems that you have to place them in the array, as they will be placed in the inventory, rather than the slotidx having any effect. Ie. if you have ItemStack[0].slotidx=1, it would be placed in slot 0 regardless.. This behaviour is fine, and somewhat logical.. ish.. Not totally, but close enough. However, if the player have no items, or the inventory have items only halfway, the remainder of the inventory 'doesnt exist', and you have to make some nasty workarounds to manipulate the ItemStack arr, to place items there. If by default the ItemStack arr would just be max size, it would require way less effort to manipulate.
RE: this.. The initial data should ATLEAST be in the same format, as expected.. Try do a simple 'get player' request.. Then do a Request_Player_SetInventory with the same bag + toolbar This will completely mess up the ordering of the items, as the original 'get player' event didn't contain the items in a proper array, but rather where the idslotx defined their spot.. (So if you for instance have a toolbar, with slot 2 and 7 filled, it will give you an array size of 2, with [0] being what should have been [2], and [1] being what should have been [7]).. Now that is rather inconsistant.. fix pls? <3
Event_WindowOpened : Will fire whenever a player opens a window. Will supply the windows name/id. This can be used to better track what the player is doing, for instance, if they are opening a deathcontainer, or a loot container, their PDA, etc.. Request_CloseWindow : Will close the current open window. Can be used to make refreshing messages, prevent default behaviour (such as denying other players from looting a deathcontainer, or specifying custom behaviour to it, etc) Event_OnBeforeDeath : Will fire before a player actually dies, and contain their player data. This can be used to for instance extract their inventory, and possibly even save them from death, if a request to change their stats is passed. Will allow for interesting tweaks.
Event_BlockAttacked : Will trigger whenever a player attacks a structure. Will return the structures id and the attacking players id. For convenience could also contain the structures owners id. Should be heavily throttled! Only fire once for every player, every reasonable interval (Throttling to like 30s seems reasonable?) Should only trigger if the player is of a different faction from the structure! (To prevent abuse with the throttling.. or the throttling could be per player per structure optionally) Ideally this should trigger for both POIs and player sstuff And for HV/SV/CV/BA
For the SpawnEntity, when using a structure: Would it be possible to have an option to -'Allow digging' (By default, it will be buried, if any is underground, and by default it will disallow digging) -'Make inside clear' (By default, it will be buried. Ideally, an option to make the inside not full of dirt/sand/stone/.. would be appreciated) -'Make inside clear, but fill up on destruction' (If removed, don't destroy the landscape sorta deal.. If any players are inside, let them be teleported above the world, so they don't fall into void)
Simple links, that can be clicked, and will fire an event, with data specified by the link. Usuable anywhere with normal formatting, such as chat, PDA, prompts, etc. If clicked, will fire an event. Event will contain the 'url' related to the link (this could for instance be 'giveitems_2', 'makeMarker', etc, whatever) The event will contain the players id, and the clicked links 'url'. (optionally a type, specifying the context the link was pressed in (chat/prompt/...), and optionally, players permission)
Event_Entity_PosAndRot is the closest thing we have to get entity information.. Can it include the playfield it is on at the very least?
Method for getting all playfields (At the very least generated + nearby) Current best-approach that I can think of, is using 'Event_GlobalStructure_List'. But this doesn't account for non-generated playfields.
Can 'Event_GlobalStructure_List' include how it was created? (ie. if spawned/created from a blueprint, include the filename of the BP, and if created ingame, from a starterblock, state that?)
For future reference: -Event for players entering & leaving combat, per entitity: --Specify the entityid, if any, the player is in (vessel) --Specify the entityid of the engaged unit --Specify the vessel, if any, the engaged unit is in (vessel) -Every time engaging with a new entity, send a new 'entering combat' event Purpose: Can track when player is in combat (and from ID, where, and with who/what) Whenever a player engages a new unit, will be able to measure the combat tme, and act accordingly, both for players (pvp combat), npcs (pve combat), or both.
I'd love to be able to make a 'stamp at location' call. Most basic usuage would be making a flat square with x,y dimensions, which would terraform the ground around it, to a set y-level. Could potentially be cool to use it together with the stamps, so it can be more flexible shapes. But I'd settle for squares!
