Support_Updater

[Goth77]

My apologies. This is the code that Support_Updater uses to update RTB:

Code: [Select]

%crc = getFileCRC("Add-Ons/System_ReturnToBlockland.zip");
if(%crc $= "-343036381")
%channel = "DAProgs";
else if(%crc $= "-642662817")
%channel = "Port";
else
%channel = "NO_INET";
I overlooked GRTB while writing the code.

It's alright I know you got your hands full with stuff. For when you get the time

Code: [Select]

(CRC:-1383460313)


[Ad Bot]

[Demian]

Whoa whoa whoa, what is this stuff?

Code: [Select]

Updater checking repository DemiansAddOns
DemiansAddOns does not own Brick_Doors_Demian!
DemiansAddOns does not own Brick_Doors_Demian_Arched!
DemiansAddOns does not own Brick_Doors_Demian_Big!
DemiansAddOns does not own Brick_Doors_Demian_Eastern!
DemiansAddOns does not own Brick_Doors_Demian_Half!
DemiansAddOns does not own Brick_Doors_Demian_Other!
DemiansAddOns does not own Brick_Doors_Demian_Thematic!
Updater checking repository DemiansAddOns
DemiansAddOns does not own Brick_Doors_Frameless!
I finally got my new repo up and running and now everything is broken? I was going to roll out an update sometime soon that was going to change the repo URL in the version.txt of those add-ons. It worked with Brick_Doors_Frameless for me but now this happens.

Old: http://blockland.dataorb.net/repository.txt
New: http://blockland.dataorb.net/repository/ & http://blockland.dataorb.net/repository/repository.txt

[Greek2me]

It's just overlap. Once you update all of them to the new URL, those errors will go away.

It'll be much clearer what's going on if you temporarily name the repositories different things. Basically the new repository is saying "I own these add-ons: A, B, C", but add-ons A, B, and C specify in their version.txt file that they're owned by the old repository. The same happens in reverse: the old repository claims to own Brick_Doors_Frameless, but Brick_Doors_Frameless specifies the new repository in its version.txt file.

The error is harmless so long as you control both repositories. The purpose of it is to prevent people from taking over others' add-ons using their own repository.


Also, I see that you got the PHP script set up. Very nice.

[Demian]

It's just overlap. Once you update all of them to the new URL, those errors will go away.

It'll overlap for anyone with the old add-ons and there's no way for me to be sure when all ~50 people have updated their add-ons. I'll need to look into file redirection.

Also, I see that you got the PHP script set up. Very nice.

With a bit of Googling and poking around some other PHP scripts on my server I was able to figure it out. Here's my script in case anyone else is interested.

Code: [Select]

<?php
$counter = "queries.db"; // Permissions: 777
$pldb = "players.db"; // Permissions: 777

// Get the number.
$queries = file_get_contents($counter);

// Count the lines.
$players = count(file($pldb));

if(strstr($_SERVER['HTTP_USER_AGENT'], "Torque"))
{
// Support_Updater
$repository = "repository.txt";
$user = $_GET['user'];

// Player name not null.
if($user !== 0)
{
file_put_contents($counter, ++$queries, LOCK_EX);

// "Privacy", now with less collisions!
$hash = hash("sha1",$user);

// Hash not in database.
if((strstr(@file_get_contents($pldb), $hash) === false))
{
file_put_contents($pldb, $hash . "\n", FILE_APPEND);
}

// Show Support_Updater the repository text file for updating.
header("Content-Type: text/plain");
ob_end_flush();
readfile($repository);
}
}
else
{
// Browser
$queriesPerPlayer = round($queries / $players, 1);

echo "<p>Repository queried $queries times from in-game by a total of $players unique players averaging at $queriesPerPlayer queries per player.</p>";
}
?>

[Greek2me]

It'll overlap for anyone with the old add-ons and there's no way for me to be sure when all ~50 people have updated their add-ons. I'll need to look into file redirection.

That's the best option. I used Apache's mod_rewrite. The other option is to just leave the old repository file in place indefinitely.

[Ipquarx]

I wouldn't use md5 if I were you. Collisions. Collisions everywhere.

[Demian]

RestartRequired tag doesn't work? My add-on was at 1.0.1, updated to 2.0.0 and it didn't require a restart even though I defined it so in Brick_Doors_Frameless: http://blockland.dataorb.net/repository/repository.txt

[Greek2me]

RestartRequired tag doesn't work? My add-on was at 1.0.1, updated to 2.0.0 and it didn't require a restart even though I defined it so in Brick_Doors_Frameless: http://blockland.dataorb.net/repository/repository.txt

Set the restartRequired tag to the version that will require the restart. You would need to set it to 2.0.0.

However, server-sided add-ons typically do not require a restart.

[Demian]

However, server-sided add-ons typically do not require a restart.

I'm adding a new datablock though?

[jes00]

I'm adding a new datablock though?

Updates done with Support_Updater happen when you first start up Blockland. So unless it's a client sided mod, it does not need a restart.

If it happened after you made a server, then it'd need a restart.

[Demian]

I wouldn't use md5 if I were you. Collisions. Collisions everywhere.

Thanks, I had no idea. Changed to CRC32 and updated the post above.

Updates done with Support_Updater happen when you first start up Blockland. So unless it's a client sided mod, it does not need a restart.

If it happened after you made a server, then it'd need a restart.

Oh okay, thanks.

[Ipquarx]

Thanks, I had no idea. Changed to CRC32 and updated the post above.

crc32 is even worse because it's not meant to be resistant to collisions, use sha1 (which is plenty secure enough) so just replace "crc32b" with "sha1"

[jes00]

Yeah. Bump.

Are you still working on this? You should fix the console error that occurs every time you try clicking the X on the options GUI.

[Greek2me]

Yeah, I can do that whenever I next work on it.

[TheBlackParrot]

That unix-like package manager idea you had a while ago still sounds like a nifty idea.
If you're still considering it, pacman seems like a decent one to base it off of