Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - DontCare4Free

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 327
62
How will this actually work, what does the user have to do to update?
The user downloads the add-on through a special website, which downloads it from GitHub/Bitbucket and repackages it with a metadata file. When the user launches blockland it connects to the server and asks for the latest versions of all the installed add-ons. If any versions mismatch then the user will be prompted with a list of out-of-date add-ons, each entry containing information about the current version, new version, a link to the diff, and an option to download the update. Selecting to update automatically downloads and executes the add-on.

How does what detect updates to the github?
There is a server which queries GitHub for the latest versions, as well as doing applicable caching. The client compares SHA commit hashes, and prompts an update on any mismatch.

63
Here's what I do, since it seems to serve both interests.

  • The add-on is hosted using the RTB service.
  • I have an update-notifier service which lets clients know that there is an update and displays the change log.
  • The clients update the mod from in-game. For RTB users, the mod is downloaded directly using the Mod Manager. Non-RTB users are taken to the mod's page on the RTB website.
That is not at all what this is trying to do. This is an attempt at making an auto-updater that:
  • Requires no (manual) modification of the add-on itself
  • Is automatically synced from version control
Your method is pretty much opposite of these goals, instead solving a completely unrelated problem (displaying update notifications for RTB add-ons even when RTB isn't installed).

64
Nullable, perhaps implement a method for blacklisting any add-on that pushes out malicious code, preventing it from being used?

I do agree with Ephi here, this could be pretty dangerous without some form of moderation.
While I'd rather not store anything permanently on the server, it should be possible if the need arises.

65
Not sure how that was a response to what I said.  I'm not contesting the usefulness of this - it just has vast potential for abuse. The fact that anyone with a well downloaded add-on can just flip one day and decide to push out some malicious code over this thing to all their users makes it a danger. Even if it was discovered that an update contained an issue - what next? Someone has to get a hold of you to take down the repo to prevent other oblivious users from continuing to update.
What is there preventing you from pushing out a malicious update to RTB? What is there preventing me pushing out a malicious update for Permissions?

I don't think pre releases should be handed out to all users anyway - that makes it a full release. I think it makes sense for pre releases to require you to make the effort to go to the dev thread, read about what you're downloading and the risks it entails so you can make a sensible decision.
Exactly. You go to the dev thread, download the add-on, and this notifies the user when the prerelease is updated. It won't propose for you to update from the stable release to the prerelease.

66
It's absolutely not. Once people decide they're done playing Blockland, that reputation means nothing to them and they're free to forget up whatever they want with nothing holding them back - and this has happened far too many times to count now.
This is a risk you take when you install someone's add-on regardless.

I'm "into scripting" and I can't imagine myself ever doing that. The 99% of people who aren't into scripting also won't ever do that so it's fairly pointless.
Valid point, but it's there so that you can choose to review the update without too much information overload. For example, here's the diff between the two last versions of Permissions.

Blockland add-ons are barely reliant on having a strong reputation. I could create a new account, release some stuff gun mod, have a thousand users over the course of however long that takes and then flip a switch to provide everyone with an update that hijacks their key entry screen. People would be rebooting their games and handing their keys over to me within minutes.
Low-maintenance add-ons such as weapon packs are a pretty good example of where RTB shines. The scripts aren't very complicated, there's little that can go wrong, there's not much to change after the fact. Compare this to, say, Slayer, RTB or Permissions which are bigger add-ons made by people you already trust, and with more moving parts and more that could go wrong (increasing the value of prerelease testing, which is one IMO the area where BB shines).

67
The reason RTB has high latency for updates is to ensure there's security for users (plus a lack of mod reviewers atm). This is just a way for anyone with repo access to semi-immediately push anything they want with no kind of oversight to everyone who has their add-on.
Security vs convenience. RTB provides better security with it's mod review, but on the other hand it doesn't work very well for prereleases, because then you want to push out an update fast (and I'm not sure about what the rules say about those anyway). Besides, this is essentially how the add-ons forum works already, and you can already roll your own auto-updater if you want to, this just makes it less of a hassle.

This isn't the real world where developers of popular software have reputations and integrity - this is Blockland where most users will screw eachother over without a second thought. Babysitting is absolutely required. If this is to be released I think you're going to need to educate and warn potential end users on the substantial risks of accepting any kind of code updates from basically anyone.
While it may not be as lasting, reputation is still definitely a thing in Blockland.

Because you can be sure that an add-on that is on RTB is going to be secure
See the above.

Think of a situation, let's say someone creates a huge ui overhaul that almost everyone downloads, and because someone has pissed him off he wants to get "revenge" and uploads an update to delete everyones saves and add-ons

How would you prevent that?
I wouldn't. I don't believe it'd be beneficial in the end to severely limit the usefulness  just because of the off chance that someone might push a malicious update (ruining his/her reputation, would you run an add-on by cciamlazy?). That said, of course, updates wouldn't be interactionless (you'd still have to OK the installation of the update). In addition, to mitigate the problem, the GUI could give you a link to the diff between your current version and the update, giving you a relatively convenient way to review the update yourself if you're into scripting.

69


Today, when developing an add-on, your options for auto-updating usually consist of having none, building your own, or using RTB.

With all three options you usually end up having to repackage your add-on every time you release it. In addition to this, each approach has it's own disadvantages. Having no auto-updating at all quickly gets tedious for your users if you need to update something, and people aren't very likely to actually update. Building your own takes a non-trivial amount of work, and delivers an inconsistent user-experience to your users. RTB has a lot of latency, and it's not unusual to have to wait for days, if not weeks, before your add-on or update is actually released to your users, making it inconvenient for regular releases and almost impossible to use for beta releases and similar. What if releasing an update was as simple as pushing the update to your Bitbucket or GitHub repository, and it'd then be released to users within 5 minutes?

So is this a replacement for RTB, then?
No. RTB provides a lot of features that Brickbucket does not even plan to offer, including stuff not related to add-on management (RTB Connect), as well as a useful service for discovering add-ons. Brickbucket is supposed to come into the picture after you've "sold" the add-on to the user.

Features
  • No extra effort for you as the developer, just push it to Bitbucket or GitHub as usual (make sure to structure your repository layout like this)
  • Updates released to users within 5 minutes
  • In-game auto-updater
  • Web-based endpoint that automatically repackages your add-on for Blockland, and includes the metadata required for Brickbucket to function
  • Open source

Status
Server - Working
Client - Not yet started

Links
Server Bitbucket repository
Issue tracker

70
The forget?
Now I'm supposed to make programs with JavaScript?
If you want to have it run in the browser, yes.

71
What, are they outdated?
If you have another suggestion let me know.

I just wanted a convient way to get programs I'm writing to people who can see them.
This is far more convient for the potential user/player than downloading and installing a game I wrote in C++.
Somewhat. The major point was that you could do more advanced stuff with it than was possible with JavaScript at the time. Nowadays most of those limitations aren't there for JavaScript any more, and the applet warnings from browsers have gotten scarier and scarier (since it's an additional exploit vector with an ever-decreasing legitimate use-case).

72
Dropbox public folder. Put a your jar and a HTML wrapper that loads the applet in it. That said, what do you need Java applets for nowadays?

73
Off Topic / Re: Mid-Year Cleaning
« on: June 05, 2013, 02:34:50 PM »

Get on my level.

You were saying?

74
Off Topic / Re: Should I switch from Windows 7 to Linux?
« on: June 05, 2013, 02:28:19 PM »
Stick to W7 for now, the pros outweight the cons (but that's going to change in a couple of years, maybe.)
I disagree. Linux is a viable alternative for most purposes nowadays, unless you play a lot of AAA games that don't play nicely with WINE or need it for professional work in an area where the industry-specific stuff doesn't run well under it. For example, CivV is a bit messed up, and I doubt CoD would work that well, but many Indie games are either natively ported or run fine under WINE. Blizzard games also tend to work well under WINE.

Unless if you wear a fedora, support MRA's and strictly only listen to dubstep.
Can we stop with the stereotyping and hear some real arguments instead?

I'd say to try it out in a virtual machine to see if you like it enough to use it as a main operating system.

One thing I would advise not to do is to completely erase windows 7. If you find that linux is your thing, look up a tutorial on how to dual boot it with W7, so you can use both interchangeably.
This, absolutely.

Have you decided on a distro? If not, if you're new to linux, Ubuntu or Linux Mint will probably be the easiest to use.
While I admire Ubuntu's purpose, personally I've had far more "out of the box" success with Arch. However, Arch requires quite a bit of manual work, especially to install (which is a double-edged sword, it requires more work and takes more time, but it teaches you more about how it works under the hood and you get less unused crap). I have no personal experience with Mint, however.

Tripleboot W7, Mint, and Cinnarch.
Pointless in most cases to multi-boot multiple distributions.

75
Development / Re: 2013/06/01 - Blockland Sales Data
« on: June 02, 2013, 11:51:51 AM »
You should add about the trust system and how it's nearly impossible to grief.
The trust system adds it's own griefing attack vector.

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 327