Mtasa-blue: A new way to auto-start resources

Created on 31 Oct 2019  Â·  9Comments  Â·  Source: multitheftauto/mtasa-blue

Describe the solution you'd like
Hey, I was wondering here, why not add a startup parameter to meta.xml?
As there is already a meta reading when starting the server, the resources that had the startup parameter would be started automatically and the same would apply when using commands as refresh.

Describe alternatives you've considered
1

Additional context
Yes, I know there are many other ways to auto-start resource, as startResource function, mtaserver.conf, in my opinion this could be a good improvement

enhancement

Most helpful comment

👎 and i vote close

All 9 comments

I think that resources get started only if they get called, can meta.xml trigger itself though?

This would be possible, but do you have a reason as to why this feature should be added? _Why_ is it a good improvement?

What are the advantages of introducing an <autostart>1</autostart> in meta files vs. the current method of adding <resource>s to the server config?

Does it just provide an alternate way of auto starting resources, or are there some other advantages?


One disadvantage of this feature is that it is no longer easy to find out which resources are going to be started by default.

Someone would have to look through both mtaserver.conf (for <resource> entries) AND look through each resource. To make the latter easier, someone would have to write a tool/script to loop through every (potentially zipped) resource and look up the <autostart> field.

One would also argue that it decreases the separation of concerns between server config and resources themselves.

Decisions about whether a resource should be started (outside of dependencies) isn't of concern to a resource - it's a thing that the server decides. So a resource config (meta.xml) shouldn't decide whether or not it is auto-started, the server config should (mtaserver.conf).


Note that if we implement this, we'll also need to update the community website to strip this setting or require it to be unset (when new resources are uploaded).

One disadvantage

One more — it would mess the startup order if implemented.

In my opinion, this would help because when adding a resource to the server, to create an auto-start you must add it to mtaserver.conf, and to take effect the server should be restarted, right?
With this new functionality would be more practical because if there is the auto_start field, just typing for example "refresh" in the console, if there were no errors the resource would be loaded and started automatically.

Note that if we implement this, we'll also need to update the community website to strip this setting or require it to be unset (when new resources are uploaded).

Of course this could be dangerous and could also end up causing problems if a person adds a resource without first checking if this option is enabled in the meta.xml, and by talking to Haxardous, he came up with the idea of ​​having a field inside the mtaserver.conf, which could enable/disable this functionality, such as 0
which would be disabled by default, meaning it would be 100% optional.

it would mess the startup order if implemented.

and what about download_priority_group param?

and what about _download_priority_group_ param?

It wouldn't be usable, because then you have to check this param of each resource before set it. One list is simpler and better.

Why can't you just do start resource after refresh? It will work until restart the server. And after restart the resource will be started via mtaserver.conf. Current solution is a lot better than your solution.

this feature doesnt make sense at all, and it would just make everything more complicated.

if you really want such a feature, just write a resource to do so.

👎 and i vote close

as i said, this would be a "optional" startup way, and i agree we have many other ways to do it, and i think it could be a good thing, but i know it shouldnt be a thing too important for now

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rk-r picture rk-r  Â·  4Comments

ALw7sH picture ALw7sH  Â·  3Comments

Haxardous picture Haxardous  Â·  3Comments

patrikjuvonen picture patrikjuvonen  Â·  3Comments

LosFaul picture LosFaul  Â·  4Comments