Guys,

all i see is chaos,
xx plugin depend on xx plugin but isnt true but xx plugin needs xxx plugin to work but isnt listed as it is need to work....
so xxx plugin isnt working or it cause performance impact because it sends xxxxxxxxxx requests to yyyyyy but yyyyy doesnt exist !

So to prevent overall chaos what about implementing basics directly into uMod ? Also Steam API functions ?
So that Plugin developer just need to get the string/functions out of uMod ?? And you can list clearly whats aviable to get from umod.

How it is cant be because xxxx plugin is using xxx API or Website requests but xxxxx API does no longer wokr or exist and also xxxx website does no longer exist. So again a xxxxxx API plugin or xxxx Plugin isnt working.


Cheesus gus do you really want to have all this things that messi ? U started with a new web present but wont have structure in it. And it is important because uMod is a great thing and (the only) big thing at the moment.

I think you are confusing Oxide with uMod. uMod is a new framework that has not been released yet, once it does it will replace the old Oxide framework (you are using Oxide right now). As for your request I'm not entirely sure what you're asking for but hook calls really aren't that expensive. There are hundreds of Oxide hooks, calling all of these causes minimal overhead, definitely not noticable.

0x89A

I think you are confusing Oxide with uMod. uMod is a new framework that has not been released yet, once it does it will replace the old Oxide framework (you are using Oxide right now). As for your request I'm not entirely sure what you're asking for but hook calls really aren't that expensive. There are hundreds of Oxide hooks, calling all of these causes minimal overhead, definitely not noticable.

Thx for that info, yes i though Oxide/uMod is same.

What i mean is like this plugin does it https://umod.org/plugins/placeholder-api

Because i saw a lot plugins do not longer work because of missing API, Website or another depending plugin.
So when you store this information with uMod/Oxide and all plugins request it from you, its better and its preventing plugins from no longer working just because a single website or API is down.

Well dependencies are made to exist as something optional or to help other developers without putting everything you can into core even if you do not use it, you cannot put everything into modding framework. Especially anything like Steam API - it is not related to the modding framework and will not be added because makes no sense and is unnecessary.

Implementing "basic" plugins into Oxide directly would defeat the purpose of being a framework; you'd now be just a mod with a bunch of random things. The placeholder API makes sense, and will likely be something in uMod (not Oxide), but things such as Steam Checks would not make sense.

The core is primarily there to handle plugins and provide an abstract way to develop plugins, not integrate with services and such.

Apart from complaining about everything about this site , what plugins do you have that are not working ?. If you have difficulties with plugins you have installed the support sections are there to help resolve the issue, But i have the feeling that you will not be satisfied unless this site mirrors whatever site you used to use for a completely different game.

As example plugin X providing value Y that i used by another plugin Z
but plugin B is generating another value A and this is used by plugin C, D and E

What is if u want to have Plugin Z to work with value of plugin B ???

Guys at the moment you have xxxxx plugins with yyyyy values and maybe xxx plugins using yyy values but there plugins using zzz value instead of yyyyy and dont work with each other.

U know the Italian Card Game Scopa ?  X card has Y value and u can collect XX cards with Y value to win in the end with Y value. But u can create otehr games based on this system......

So a unified value by uMod/Oxide would solve a lot issues that will happen with more plugins and already is a problem .....
Umod could store values and u can set, fix, add this as needed so all plugins use it as they want instead of seperating them and killing XX plugin just because XX plugin no longer exist or is BUGED

You punish and limit the advantage of the API etc. features of the year 2021 and push them back to stoneage.

The scheme would than be

Plugin X request value Y from uMod/Oxide Database, Value Y is also used by Plugin Z, G, H
Plugin X is creating new value with T and is storing it local
Plugin Z is creating another value with Y and storing it locally
Plugin G is using Y value and creating K value and store it on uMod/Oxide databse but also creating P value locally

and this Y,K,P could be used ba other plugins but and this is the important part value K and Y always exist doesnt matter what happens to all the other stuff. And it is unified on one place.

