Rust Arena standalone

Ah ok so it sounds like its completely unrelated to events and only needs one spawn point then. I think in that case it should be a separate plugin.

But for *Event type* plugins here is a diagram I made to show what I mean and I hope you will consider it. (Spent some time in paint making this).



I believe the left side is how modularity should be done. It's better for owners since they don't have hundreds of plugins to update and better for developers as it would be easier to maintain than multiple dependent plugins and more efficient. Of course exceptions can be made (such as zones which I think is a good plugin), but I think one core plugin to include most of the functionality with separate add-on plugins is what we should be aiming for rather than relying on 4 or more dependent plugins for core functions.

 

You got it right Hatemail. I have couple of friends that have an eye for building things, and we have few simple yet good gameplay changes planned. They are not coders though. I need to expose a simple interface for them to be able to add non-standard (to rust) objects and structures to the game world. That way they can focus on design and not wait for me to add custom tweaks to the code (make this elevator go slower and to the right at some point, open this gate only if player rank is "nobleman" or higher etc). I know I can't just get away with simple friendly command interpreter since I tried to customize the Telekinesis plugin to move more than one object at once - you either keep it simple and have to mundanely select all the "parts" before moving them all the time, or start to include some kind of DB mechanism to save information about those "glued" parts. That is the problem with small modular plugins. They are written to work with as many other plugins as possible. Small chances that a custom tweak will be included just for you, since devs have responsibility to their user base not to change too much. So you either have to keep tweaking them yourself (and since they depend on yet other plugins keep making sure your tweaks work with updated versions), which is a nightmare, or just be happy with what is already out there, which limits you a lot - and it soon becomes a nightmare anyway: the amount of commands you need to design a complex scenario is terrifying, and after all this work there is no way to easily save/load/clone it; you need to worry about the correctness of data that other plugins pass to each other especially if any of them save to database, since if the config for said plugin gets corrupted all other dependent plugins will stop working too (so more code to add like it or not); finally you have no control (or even clear overview) over the execution flow - i think i saw you @Reneb just talking about the need of adding a feedback channels to some plugins to make sure they don't lock out a dependent plugin? Double points if the plugins are Update()-oriented, you really need to start to worry about the timings and you might end up adding all sorts of safety checks that certainly won't speed things up (or straight up rewriting Update()s for every plugin so they work in sync). This all is not needed if you want to have fun with mods on your sever, but imho it is needed if you want to have your players have fun with the mods on your server (and more then just to log in for 5 mins and say "that is cool"). My point being, if you are able to code all those tweaks you are probably able to write it from scratch and gain on performance and readability.

That is what I mean when I say AIO plugin - not something that would just do the same things that are already out there in one file, but rather a scenario-building toolkit (that could be also used to administer said scenarios). Think of it that way: some ppl have no idea how to hook calls in dlls or how to inject an on-the-fly compiler into their server, but are able to script and elbow straight to their mouth if they want to. And for them there is Oxide. Some ppl have an immense imagination and eye for a artistic detail but wouldn't know the difference between javascript and post scriptum. For them, hopefully, one day there will be my toolkit to download . I know it won't be an easy task, but I have some free time. I gave myself 2 months to reach alpha. Worst case scenario, I fail and learn some C#. But just maybe someone will be having some fun with it one day and encounter a bug - and just, just maybe he will open his first .CS file that day to see how this all works in the first place
[DOUBLEPOST=1430786070][/DOUBLEPOST]

You would be able to install or even merge them by this time . Also your graph is misleading (and i think incorrect, jail needs zone manager no?). you can't just put "other" plugins like they have no dependencies and "core" plugin without stating what it would include. Reneb's point was he doesn't want make the core plugin because it would get too heavy over time, which would harm ppl that only need particular features from it (most of his userbase probably). I don't necessarily agree with him, but he's the one putting in the work so it's his call - he's more experienced than the both of us too ;p. But even if he just did it on the whim you have no right to complain - this is 'free' software, as in you are free not to use it if you don't like it.

 

In my diagram core functionality of Spawn DB would be included in the core plugin Events manager. Kits and Zone manager would be optional. The Arena plugin would include Team Deathmatch and Deathmatch with an admin option to switch between modes.

I stated in my post that I thought Zone manager deserved to be a stand alone plugin... But it should be optional for Arena and not a requirement. However I do not think Jail needs the Spawn DB, a Jail plugin to punish players only needs 1 spawn point.

And yet his current system is forcing people who just want an arena to install 3/4 additional plugins (not including kits as most servers already have that).

Sharing my opinions/offering suggestions is not really complaining. I run one of the top modded servers and am grateful for all the work the devs do.

 

