So I'm thinking we add a way to add new blocks to Chisel directly by similar methods of iChun's hats mod.

Instead of releasing new blocks through new chisel versions, we could shift them to client downloading on launch. We could have a server that collects all new code and images from this repo every 24 hours, at 4AM EST/1AM PST. Clients can request the manifest from this server and if they differ, the client downloads the differing files.

We can implement this by moving our entire features class into a json file. This means we can put all real mod changes into releases and trivial changes (new blocks) into client downloads. For each version that we introduce new instances of BlockCarvable, we can leave behind legacy jsons so we don't go introducing problems to legacy clients.

Now begins your usual collecting of chairs and pitchforks and breaking them over each other's heads sitting down and discussing these radical improvements like refined gentlemen while you sip your cups of tears of problematic end users who are using the wrong-versioned install of Forge and AUTOMATICMAIDEN's version of chisel high-end quality tea.

What happens if this fails? IE: no internet access.

your BlockCarvable would need to use NBT, then, so new blocks would just be missing texture. And new blocks could have the client ping the DL server...

Um, what do you mean?

its more work then its worth imo

This seems like it could cause a mess. What if a client without certain blocks (for some reason) joins a server with the blocks?

@yrsegal The client can ping the game server it's about to connect to as to what blocks are diff. If differrent the client is told to re-dl and close.

You don't want client crashes if you see a new block on a server, do you? So, you'd have to use NBT. Pretty much no way around it. And if a block isn't in the registry for chiselables, it could check the server that has the block json for updates.

@TheDoctorSoda What do you mean? The game should be able to launch normally?

Downloading unconfirmed data from servers is a _HORRIBLE_ idea.

@tterrag1098 Our Content server only, not the game servers... I'm not that stupid :P

@Drullkus that would be an elegant solution. or it could just re-dl on a mismatch, and then try to reconnect. (think that answers @TheDoctorSoda's concerns too)
On second fail to match, it could stop trying to connect.

They can opt-out via configs... :P

It's still unconfirmed. What if the server is compromised?

Opt-out of what? All of chisel?

Sorry but this is a tried-and-failed idea, it's far too much effort and too error prone.

We could allow downloads for manual content additions.

I feel like some people will have issues installing a mod that downloads data from any servers...

I'm sorry but I completely agree with @tterrag1098 here. Good thought, Bad idea.

@tterrag1098 I'm kinda thinking about AWS though. AWS seems pretty good for this function.

If you can somehow pull this off, I'd use it. But personally, I don't see this happening without issues.

I'm planning on writing a chisel addon featuring models, so I may follow a bit close to ichun's tracks as to hats

Another agree-er with @tterrag1098. It would be very cool if it could work, but too many things can go wrong.

AWS would differ from a normal VPS how? Also it's yet another out-of-pocket cost (potentially terabytes of bandwidth per month downloading textures).

Hmm. Alright. I might experiment with this with an addon. Otherwise, case closed :\

@tterrag1098 Amazon S3 has specialized services specific to just doing content delivery and nothing more.

On Sep 05, 2015, at 08:31 PM, tterrag1098 [email protected] wrote:

AWS would differ from a normal VPS how? Also it's yet another out-of-pocket cost (potentially terabytes of bandwidth per month downloading textures).

—
Reply to this email directly or view it on GitHub.