[garry]

Just thinking this through. As I understand it right now Oxide/Leather work by replacing some of our dlls.

We'd rather avoid that. So if I make the server load any dlls that are in a 'servermods' folder - would that be better? Could they still operate without changing the original dlls?

Then the mods could load their submods (like Lua script etc) from inside the -datadir provided by the server owner.

This means that GSPs could give their clients free access to the -datadir folder.. while only installing whitelisted dlls in the servermods folder.

I'm investigating strategies here, figuring out what would be best for us, modders, GSPs and server owners going forward.

[XoX]

Considering Garry's Mod would be no where without the ability to turn it upside down with addons I enjoy seeing you worry about helping Rust modding.

And what you proposed definitely sounds better than having to edit Rust dll's

[Zidonuke]

Well as it is, only people who managed to get the current server dlls can do anything related to modding, even adding a servermods folder would only support developers lucky enough to have the info and direct server files access.
If you could, it would be nice to release a rust server with a limited max slots, bind to localhost only? and even disable the steam server list announcements. That is if you wish to keep GSPs as the only official hosters.

[xEnt22]

The problem is, modding is extremely limited right now without modifying the dll. changes need to be done to the dll in it's current state to gain access to features we need, take door sharing for example, i couldn't come up with a way to share doors without editing Assembly-CSharp.dll's CIL code to call my mod and check if that player is the owner of the object.

If your willing to add listeners for a bunch of events that plugins can use, and other requests then we could all get along just fine :)
I don't like modifying the DLL and it seems either does anyone else, but right now i don't think there's any other way? It's nice to see you showing interest though, i see this type of game as the kind of game where modding is essential (like Minecraft)

[Hoffa1337]

Give us the same control as in gmod.

[BARKx4]

Zidonuke posted:

Well as it is, only people who managed to get the current server dlls can do anything related to modding, even adding a servermods folder would only support developers lucky enough to have the info and direct server files access.
If you could, it would be nice to release a rust server with a limited max slots, bind to localhost only? and even disable the steam server list announcements. That is if you wish to keep GSPs as the only official hosters.

Why is this guy still allowed to participate in conversations here when he's been proven to be part of the crew from #ArtificialAiming and has already publically leaked server DLLs on this very forum?

On topic, right now things like sharing doors and manipulating inventory require changing private methods to public in the CSharp assembly DLL. If you even just made more methods public it would be helpful, and hopefully get rid of the need to overwrite DLLs with modified copies. Most of the modification going on is just to change method declarations and gain access to private members, AFAIK.

[Handsome Matt]

Event Listeners!

class EventListenerExample : EventListener
{
 
	// You can name this method anything
	public void onSpawnEvent(SpawnEvent evt)
	{
		// Your Event Code here!
	}
}

class ExampleMod : GameMod
{
	
	EventListenerExample listener = null;
	
	public void Example()
	{
		// Example of getting the event manager
		EventManager eventManager = getEventManager();
		
		// Instantiate our event listener
		var listener = new EventListenerExample();
		
		IEventListener eventListener = eventManager.CreateListener(listener.onSpawnEvent);
		
		// Basic Registration
		// Register our event listener
		// We can use a 'generic' event listener
		eventListener.register<SpawnAnimalEvent>();
		eventListener.register<SpawnZombieEvent>();
		
		// Chaining
		eventListener.register<SpawnAnimalEvent>().register<SpawnZombieEvent>()
		
		// Types ( any number of arguments )
		eventListener.register(typeof(SpawnAnimalEvent), typeof(SpawnZombieEvent));
		
		// Type Array
		eventListener.register(new Type[] { typeof(SpawnAnimalEvent), typeof(SpawnZombieEvent) });
		
	}
}

[mistad]