I'm just saying that you did get pretty clear explanation from the dev itself, and i doubt any graph will change his mind . unless you have a thing for .BMPs Reneb

can you say exactly why there's such a difference for you if it's 2 files or 4 files?

 

That's like saying what difference is it if its 4 files or 10 files for an Arena. If you were a server owner you would know how I feel. The less plugins the better. We would much rather have 20 powerful plugins than 80 separate ones to manage. Quality > quantity.

 

Every prior all in one plugin on rust legacy was complete and utter shit. I expect it to be the same for Oxide 2.0 if someone attempted.

 

we are all just speaking in the wind ... you just don't understand ...
wish you were here on legacy with all those all in one plugins and people crying because they werent compatible and because one had some features that others didnt, with 10 player lists that made the server lag for 5-10 seconds sometimes if they all saved at the same time ...
legacy was full of all in one plugins and it was chaos, it was rubish, if you wanted to make a new feature you had to create 4-5 compatibilities or people would go: flag support? oxmin support? whatever the other names were support?, oh but i want the remove tool from this but not from the all in one plugin, how do i do that?

 

At least legacy had more plugin developers.

I am not pushing for that though. If you are familiar with any of the old minecraft plugins for bukkit (was a mod framework like oxide but based on java) there were several well known independent core plugins which had numerous add-ons and those were usually updated and maintained more than others.

[DOUBLEPOST=1430790191][/DOUBLEPOST]

I think you should make Events Manager a core plugin that is used for *event type plugins*.

Merge Spawn DB with it.

Make Kits and Zone manager optional and not a requirement to use with it.

Have the Arena add-on include both (TDM/Deathmatch).

That's my suggestion.

 

i challenge you to come and blow me on stage during one of our communal events, on our tweaked-to-the-max, amazing server built only using our custom in house AIO - if i prove you wrong that is you can be the judge.

Ray in this special case there is no real difference for you as an admin: 4 is realistic number and those 4 plugins are written by the same dev right? there really should be no redundancies or performance penalties, it's more like if you would split classes in 4 different files. there should be no difference for you either you update zone manager once and arena once, or a plugin containing both twice. i don't think you have 80 plugins, but if you do and you just need updates ASAP automatic updater in python can be written in 10 lines.

@Reneb: above will hold true only to the degree of complexity. the almost distributed-like structure of modular plugins comes with a price. keep adding new functions and you will run into timing issues sooner or later, or your users will. when you add new features to your individual plugins you will have to update the way it communicates with other plugins to include new info (in both this and dependent plugins), with time it will get harder and harder to keep this communication system unified. you can work around those issues by writing more plugins for managing queues and acting as a middleman between your plugins to ease data flow but when you have those it just begs for you to include them in your 'core' plugin.

 

spawns data, kits, zone manager have no reason to change much the way they communicate, at least not from what i can see atm.
the eventmanager core will probably change, it's a beta version to see where the problems are to fix them before going forward,
but yes i actually didn't think about a TEAM implementation while creating it, and i'm still thinking on how i'm going to add it, shouldn't be a huge problem, but either i could make teams from the event manager core or from the addon mod ...still thinking ^^

 

@Reneb how about this: you can set small zones in arenas when players get resupplied right? but they have to do fair amount of checks to decide if kit should be awarded, plus we have to refresh them fairly often (or make them bigger and catch more colliders) to make sure we don't miss fast moving players. the bigger the area gets and the more zones you set up the biggest performance you will get. to help this, we can iterate over all participating players position every X seconds (where X could be even something like 3-5 for big arenas), note the extreme positions and activate only those zones that can be reached by players by legal ways in the time before the next big sweep. this should help performance greatly if tweaked right for the arena size.
question is, where do i put this code in your design? if i put it in arena mod that is fine, but this solution can be used in other places too, like houses etc. we could put it in zones manager, but then to use the "optimization" we would have to either let it know each time for what purpose the zones are being set or include code in each dependent plugin to set the otpimization on manually. but if you had really lightweight core plugin that manages communication between your other plugins, you can handle it all in there. you could easily expand said core plugin later with clever use of classes<> and such. you can check for dependencies there. that's most of your bugfixes would go too, leaving your modular plugins very clean, abstract, easy to use and modify.
well, at least, it's just like my opinion man

 

you can just make a new mod, use the zone manager to create the zone, use zone manager external hooks: OnEnterZone, IsInZone (what ever that one is), to redeem special kits ... what you are saying can be very very easily done with the event manager and the zone manager plugins
you will have to do a bit of code to choose what to give players ... but the hard parts are all already done :x