I'm probably not doing the thing everyone else does to make this information appear out of the ether, because I'm only a few weeks into this environment, but I've been regularly stuck for long periods because the documentation and guides here give code snippets but usually (yet to find a counter example) don't specify the using Namespace, or the Assembly that is required to use that code, and that's pretty essential information. Everything else about the guides is fantastic and I love them and the community search, but it's not quite meeting my needs and if everyone shuts up about their solvable problems, others will keep getting them.

Look At Existing Plugins is not sufficient as far as I can tell, VS isn't telling me what namespace an unknown thingy needs and I don't seem to be able to look up which references were assigned to downloaded plugins, and several times I've had functions not work in spite of 'using' all the same things the other plugin was, probably from different versions of references.

Assuming I don't just need to hit one tickbox somewhere and everything's fine, would it be good for someone that has access and already knows these 'obvious' things, to do a pass over the guides and fill in this info?

Example: https://umod.org/guides/the-basics/hooks

You need to be "using Oxide.Core.Plugins;" for creating a Hook in your plugin to work, but this page does not tell you that. There's something else I need to do to be able to use [Async] and IsSubscribed but I can't reverse engineer what it is so I'm still stuck just not using [Async] and re-subscribing to things I'm probably already subscribed to and hoping that doesn't cause any problems or waste resources.

In spite of this, I've come from a purely Java background and made a plugin and it does everything I really wanted, bravo umod!

Cheers, Pike.

The Oxide documentation at /docs is fairly limited, and most of what exists at /guides is for uMod, not Oxide. Oxide is the older platform that we are going to be phasing out in favor of uMod. I do agree that the Oxide documentation is lacking though, but the uMod documentation continues to grow.

If you have a specific question though, feel free to ask. In general though, most general questions can be found via search on our site.

To answer a few though... I do not believe [Async] and IsSubscribed are available in plugins, the main DLL you need to reference is Assembly-CSharp.dll from the game and all Oxide.*.dll files. Sometimes you'll need other Facepunch or Unity DLLs, which your IDE will generally give you hints if you have a path set to some of them already. Setting up a local server is recommended for development as well.

This reply is helpful and deserves acknowledgement. I've since also found that https://umod.org/api is a great way to find out what Namespace is needed to do things seen or read about elsewhere, though the Assembly is consistently not where I find them as a Rust plugin maker. I've also now got VS trying and automatically add them whenever I paste something, but it's hit and miss and I don't know how or when it happened.

Cheers

That page is also only for uMod, not Oxide, which is why the namespace varies. ;)

Oxide has Oxide namespacing, uMod has uMod namespacing; not the same projects.

Any documentation on our site other than what is under /docs is only for uMod.

Absolutely, I should clarify it's only good for clues when you're working with Oxide, and there was a time when I didn't have any of those.

As someone not all that familiar with digging around in the codebase to try and find things, the most frustrating aspects of the documentation is the lack of information on object parameters and what routines that can be modified. A good example is the plugin I been working on all day essentially, because I couldn't find information as to how plants behave, what parameters they have and what routines are tied to them. I have also been unable to figure out a good testing solution for the plugin as to test the plant states I have to wait for them to change unless I find a way to debug cause progression on click or something.

Getting just a dump of all the parameters listed for the hooks themselves would be useful to extend the docs with. Then adding object operators to that e.g. GrowableEntity.ResetSeason() to be able to know what manipulator functions are included would simplify figuring out what one can do with the provided objects.

I'm aware a lot of that information is out there and there are ways to get to it, but the point of the documentation remains that as central place for information it should ideally cover all capabilities and exposed objects/data and not just the hooks. As with anything that has a direct visual effect writing plugins is actually quite fun, even the odd results during debugging, so better documentation just augments that fun :)

We document what we provide, not everything that is from a decompiled game.

Not saying it needs to include everything, but at least the objects mentioning in the various hooks a basic list of their parameters and routines, which are pretty self explanatory in most cases. The main issue I have is not knowing what the hooks normally would do aka what code would be within them if I were to 1to1 replicate Rust behavior, but just having the objects described would probably already help massively.

I mean how exactly is this meant to work, where am I meant to get information on what Rust does when and where in it's code that is overwritten by the code in the hooks, where do I get the "vanilla" version of the hooks code from?

Hooks are not there to replace the behavior from the game, they are there to modify and potentially stop. If you want to see what the code looks like where a hook is located, that can be found in the patched DLLs for the game that Oxide provides in each download. There's still a lot of code that Oxide doesn't touch that you can see as well in those DLLs to understand how things work with the game, for which would be a massive undertaking to try to document and a constant job to keep it updated.

So that leaves then digging through the github and yet links to the specific files each hook is contained in or even just cloning the relevant source parts to the wiki isn't possible? Think it would be possible to extract the relevant data and reload it each git push, just requires some scripts and a bit of fiddling.

Tampa

So that leaves then digging through the github and yet links to the specific files each hook is contained in or even just cloning the relevant source parts to the wiki isn't possible? Think it would be possible to extract the relevant data and reload it each git push, just requires some scripts and a bit of fiddling.

Could always add whatever useful information there is based on the function name though. Take dll, break open, dump code, regex the functions, insert comments, put on wiki. A day or two of some scripting and a bit of trying to figure out how to dump DLLs in the first place, but within the realm of possibilities. I'll give it a look if I find some time and don't forget about it. :)

A user-generated wiki sounds like a bangin idea if you can find someone willing to populate it or create it's generator, much better organisation of  crowdsourced info than searching the forum, we can't lean on the umod devs for that though, they've got other work more pressing. The same problem again is that Oxide is going to be replaced and they're already documenting uMod in a very satisfactory manner, we've just got to wait for it to come.

We had git hosted docs (and even a wiki) that were available for users to contribute directly to before, but there was very little contribution toward them. I don't foresee that improving with trying to take on an even larger task like documenting an entire game.

Again though, documenting what we provide isn't the same as documenting a decompiled game.

As mentioned previously though, generated docs may be likely, but beyond that is slim given the scope and amount of changes that occur for actively developed games.

im suprised someone hasn't just created a plugin for notepad++ so it intergrates the entire oxide and umod dictionary into something with a native autocomplete function that tries to predict what function/hook your trying to type and gives you a list of the possible inputs.

like what "lua native autocomplete" does