Introducing JARVIUS! [Feedback wanted]

[macsipac (丁の大之丁)]

When you roll out an update for your roblox game, whether it be a bug fix, adding more content, or fixing a critical data loss issue, servers created before that update do not get it.

Thats where JARVIUS (just a rather very intelligent update system) comes in!

Once placed in ServerScriptService, it will automatically detect updates to your game and restart every server! (This is completely automatic, and yes, i said restart, not shutdown)

Sadly, no, we cannot break the laws of physics :P, servers have to include JARVIUS for it to work, so old servers that were created before JARVIUS is added will not update, so you will have to update or shut them down manually.

(Due to how this system works, when updating, it will create a server of your game and immediately try to delete everything in it, but JARVIUS is not always run first in the game, so code in your game may run in the update servers)

Free model link: https://create.roblox.com/store/asset/118909113695613

(No, this is not associated with marvel in any way)

[baj_dev (baj)]

Ever heard of “Migrate to Latest Update”?

[macsipac (丁の大之丁)]

even if that works, you still have to press a button :P, JARVIUS is completely automatic, made because i often forget to migrate servers

[road963 (April)]

The purpose of this code is to display an update screen and then teleport players to a new server during updates. Your “Migrate to Latest Update” feature doesn’t do this; it doesn’t migrate players, it just kicks them. According to data from a previous module, this causes a large portion of the player base not to return.

As stated on the DevForum: Introducing Migrate to Latest Update - #5 by TheCarbyneUniverse

Karun (karunamat9ta ), Roblox Staff, said: “Thank you for your feedback, migrating players automatically is something we will consider doing in the future.”

Please, before you say something, look into the module itself. The OP’s idea is excellent because it solves a problem from old posts! I forgot the name of the module that did the same thing, but congratulations to the OP!

The only risk with this module is that it’s dangerous for metrics. After all, it looks like all players left, but they actually came back. The metrics don’t see this; they just see the player count dropping.

Hmmm, I think there was a lack of text interpretation… I think. I said ‘Migrate to the latest update’ is about what Baj Artembon unnecessarily sent above, that’s why I’m responding to him…

what baj Artembon said is like you didn’t need the OP code to update

if you only use the “Migrate To Latest Update” it closes the servers and some players may not even come back, whereas the one from OP you wouldn’t have to worry about that, it migrates the current players and a larger part of the current player base remains.

[real_ryanx (Ryan)]

@road963

Please, before you say something

how about you confirm that it does that? It doesnt kick the players. It teleports them to a new server like the script does. Also the idea of it is to teleport players to a new server when it detects an update

[avodey (avocado)]

@road963

Your “Migrate to Latest Update” feature doesn’t do this; it doesn’t migrate players, it just kicks them.

When you migrate servers, all players are teleported into new and updated servers seamlessly. Your game’s code can also provide a transition screen using game:BindToClose.

[avodey (avocado)]

For those wondering what this resource actually looks like, here’s a video of it in action.

Streamable Video
Google Drive Video

It teleports all players to new servers when the game is published, not saved. In my opinion, the transition screen looks awful and should be overhauled. But it works, at least.

The built-in Migrate to Latest Update button on the experience page is superior though, we should all be using that instead of soft shutdown scripts.

[road963 (April)]

I was responding to the baj Artembon D:

[avodey (avocado)]

Unsure what you mean by this, I was just correcting what I saw in one of your posts.

[road963 (April)]

What I meant to say is that the first comment on this post suggested using Migrate To Latest Update as if the OP’s code was useless and not helpful at all. Anyway… forget it.

he says “Ever heard of “Migrate to Latest Update”?”
What does that have to do with the OP’s code?

so I say “Your “Migrate to Latest Update” feature doesn’t do this; it doesn’t migrate players, it just kicks them.”

[avodey (avocado)]

@road963

he says “Ever heard of “Migrate to Latest Update”?”
What does that have to do with the OP’s code?

This resource and that option both have to do with soft shutdowns. The sarcasm implies that he believes the resource is pointless because there’s already a built-in way to do this. I agree.

@road963

so I say “Your “Migrate to Latest Update” feature doesn’t do this; it doesn’t migrate players, it just kicks them.”

Shut Down All Servers kicks all players, Migrate to Latest Update migrates all the servers to the latest update. What’s confusing about that?

[road963 (April)]

There’s only one command missing to cancel the update itself… if there’s a game with only 2 places and the update of the second place needs to happen before the match starts in an average time of 10 minutes, what to do or in specific maps? it opens up more choices, I think.

If you want to go further, you could save the players’ position in the update; a previous module that existed for the same purpose did that.

But instead, it would be better to have something more external for whoever uses your code to choose what to save in a table and send to the next map, whether it’s to MemoryStoreService or Datastore, then you get the new place.

Like being able to store a function to execute an hour before the update happens, that would avoid having to change the code for that.

If someone wanted to edit your module, you could specify what names the GUI elements should have so that it can be changed without impacting the code itself.

You also have to be careful with teleportation; after all, there’s the Datastore, and it would be many requests. Being able to put a ‘wait’ in the middle is sufficient.

By the way, it would be cool to put a Module with --[[
# general explanation about the module

]]

Also, I think it will look like this:
JARVIUS
RequireJARVIUS
Explanation

local RequireJARVIUS = module(…/RequireJARVIUS)

RequireJARVIUS.Execute(function()
– a command to execute when the update happens
end)

RequireJARVIUS.Data_For_NewServer(function()
– executes when the first player enters the new server
– I think it’s even good for you to use the MessageService for communication between both servers, what if the first player who enters simply closes the game along with the server?
return {1 + 1} – stores in MemoryService according to the New Server ID or DataStore
end)

inside the module

RequireJARVIUS[“Configuration”] = {
WaitForTeleport = 60,
WaitVerifyUpdateServer = 2,
RetryVerify = 5, – to avoid getting the wrong version, I don’t trust Roblox much…

}

I almost forgot, you are automatically expelling those who fail the teleport, which is good; it might be worth adding a memorystore so that when the player joins, they can return to the server they were in, but that will depend on the playerAdded of the game.

However, I think it is possible to implement this, since why would a banned person have a memorystore of a previous server?

Putting a true or false in the module’s configuration for this would be good or a line of code for someone to add if they wanted that, plus a system to clear the memorystore in case there is a memory failure.

I used Google Translate if I seem arrogant, etc., sorry (. . )

[macsipac (丁の大之丁)]

thanks for the feedback xd (sorry for very late response, i was on vacation)
ill make the update screen better