What you are asking for is a standardized way to store data to be shared across plugins, from what I can tell. I don't really see how that would work, as one plugin still has to set up that value before others can use it. There's no reason for Oxide or uMod to try to expect and provide for every possible thing a plugin may want to access a service or otherwise.

Plugins exist to provide the functionality you want with various services, not the core. The core is there to allow those plugins to talk together and provide a means for them to do so.

If you have a more specific example, they would be helpful, but from what I can tell, you are asking for things that do not really belong in the core nor would they make sense to be.

Wulf

What you are asking for is a standardized way to store data to be shared across plugins, from what I can tell. I don't really see how that would work, as one plugin still has to set up that value before others can use it. There's no reason for Oxide or uMod to try to expect and provide for every possible thing a plugin may want to access a service or otherwise.

Plugins exist to provide the functionality you want with various services, not the core. The core is there to allow those plugins to talk together and provide a means for them to do so.

If you have a more specific example, they would be helpful, but from what I can tell, you are asking for things that do not really belong in the core nor would they make sense to be.

You can implement really just the basics.
As example Steam Checks. Steam Cheks should get xxx information from Steam API to work.

But what (like it actually happens) when Steam Developer guys decide to change it ? When uMod is providing this information lets say Steam Username is a called Value X but STeam Developer decide to change it to XY now Steam Checks is no longer able to get this informations from Steam API. But when uMod provide this X and now XY as a static unified value just uMod has to implement the new changes and all Plugins that use value X still work. It makes it also lot easier to write plugins for uMod.

This also happened with the plugin Analytics the have changed the way of usage (for new stuff) .... https://umod.org/community/analytics/29408-update-for-latest-google-analytics-version

Man guys .... dont be such straight guys be creative. Just because i bring an example shouldnt mean you can use thgis for ur own creative idea. I dont know what happens with all the ppl on this f**** Earth but most are just to tired to think more than the words the can see (and some also cant read). Its a general thing has nothing to do with you ^^

BestNoob

You can implement really just the basics.
As example Steam Checks. Steam Cheks should get xxx information from Steam API to work.

But what (like it actually happens) when Steam Developer guys decide to change it ? When uMod is providing this information lets say Steam Username is a called Value X but STeam Developer decide to change it to XY now Steam Checks is no longer able to get this informations from Steam API. But when uMod provide this X and now XY as a static unified value just uMod has to implement the new changes and all Plugins that use value X still work. It makes it also lot easier to write plugins for uMod.

This also happened with the plugin Analytics the have changed the way of usage (for new stuff) .... https://umod.org/community/analytics/29408-update-for-latest-google-analytics-version

Man guys .... dont be such straight guys be creative. Just because i bring an example shouldnt mean you can use thgis for ur own creative idea. I dont know what happens with all the ppl on this f**** Earth but most are just to tired to think more than the words the can see (and some also cant read). Its a general thing has nothing to do with you ^^

I think Wulf's previous point can be applied to that aswell. The core is there to allow plugins to talk to each other, not to provide functionality.

Man guys .... dont be such straight guys be creative. Just because i bring an example shouldnt mean you can use thgis for ur own creative idea. I dont know what happens with all the ppl on this f**** Earth but most are just to tired to think more than the words the can see (and some also cant read). Its a general thing has nothing to do with you ^^

Or even too tired to spell (?)

And the only reason for proposing change and showing examples of what you want changed is the expectation that that change will (or could) be adopted, But with that proposal should be the appreciation and realisation that the change (proposed) might not be appreciated or welcome or might even be impractical.

Not all games use Steam, so providing that info via Oxide or uMod wouldn't always make sense. Both Oxide and uMod already provide a way to get the username, but that isn't always based on Steam due to what I mentioned previously.

Support for Google Analytics in the core also doesn't really fit, as it is a random third-party service that doesn't really help make plugins easier, it would just be throwing a random plugin in the core that would be barely used.

Just because something becomes outdated with a service doesn't mean it would be instantly fixed in the core either, as it would take the same amount of time to fix it in the core.

Our frameworks aren't here to be a "I want it all in the core" mod, it is a "here are the tools to make things" framework.