Creating a 'servermods' folder would eliminate the need of a dll loader, such as LeatherLoader, sure - but we still wouldn't be able to make the adjustments and features the people want if we can't change the original dlls. BUT, there is a work around. It's as simple as making classes, methods, and variables accessible. Public - static if need be. Also, eventhandlers as mentioned above would be an amazing touch. Currently, the way we all edit doors is through changing method bodies at runtime and rewriting the method itself in the original dll - which is kind of tedious and excessive. Simply readjusting the access modifiers of most of the variables would open more doors than one would think. To move forward, this is what I think.

[garry]

Handsome Matt posted:

Event Listeners!

class EventListenerExample : EventListener
{
 
	// You can name this method anything
	public void onSpawnEvent(SpawnEvent evt)
	{
		// Your Event Code here!
	}
}

class ExampleMod : GameMod
{
	
	EventListenerExample listener = null;
	
	public void Example()
	{
		// Example of getting the event manager
		EventManager eventManager = getEventManager();
		
		// Instantiate our event listener
		var listener = new EventListenerExample();
		
		IEventListener eventListener = eventManager.CreateListener(listener.onSpawnEvent);
		
		// Basic Registration
		// Register our event listener
		// We can use a 'generic' event listener
		eventListener.register<SpawnAnimalEvent>();
		eventListener.register<SpawnZombieEvent>();
		
		// Chaining
		eventListener.register<SpawnAnimalEvent>().register<SpawnZombieEvent>()
		
		// Types ( any number of arguments )
		eventListener.register(typeof(SpawnAnimalEvent), typeof(SpawnZombieEvent));
		
		// Type Array
		eventListener.register(new Type[] { typeof(SpawnAnimalEvent), typeof(SpawnZombieEvent) });
		
	}
}

We could definitely do something like this. I guess the issue is that it then falls on our shoulders to add events.

What kind of interaction would you want the other way, moving players, killing players, running console commands?

[mistad]

