But wait ! Theres more ! We will chuck in a set of kitchen knives ! Did I say that right ?! Seriously though, theres an API still being worked on for modding, and we still have things being added to the config file, if you havent explored what the config file can do for you, I recommend you do asap, it also is a game changer.
You know what would be a game-changer? Actual, real, decent documentation for the API and the Config file. Please, for the love of God, hire a technical writer/documentation specialist. --Brian PS: No, what is available now is NOT sufficient. PPS: HWS having direct-team access isn't helping. They know things that are totally undocumented.
I see things in HWS I never knew were possible, the most customised config I have ever played on. It is no surprise these guys know stuff we dont, HWS made some mods for their server which led to eleon establishing those mods as game content like the overall marketplace trading concept for example, I am sure I read that this was originally a HWS mod. I think HWS in some cases knew stuff eleon did not know. HWS takes the EGS code and bends it to their will with the use of web technology and their server paints a picture that most servers do not for the devs. I think HWS is a source of inspiration and useful information for the EGS dev team for that reason. Eleon's own servers are not as custom or complex and eleon themselves probably don't have the time/resources to run and maintain a server on the scale of HWS during this alpha stage of development so this probably makes HWS a big helper server. I think it is great that a development team can work with its players so closely in cases like this to produce the game we have today. I too look forward to all the documentation and I mean alllll of it and I want game manual documentation and i want alllll that too lol. I want to explore the possibility these guys are exploring with my own creative outlet And in response to the OP I would also like to say thank you for all the tools and gadgets ! <3
@Slipstream on the topic of the API, what exactly do you find insufficiently documented? I've slowly chipped away on this subject for a while now, and would like feedback on what you think is missing?
I see some progress there, thank you. However, some issues: 1) None of the items listed show what is returned, and what FORMAT whatever is being returned will be presented as. 2) While a 'sample' is provided, no actual EXAMPLES are provided. The sample is simply what the API command will take for arguments. --Brian
I'm not quite sure I understand what you are talking about here: -Most Requests won't have an attached event (return). Many are simply 'request => ok/error' -Those requests that does have an attached event, have a 'Corresponding event' entry, that states what is returned? -The format, is the ParamData. *Most* is clickable, for extended information (what it contains). For instance ' Event_Statistics' gives returns of the class StatisticsParam, which then states what it contains (https://empyrion.gamepedia.com/Game_API_StatisticsParam) (Sorry for formatting.. I just c+p'd) So if you can elaborate what you think is missing here, I can try to address it. But unless I'm misunderstanding what you are looking for, I don't see what is lacking here. This is def. something I havn't really done.. Personally, I can't see the benefit of this. Once you understand the format of 'how to send a request' or 'how to receive an event', samples are pretty obsolete. Atleast I think so. If you want to expand on this - Please! I just don't see the time-invested vs reward being worth doing myself
Over the roughly 30 years I have been professionally employed in IS/IT, there have been some hard lessons I have learned. In some cases, still learning. We're in the midst one of of those, now: The fallacy of "If I understand it, everyone understands it." It is clear you understand it. When writing documentation, you cannot assume the people reading it have the same comprehension. Be clear, be concise, but also be gregarious in the information provided. As an example, how are we to know "Most requests won't have..."? We don't. We cannot, in fact, without experimentation. --- In the end, the job of someone writing documentation is to reduce the burden for the people who come after them. Right now, you have to click far too much to understand a single API call, and there are assumptions baked in, such as knowing what does and does not return data, formats, and so on. Here is a great article that showcases some truly amazing examples of real-world documentation. https://zapier.com/engineering/great-documentation-examples/ And here is what I have come to expect from best-practice API documentation. https://bradfults.com/the-best-api-documentation-b9e46400379a "Most API docs just assume their audience is 100% developers, and further (incorrectly) that those developers are completely familiar with the API’s domain and jargon." I hope this helps you understand what API documentation can be! --Brian
From my POV, I can sum it up in two words. Layman's terms. About 99% of what is on that page is gobbledegook to me. Yeah, I'm the baseball player that is always put way out in left field.
Many MODs, including mine, are available as source code under GIT. Take a look and if you have any questions just ask !!! PS: You can find mine for example at https://github.com/GitHub-TC PSS: The API is simple, what makes Empyrion out of it is hard
Well, no, you wouldn't know - Unless you read the documentation, and summed it up Looking at the list, you can see which calls have a 'response' and which doesn't. Statement was purely based on the wiki data So I'd claim it to be fully possible to know, without doing experimentation, and simply looking at what is availible. I'd claim that it does not rely on any assumptions, except understanding the format of 'You can actively send a request. The request may contain some data, that you may need to specify, depending on the request (See 'Param data:' for what is expected/possible) Once sent, it may trigger an event (See 'Corresponding event' for which. If not specified will return nothing, or simple the 'Event_Ok' or the 'Event_Error'. Events may be triggered without having to be a response to a request, if something happens in the game, that warrants that event being triggered. The event will return code in format specified in 'Param data:'. Note, that it will be a 'dummy object' (typeless), that you have to convert. This should simply be done by GlobalStructureList gi = (GlobalStructureList)data (Example, if the data is expected to be of type 'GlobalStructureList' based on the 'param data' specifying this is the type. (the event Event_GlobalStructure_List for example) You can from the 'Param data:', see what data is possible to extract from here.' It was already stated in other words, but eh.. On the topic of clicking too much: You can easily avoid this, by simply using a good editor, like VS, that references things realtime. (Like what a class contains, etc) Really, there's no good way of doing it involving 'less clicking' . And really, you at most need to click twice, to get the information you need. Usually 0, once you get used to it. I'll admit this claim kinda pissed me off: I have gone to great lengths of making sure this was not the case. Sure, the wiki is not script-kiddie friendly, but anyone with a basic C# understanding should be able to easily use it. It's really just a matter of looking at the overview list and guessing what request/event you need to accomplish what you want (yes, this is a bit of guesswork, as some of them aren't that intuitive, but I havn't designed the API), or at worst searching (ctrl+f..) What you refer to as https://bradfults.com/the-best-api-documentation-b9e46400379a is exactly what the API has, except an example response, because you don't get a JSON return, but rather an object/class, where an example is utterly obsolete, as you don't have to interpretate it. This is fair. The API is not meant to be understandable, unless you have a basic understanding of OOP (Object oriented programming) .. Well, really, just a basic understanding of programming should do imo, but.. This. There's a list of mods linked (Both usefull for new modders, and people looking to install a mod. This list contains links to their githubs/however else they are linked, if they have open-source. Plenty of examples to go by, if you really need to see it in practice (Also, keep up the good work Astic, this comment wasn't meant for you )
Well, we'll have to agree to disagree, then, especially as I have clearly gotten you to be overly-defensive. --Brian
I do have somewhat of a basic understanding of programming/coding. While I may not be able to "script my way out of a wet paper bag" I can do a bit of tweaking. While I can't really wrap my brain around LSL, I can make changes. That's just one example. Years ago I was able to make skins for some of the forums (ZetaBoards, Invision Free, and a couple of others I can't remember the names) that used to be around. So yes, I think I have a very basic understanding, but I still prefer layman's terms.
Hey fellas and ladies, Ive been reading through some of what your all talking about. and its insightful. here the issue im running into if you want to run mods and this is where documetation comes in https://github.com/MichaelGoulding/EmpyrionNetworkConnectedMods To the new or uninformed none of this makes an sence at all. I was around in the begining days of minecraft modding and im seeing the same sort of thing here with empyrion you have to download this add that configure this port to that dierctory then build the code to compile another and setup the ports to = this or that. to the simpleton or layman alot of this is to complicated to even bother with and there is no clear concise explination or or how tos to a person that knows nothing about visual 2017 or even understands file structure and directorys mabe they shouldnt mess with modding empyrion but this could be as simple as download mod A and mod B and drop it into this folder and i think your gonna see a huge influx of players and content creators come out of this. also as far as tools are concerned i have seen a couple of different one but they all lack a degree of simplification. if you had a tool to say make custom scenerios that can cover all the basics and had a standard of development that creators can follow you could very well have the next generation minecraft modding community in empyrion. Right down to texture packs and modded block mods. the best way to explain it is your working magic in front of people eyes bach could write grand orchestrated synthonys and to that regard yall are bach but how many bachs are out there Not very many but everyone can learn to dance or sing or even play an instrument
an amazing thing would be seeing a tool that would load a playfield and make changes to said playfield In a gui in real time rather then having to open and close notepad ++ reloading and seeing if it took effect. if i knew even a little code i would mod it myself However i fall under the catagory of edit yaml reload and see if it take the effect i was intending
You clearly havn't tried hard enough There's two forums dedicated to different types of modding - API & general changes The API is the baseline for modding for egs.. The one you are referring is also using the API, but builds ontop of it, in its own way, that does require you to compile etc.. Other mods, like SG and CC (Two of mine) comes as a downloadable folder that you simply drop in the mods folder, configure what you want, and good to go. This is not the only two ofc. There's a series that comes as .dll files ready to drop into folders.. check out the wiki entry: https://empyrion.gamepedia.com/Game_API_ModList It also contains a quick guide how to 'install' For the tool you are asking for, JMC is doing a great job at providing playfield-editing tools, and my ePDA is pretty much as simplified version of editing the PDA as you get.. So I'm really not sure what you are asking. EGS doesn't support too indepth modding yet - however, their support is based on 'official code' from their part - meaning that it shouldn't need to be updated much for each rev. There isn't support for doing sounds, textures custom blocks, and much more yet - but they've shown which path they want to pursue, and from my POV, it's worth waiting for. EGS provides two types of modding: 'everyman' modding - files that you simply edit values in And actual modding - writing C# code that interacts with their 'backend' That is pretty much the best you can get as of, when it comes to yaml editing.. Few tools around to aid this, you really just have to look around the forum.. https://empyriononline.com/threads/server-tool-mod-list.10916/
believe me ive tryed pretty hard i just get lost in the shuffle i think Yes you are right it is worth waiting for there is a ton of stuff this game can offer and i cannot wait till they sort it out