I guess the one everyone wants the most would be the ability to return a different value for when you check who the door belongsTo. Some others would include storing the Inventory instance of a PlayerClient/NetUser/Character and something as miniscule as changing the color of names in chat (Ex: have users be able to recognize the PMs our plugins send as actual PMs if the player's name is too long by changing name color). Things such as moving players, killing players, and running console commands we already accomplish with ease - so don't worry about that one I think.

[Handsome Matt]

garry posted:

What kind of interaction would you want the other way, moving players, killing players, running console commands?

Some interfaces that come to mind:

IEntity: Get/SetPos, Get/SetHealth, Kill, SteamID, ..
IGameServer: GetMaxPlayers, Log, ..
IInventory: Get/SetItem
IPlayerManager: FindByName, GetAll, GetByID, GetBySteamID

These can be retrieved with: mod.getGameServer(), mod.getPlayerManager() or entity.getInventory() etc..

[Pwnoz0r]

Any sort of official API we can hook into would be great to avoid modifying/injecting our code into the game (feels like server side hacking instead of modding at this point). Instead of just server side modding it would be great if we could hook into the game as a whole. Doing either something like GMod or Minecraft would be beneficial.

Thank you for looking into and supporting the modding community.

[WANNAPLAY]

Garry's idea is better than providing interface.
If someone decide to modify DLL's he will have more possibilities than with an API.
And if the API wants to compete, rust developers will have to add functions to the API and it can take some times.
I guess an API will be just great for 95% of mods but some servers will still modify DLL's for unique exclusive features.

Sorry for bed england.

[Handsome Matt]

WANNAPLAY posted:

Garry's idea is better than providing interface.
If someone decide to modify DLL's he will have more possibilities than with an API.
And if the API wants to compete, rust developers will have to add functions to the API and it can take some times.
I guess an API will be just great for 95% of mods but some servers will still modify DLL's for unique exclusive features.

Hire me to write the API, problem solved.

[John123]

Are "door share" servers legit or not? There are rumours going around that they are not. Other people claim they are legit mods. How can a normal player now what is right and what is wrong at the moment? I mean there is a modded tab so it must be kinda official to use these servers.

[WANNAPLAY]

You are NOT going to be in trouble for playing on those servers if it is the question.

[Dorkslayz]

Some way for our mods to interface with the Rust Server functions (whether this is through an API or another method) would certainly be good.

[garry]

I guess this is better done sooner than later. And people are going to mod whether we want them to do not.

I'll talk to helk about what he thinks the best solution to this is, and try to work out what we're going to do.

Would you guys be upset if what we do makes Oxide/Leather redundant?

[BillNyedaSpy]

As far as I'm concerned, if you make Oxide/Leather redundant, but open up new possibilities for mods, I don't think they would mind.

[BARKx4]

garry posted:

I guess this is better done sooner than later. And people are going to mod whether we want them to do not.

I'll talk to helk about what he thinks the best solution to this is, and try to work out what we're going to do.

Would you guys be upset if what we do makes Oxide/Leather redundant?

I think everyone involved would love it if you made them redundant. The community is completely divided and its creating hostility between GSPs, developers and everyone else involved.

[CanVox]

garry posted:

I guess this is better done sooner than later. And people are going to mod whether we want them to do not.

I'll talk to helk about what he thinks the best solution to this is, and try to work out what we're going to do.

Would you guys be upset if what we do makes Oxide/Leather redundant?

NNNNNOOOOPE!

Oh boy, what do we want, what do we want.

- The ability to write MonoBehaviours that run on startup like leather does.
- The ability to write a handler that catches prefabs & stuff on startup as it comes out of the bundling system? Basically I'd like to be able to do something like:

Bundling.RegisterObjectMod<CharacterLoadoutTrait>( ModifyTheCharacterLoadout);

public void ModifyTheCharacterLoadout(CharacterLoadoutTrait trait)
{
//Add/remove blueprints/items/etc.
}

- Same with I guess items as they come out of the savegame? Another good example of something I'd like to be able to do is replace the DeployableObject on all doors with an extended DeployableObject that overrides BelongsTo to use a different permissions system- this would require me to be able to be able to change the door prefab as it comes into the bundling system and also all existing doors in the save file.

- Event Handlers, please! Most functions in the ServerManagement, damage dealt, death, resources extracted from a node, need to be added as cancellable & modifiable (damage dealt, resource gained) events. I can't decide whether global events described above are cooler or event handling components that can get added/removed to thinks you want to catch events for are cooler.

- Easy access to the modded stuff to get saved out via the savegame system so the new data doesn't have to have a weird separate db like oxide does.

- I'll think of more but I gotta go to work.

Edited:

Oh, yeah, hey, best of all would be the ability to download bundles of resources to the client- initially just sending new ItemDataBlocks of existing types across the wire, later letting new assets bundles (graphics, sounds) be downloaded on server join, and finally maybe even client mod DLLs. It would be fantastic to have hassle-free client modding.

EDIT AGAIN: oh right, hey, whatever system that gets used to save stuff out, it probably needs to be able to withstand mods being removed without wiping the server? I think people will understand if that doesn't work out, but it's a goal to reach for anyway.

EDIT: Event handlers for when a player ACTION1/ACTION2/ACTION3 with an item, without an item, when a player hits a thing with a weapon (even non-destructible stuff)

EDIT: Less stuff sealed, more stuff virtual.

Edited:

Oh, and more stuff public. A great example is Sleepers.Close(uint)- it's a protected method guarded by the public method Sleepers.Close(NetUser). Why is that method protected? It seems like it's only non-public because no external facepunch code needs to use it. There's no real danger in feeding it bad arguments, and there are plenty of situations (for instance, the mod Limited Sleepers) where someone trying to close a sleeper might have a steam ID but no NetUser.

[Al Apone]

garry posted:

... Would you guys be upset if what we do makes Oxide/Leather redundant?

I think that is your best course of action, so Absolutely Not! As an admin I prefer not to modify the core programming. I would be thrilled if the functions of Oxide, Rust ++, and others were available in the core RUST program by default. The more flexibility you build in for your Admins, the more variety you provide your player base.

Personally I don't feel accommodating mods is worth your effort until late alpha/early beta. Build the game the way you want first.

[sherkaslod]

I would say allow global event hooks to be had, then most mods can go from there as long as you load all mods in the folder you said.

I think that is a great start, it will eliminate the need of a loader.

[Eclipzed]

Also take into account the usage needs of GSP server owners. Unless you have a good GSP it is hard to get mods up on your server. If event listeners could ease that process, then make it so. Its hard enough updating everything whenever a server/client update comes out.

[CanVox]

Oh I forgot the most important event hook: The ConsoleSystem. When a user's crap hits the server we need a cancellable event hook for all commands, especially chat.

[StryfeKhaos]

Some general observations of the current Rust code that is similar to Minecraft code that causes difficulties in creating mods:

Pass objects by interface instead of as instantiations of concrete classes.

Use factories that create objects instead of hardcoded object creation and allow the factories themselves be replaceable at runtime (during initialization steps prior to object creation) with custom factories.

Don't use static classes - if you absolutely have to have a global (like a manager class), then make a static class that simply holds an object by interface that can be replaced at runtime with a custom implementation of that interface.

I can provide examples.

Edited:

Al Apone posted:

I think that is your best course of action, so Absolutely Not! As an admin I prefer not to modify the core programming. I would be thrilled if the functions of Oxide, Rust ++, and others were available in the core RUST program by default. The more flexibility you build in for your Admins, the more variety you provide your player base.

Personally I don't feel accommodating mods is worth your effort until late alpha/early beta. Build the game the way you want first.

Al, many of the changes mod devs would want to see in the code are just extensibility mechanisms that often arise from design best practices (interfaces, events, etc.) that if in place would actually help FP create the same features that mod devs want to more efficiently.

[CanVox]

StryfeKhaos posted:

Some general observations of the current Rust code that is similar to Minecraft code that causes difficulties in creating mods:

Pass objects by interface instead of as instantiations of concrete classes.

Use factories that create objects instead of hardcoded object creation and allow the factories themselves be replaceable at runtime (during initialization steps prior to object creation) with custom factories.

Don't use static classes - if you absolutely have to have a global (like a manager class), then make a static class that simply holds an object by interface that can be replaced at runtime with a custom implementation of that interface.

I can provide examples.

Edited:



Al, many of the changes mod devs would want to see in the code are just extensibility mechanisms that often arise from design best practices (interfaces, events, etc.) that if in place would actually help FP create the same features that mod devs want to more efficiently.

These are all good recommendations, but another thing to keep in mind is that unlike Java, all C# methods are final by default, so as I said before, making many more things virtual would be helpful also.

[xEnt22]

i see large amounts of love in this thread

[CanVox]

I'd really recommend reaching out to Squad or maybe even Unity to see how things are done in KSP. They have a really vibrant modding scene over there- the obvious use for KSP mods, adding new engines, fuel tanks and stuff, is obviously front and center. But there are mods there to set up communication networks (and unmanned crafts can only be controlled when they can reach your comms network), resource prospecting, mining, and refining into fuel, a completely rewritten aerodynamics system, all kinds of great stuff. And I get the impression that the level of work involved on Squad's end is very low because they use Unity's existing event piping systems to alert mods to stimulus.

Essentially, that's all we need- currently ACTING ON the server is usually possible (but some help here in the forms I detailed above would be great), if via nothing else but reflection. The biggest obstacle for modding currently, what tends to call for IL injection, is the difficulty of allowing the game to provide feedback to the mod. The only way of doing so currently without IL injection is console commands, and even that poses an issue because only one mod may override the chat class at a time currently.

[XoX]

garry posted:

Would you guys be upset if what we do makes Oxide/Leather redundant?

If we get the same/better functionality then not really. Though I really enjoy being able to write for Rust in Lua.

[thomasfn]

CanVox posted:

I'd really recommend reaching out to Squad or maybe even Unity to see how things are done in KSP. They have a really vibrant modding scene over there- the obvious use for KSP mods, adding new engines, fuel tanks and stuff, is obviously front and center. But there are mods there to set up communication networks (and unmanned crafts can only be controlled when they can reach your comms network), resource prospecting, mining, and refining into fuel, a completely rewritten aerodynamics system, all kinds of great stuff. And I get the impression that the level of work involved on Squad's end is very low because they use Unity's existing event piping systems to alert mods to stimulus.

Essentially, that's all we need- currently ACTING ON the server is usually possible (but some help here in the forms I detailed above would be great), if via nothing else but reflection. The biggest obstacle for modding currently, what tends to call for IL injection, is the difficulty of allowing the game to provide feedback to the mod. The only way of doing so currently without IL injection is console commands, and even that poses an issue because only one mod may override the chat class at a time currently.

In theory, if you injected your IL to the dlls then I ran the Oxide patcher on your edited dlls, both mods will work concurrently without any issues.

[CanVox]

thomasfn posted:

In theory, if you injected your IL to the dlls then I ran the Oxide patcher on your edited dlls, both mods will work concurrently without any issues.

I meant that without IL injection (or a facepunch-provided hook), only one mod may intercept & respond to chat at a time.

[krevan88]

Good Guy Garry. Helping out the modding community.

[tiffany87]

hopefully something can be made for modders. why not a whole new dll?

[xEnt22]

krevan88 posted:

Good Guy Garry. Helping out the modding community.

somehow at a quick glance i got 'curry' out of that :|

[Hoquat]

garry posted:

Would you guys be upset if what we do makes Oxide/Leather redundant?

From the server admin standing there is no way you would make us upset. If the stuff those do now is no longer needed, but we still get the functionality they provided how could anyone be upset about that? Right now they serve a need if the need is gone it would be better for server hosts because the renters will be able to update the server more smoothly. Overall making it possible to obtain the functionality that the mod people want without the loaders seems to be the best way to go.

[luck^eh]

I think the best solution would be for the developers to work with modders to create a public API for the game and then make a library/dll that serves at the front end for all modding. This is how the most successful forms of modding work across other games that allow modding.

That is more work for the developers, yes. The honest truth here is that there are a lot of smart folks out here who love to write code, and would probably apply for volunteer positions vetted and interviewed by the rust team to make this kind of API happen. That would be the safest long term plan for the game, because right now it wreaks of security flaws.

[Swiftone]

garry posted:

What kind of interaction would you want the other way, moving players, killing players, running console commands?

The more stuff we have access to the better. As I'm sure you know games with applicable modding capabilities are typically long lasting games.

Also thanks for showing interest in the modding community

[luck^eh]

I should have also pointed out the benefit of having a public API for modding would lead to many more security exploits being found much quicker. The reality is that when you have a project such as this, it takes a nefarious deed to get the serverside dll's, so most people that have those are going to be use them for evil and not good. Open up the API and let those of us with good intentions have access to it more freely, and I guarantee you we can help find and fix exploits. I believe there are more smart people with good intentions for rust than there are smart people with evil intentions.

[Joykiller]

BARKx4 posted:

Why is this guy still allowed to participate in conversations here when he's been proven to be part of the crew from #ArtificialAiming and has already publically leaked server DLLs on this very forum?

On topic, right now things like sharing doors and manipulating inventory require changing private methods to public in the CSharp assembly DLL. If you even just made more methods public it would be helpful, and hopefully get rid of the need to overwrite DLLs with modified copies. Most of the modification going on is just to change method declarations and gain access to private members, AFAIK.

Google picked up: "11-19-2011, 01:50 AM. Zidonuke. ArtificialAiming VIP. Zidonuke is offline" So yeh you are right :D