This week, Mojang has begun the long process of separating the server logic from the client. They hope to make it easier to add features in the game going foward - essentially not having to program in game additions twice, for two functionally different "Minecrafts" - and also to make it possible for players to invite their friends to play on their local computer without setting up a server. While the intent to begin migrating was announced in the past, this Snapshot begins taking the first step into realizing it fully. Note - the changes are NOT complete, but the game should run normally.
Now, on to the changelog:
More fixes to silk touch and block picking
Wooden tools work in furnaces
Villagers spawned from spawning eggs will get a random profession
Updated language files
Miscellaneous editions
The download links are slightly different than prior Snapshots - the link below is the client ZIP, not JAR; it contains both client-side and server-side JAR files. The Server JAR link is as it has been for previous Snapshots.
Downloads:
Client ZIP: [url='http://mcf.li/JtsrdC']Download[/url] (This is a ZIP file containing client- and server-side JAR files)
Server JAR: [url='http://mcf.li/IIJUCG[/url]Download[/url]
Enjoy this first glance into some very exciting changes!
So i decided to test this whole 'not able to play single player when not connected to the internet' business.
Step 1: Downloaded and installed the snapshot into the necessary locations
Step 2: Went to the Win7 network manager
Step 3: Right clicked on my network card and clicked on 'disable'
Step 4: I am now no longer connected to the internet, web browsing ceased to work, anti-virus couldn't download updates, etc...
Step 5: Loaded up Minecraft Launcher
Step 6: Minecraft Launcher complained because it couldn't update the news feed
Step 7: Clicked 'login'
Step 8: Launcher failed to log in and told me to either "Try Again" or "Work Offline"
Step 9: Clicked on "Work Offline"
Step 10: Clicked on "Single Player"
Step 11: Clicked on "Create New World"
Step 12: Clicked on "Create New World"
Step 13: Took a couple of seconds to generate the world, said 'Logging In...' then hey presto, i am now playing single player completely offline from the internet.
Only thing i can think of is that those who can't get it to work, have either installed it incorrectly, or haven't even bothered to try the snapshot.
I got 70FPS, which is normal for me for a freshly created world, it normally goes up to 100FPS after about 2 or 3 mins.
My computer specs aren't exactly the best in the world:
At the time of this test, i still had chrome open with 12 tabs, 4 of those tabs were consuming up to 100MB of RAM each, i also had Skype running (offline of course) consuming about 100MB, Steam client running (again offline) consuming about 100MB, plus a text based game that i play all the time too, and a whole lot of little extra things running in the background, each consuming memory of their own.
I have to play with graphics set to 'Fast', otherwise my FPS tends to be seriously crappy (at least in SMP), and i play on 'Far' rendered distance with FPS set to 'Balanced'.
I built this computer back at the beginning of 2010, the CPU and RAM are the 2 biggest letdowns in my system.
Does not take away the fact that there is still server code, and you cannot pause it, it is still essentially a stupid server instead of solid single player only mode.
Do you not understand the whole reason for development versions of software/games?
Would you complain this way if you were playing a beta version of the game? Because the development snapshot is just that, in-development.
Minecraft will still have single player. Stop complaining that the development version is broken and/or stupid, because that's what it's for. Being broken and trying to figure out if it's stupid. I downloaded, ran, and used the snapshot with 0 issues besides reported bugs that I was already aware about. Internet went out while I was playing, and I went on without a hitch.
For everyone complaining that someone could just drop in and ruin your server, no. Your 'server' runs as a local entity. Unless you set specifically that the port that you specify is open, and routed to minecraft, etc. Nobody can 'drop in' on your game.
So why not chill and wait for the actual final release?
Also: If jeb and mojang don't integrate the client and server software, then choosing a 'host server' button will never be able to happen.
And the pause feature will more than likely return when things are sorted out correctly. It'll take some time though, so chill.
running a server from a client is extremely recourse demanding so any hope of optimizing for bad/old computers is now dead, also now this creates a huge problem for client stabilization because if your client crashes so dose your server, so crash bugs will be unacceptable
umm... lan ya that works if you have like 10 computers in your house connected, and you all live with in that area. honestly who dose though? and no, no one uses lan.
I am having a lan party at my house next weekend.
Yes, people still use LAN.
This is a pretty awesome update but I hate it that they removed singleplayer because all your singleplayer worlds get changed to multiplayer and that is not what I am worried about I am worried that all the multiplayer bugs come with this update so a lot of redstone machines destroyed and animals glitching.
All the snapshot did for me was delete my world that I worked HARD on.
That's what you get for not backing up, not to sound rude or anything, but snapshots are 100% in-development, you accept all risks and understand what it means to install a snapshot without taking proper precautions.
When server garbage is intergrated into Single Player, and is pretty much server ready, then yes.. it's not true single player, it's now an Always Online crapfest. When server issues are affecting SIngle Player things... it's no longer Single Player. It's online multiplayer with no one else logged in.
So you're just pissed off about a technicality that doesn't really affect you at all? Get over yourself.
This isn't a reply to the actual snapshot (which I'm still thoroughly testing), but more of what the snapshot represents. I hope someone (dev) from Mojang can at least read this and hopefully understand exactly what I am pointing out. I know this post is a little long, but it's as short as I can make it while getting all the necessary information across.
Getting rid of SSP functionality in favor of SMP (with localhost support, i.e., you connect to yourself) would indeed solve the problems of two Minecraft versions (client/server) and allow for people to host games from inside the client to invite friends without setting up a server. In theory, it's a good idea, but In practice, it's really a bad idea given how things are already setup in Minecraft.
What I would like the point out, is that this is not the only solution to these problems, and it certainly isn't the best solution. There is another solution that I would like to bring to attention in case it has not been looked into yet. This solution would allow SSP to exist alongside SMP, without having two different sets of code to manage, all the while allowing new functionality to be added to accomplish the specific goal of allowing people to handle server creation and joining a lot easier without over complicating the existing code.
To put simply, you keep MinecraftServer.java package separate, Minecraft.java package separate, but merge everything else. In essence, you are creating a shared library of all the other game code, so there is just one version the server and client both use. What results is one JAR file that has both client and server functionality, while both being independent of each other. People who want to play SSP/SMP start the jar's client package to play Minecraft and people who want to host dedi-servers start the jar's server package to host the server. So to say again, rather than having a client jar and a server jar, you have a single jar that has both of them inside it as a result of how the project would be setup.
While that might sound hard, complex, or like it would cause a lot of problems, it actually is none of the above (at least, in my opinion and in my experiences so far). It's rather straight forward, solves the issue at hand quite nicely, and allows for a modding system to be integrate that supports both SSP and SMP at the same time using the same coding concepts Minecraft already employs. All of this is possible because of how the existing code is already setup.
When I say this is because of "how the existing code is already setup", I mean that the client stays authoritative in SSP and when the client is in SMP, it is not authoritative. That is how the code is currently setup, and as a result, it can be merged together without any (observable) side effects. For example, if you join a server and aren't OP, you can't just use OP commands (unless there are bugs in the server that allow this to be exploited.)
About a month ago, I made a post detailing this idea: [PoC] Merging the Minecraft codebase. In my thread, I detailed my experiences of merging not the client and server, but everything else to accomplish the ideal goals of having one set of code to work with for both the client and server. As a result, my solution allowed SSP and SMP to coexist like they do now, but without the extra overhead of two different projects.to update.
I decided to take things one step further and actually play with integrating ModLoader/MP. For any SSP mod that did not add code that would require server handling in SMP, the mod simply worked with minimal modification with SMP. For example, I was able to drop in Biosphere and be able to use it in SSP and SMP, because it only modifies world generation (my last video shows that in the thread). Since the server now has ModLoader support due to the merged codebase, it just worked. Likewise, with mods like SimpleOres or mods that modify crafting recipes, no real extra work was needed.
From a porting perspective, SSP mods that add new GUIs or interactions the server would have to handle, they would have to have SMP code added for each of those interactions much like how the client does it with EntityPlayerSP and EntityPlayerMP. It's not terribly hard to do, but it would take a bit of time depending on how much code there is to update to add this functionality. That is nothing special though, as if you typically want to code a mod, it's going to take some time and work, right?
Now, I know that Mojang is not going to use ModLoader/MP, but my experience using it myself has led me to the following conclusion: if the modding API is setup correctly, then people will only have to mod one way, and it will support SSP and SMP at the same time. The burden falls on Mojang rather than the modding developers to get things setup this way, unlike how it is now, since ML/MLMP are community contributions that are separate from each other.
After actually doing this stuff myself, it just makes total sense. I was able to do it in a timely fashion using only MCP and some custom tools I wrote. I am confident in saying that Mojang could do the same with official source a lot easier, faster, and more accurately than I could. I actually did play around with different problems that might arise, but I can't think of any. In the end, everything stays the same as it is now (pre-snapshot), except there's one set of code to work with rather than two, which is what Mojang really needs.
The only issues with my current implementation is that I use ModLoader and MLMP, which weren't designed to do all the things that are needed for a successful long term SSP/SMP modding API. However, this isn't a true issue because once again, Mojang isn't going to be using their modding APIs but rather their own.
By using this solution, everyone wins. People who want to play SSP can still play SSP as they do now (pre-snapshot). People who want to host dedi-SMP servers, can still host dedi-SMP servers as they do now. When client/server specific updates are made, they are made to the appropriate files only once, and the changes apply to SSP, SMP, or both SSP and SMP. For example, if Minecraft.java is updated, obviously nothing in SMP changes, likewise if anything in MinecraftServer.java changes, nothing in SSP is affected, but if a change is made to shared files, both SSP and SMP are updated since they use the same shared files (baring non/authoritative logic).
The real work comes in writing the perfect modding API that allows for both SSP and SMP mods to be made. Most things are pretty trivial when it comes to shared code that is the same for both SSP and SMP. For example, let's say you want to add an API to register new crafting recipes. Since that logic is the same for both client/server, that API is easy. For something like registering new GUI menus and interactions though, more work is needed to properly wrap the underlying code for SSP and SMP so the modder isn't thinking in terms of SSP or SMP, but rather just a Minecraft mod. These are the things that have to be though of anyways for any API though, so it's nothing unique to this solution.
Hopefully this idea will be considered. If anyone wants to talk about potential issues, feel free to use my thread rather than this snapshot thread, as to not get too off-topic. Based on what I'm seeing from this snapshot's feedback though so far, I feel Mojang could use some more ideas. I have spent a lot of time asking myself, "why shouldn't Mojang use this approach", and I honestly can't think of anything that is a deal breaker due to how the code is already setup.
I am steaming at this new singleplayer=multiplayer thing. Here are my reasons:
1. You can no longer pause your worlds.
2. You can no longer play Minecraft without internet.
3. I am having trouble connecting to my own worlds.
4. Singleplayer now has a lot of bugs in it that are the reason that I don't play multiplayer much.
I really hope you remove this feature in the full 1.3 release, and I am pretty sure that lots of other people feel the same way.
All the snapshot did for me was delete my world that I worked HARD on.
So you just install development things on your machine without backing up anything? Smart.
I suppose you didn't see...
Quote from Jebs on blog post »
Important! This week’s snapshot is extra experimental!
I take it back, I guess you didn't see the warning since you got it off of here? Someone please add that warning! But still.. developement version doesn't say something?
How do I start an actual lan server? I open up the server.jar file but I don't know the IP for it??? I don't get it.
When you start a single player world it automatically starts the server. To allow others on the lan to connect, type your computer name (its kind of hard to explain getting your local IP) on the multiplayer section of others' computer
This snapshot removed my statistics, acheivements, changed all my worlds to survival and deleted all my stuff in every world.
Dont mojang test snapshots before releasing them?
Cool story bro. Achievement Earned! "Learn a Lesson."
Haven't you learned to make backups before trying a development version. And if it was perfect it would be in the launcher.
Actually, I use MultiMC, perfect for this kind of stuff. I recommend it to everyone using the snapshot.
*Smh*
actually no when any one person dies they get automatically banned
Step 1: Downloaded and installed the snapshot into the necessary locations
Step 2: Went to the Win7 network manager
Step 3: Right clicked on my network card and clicked on 'disable'
Step 4: I am now no longer connected to the internet, web browsing ceased to work, anti-virus couldn't download updates, etc...
Step 5: Loaded up Minecraft Launcher
Step 6: Minecraft Launcher complained because it couldn't update the news feed
Step 7: Clicked 'login'
Step 8: Launcher failed to log in and told me to either "Try Again" or "Work Offline"
Step 9: Clicked on "Work Offline"
Step 10: Clicked on "Single Player"
Step 11: Clicked on "Create New World"
Step 12: Clicked on "Create New World"
Step 13: Took a couple of seconds to generate the world, said 'Logging In...' then hey presto, i am now playing single player completely offline from the internet.
Only thing i can think of is that those who can't get it to work, have either installed it incorrectly, or haven't even bothered to try the snapshot.
I got 70FPS, which is normal for me for a freshly created world, it normally goes up to 100FPS after about 2 or 3 mins.
My computer specs aren't exactly the best in the world:
- Core 2 Duo (E7400)
- 4GB DDR2-800 RAM
- Gainward GTX 560Ti w/ 1GB RAM
- 120GB SSD
- Windows 7 64bit
At the time of this test, i still had chrome open with 12 tabs, 4 of those tabs were consuming up to 100MB of RAM each, i also had Skype running (offline of course) consuming about 100MB, Steam client running (again offline) consuming about 100MB, plus a text based game that i play all the time too, and a whole lot of little extra things running in the background, each consuming memory of their own.
I have to play with graphics set to 'Fast', otherwise my FPS tends to be seriously crappy (at least in SMP), and i play on 'Far' rendered distance with FPS set to 'Balanced'.
I built this computer back at the beginning of 2010, the CPU and RAM are the 2 biggest letdowns in my system.
Do you not understand the whole reason for development versions of software/games?
Would you complain this way if you were playing a beta version of the game? Because the development snapshot is just that, in-development.
Minecraft will still have single player. Stop complaining that the development version is broken and/or stupid, because that's what it's for. Being broken and trying to figure out if it's stupid. I downloaded, ran, and used the snapshot with 0 issues besides reported bugs that I was already aware about. Internet went out while I was playing, and I went on without a hitch.
For everyone complaining that someone could just drop in and ruin your server, no. Your 'server' runs as a local entity. Unless you set specifically that the port that you specify is open, and routed to minecraft, etc. Nobody can 'drop in' on your game.
So why not chill and wait for the actual final release?
Also: If jeb and mojang don't integrate the client and server software, then choosing a 'host server' button will never be able to happen.
And the pause feature will more than likely return when things are sorted out correctly. It'll take some time though, so chill.
Same with me.. Close your MC, Open it again and choose your world
I am having a lan party at my house next weekend.
Yes, people still use LAN.
Make sure you put the 'server' folder inside the zip file into your .minecraft folder, if you haven't, then it won't work.
That's what you get for not backing up, not to sound rude or anything, but snapshots are 100% in-development, you accept all risks and understand what it means to install a snapshot without taking proper precautions.
So you're just pissed off about a technicality that doesn't really affect you at all? Get over yourself.
Locate .minecraft/server then open server.propertities then change hardcore to true
Getting rid of SSP functionality in favor of SMP (with localhost support, i.e., you connect to yourself) would indeed solve the problems of two Minecraft versions (client/server) and allow for people to host games from inside the client to invite friends without setting up a server. In theory, it's a good idea, but In practice, it's really a bad idea given how things are already setup in Minecraft.
What I would like the point out, is that this is not the only solution to these problems, and it certainly isn't the best solution. There is another solution that I would like to bring to attention in case it has not been looked into yet. This solution would allow SSP to exist alongside SMP, without having two different sets of code to manage, all the while allowing new functionality to be added to accomplish the specific goal of allowing people to handle server creation and joining a lot easier without over complicating the existing code.
To put simply, you keep MinecraftServer.java package separate, Minecraft.java package separate, but merge everything else. In essence, you are creating a shared library of all the other game code, so there is just one version the server and client both use. What results is one JAR file that has both client and server functionality, while both being independent of each other. People who want to play SSP/SMP start the jar's client package to play Minecraft and people who want to host dedi-servers start the jar's server package to host the server. So to say again, rather than having a client jar and a server jar, you have a single jar that has both of them inside it as a result of how the project would be setup.
While that might sound hard, complex, or like it would cause a lot of problems, it actually is none of the above (at least, in my opinion and in my experiences so far). It's rather straight forward, solves the issue at hand quite nicely, and allows for a modding system to be integrate that supports both SSP and SMP at the same time using the same coding concepts Minecraft already employs. All of this is possible because of how the existing code is already setup.
When I say this is because of "how the existing code is already setup", I mean that the client stays authoritative in SSP and when the client is in SMP, it is not authoritative. That is how the code is currently setup, and as a result, it can be merged together without any (observable) side effects. For example, if you join a server and aren't OP, you can't just use OP commands (unless there are bugs in the server that allow this to be exploited.)
About a month ago, I made a post detailing this idea: [PoC] Merging the Minecraft codebase. In my thread, I detailed my experiences of merging not the client and server, but everything else to accomplish the ideal goals of having one set of code to work with for both the client and server. As a result, my solution allowed SSP and SMP to coexist like they do now, but without the extra overhead of two different projects.to update.
I decided to take things one step further and actually play with integrating ModLoader/MP. For any SSP mod that did not add code that would require server handling in SMP, the mod simply worked with minimal modification with SMP. For example, I was able to drop in Biosphere and be able to use it in SSP and SMP, because it only modifies world generation (my last video shows that in the thread). Since the server now has ModLoader support due to the merged codebase, it just worked. Likewise, with mods like SimpleOres or mods that modify crafting recipes, no real extra work was needed.
From a porting perspective, SSP mods that add new GUIs or interactions the server would have to handle, they would have to have SMP code added for each of those interactions much like how the client does it with EntityPlayerSP and EntityPlayerMP. It's not terribly hard to do, but it would take a bit of time depending on how much code there is to update to add this functionality. That is nothing special though, as if you typically want to code a mod, it's going to take some time and work, right?
Now, I know that Mojang is not going to use ModLoader/MP, but my experience using it myself has led me to the following conclusion: if the modding API is setup correctly, then people will only have to mod one way, and it will support SSP and SMP at the same time. The burden falls on Mojang rather than the modding developers to get things setup this way, unlike how it is now, since ML/MLMP are community contributions that are separate from each other.
After actually doing this stuff myself, it just makes total sense. I was able to do it in a timely fashion using only MCP and some custom tools I wrote. I am confident in saying that Mojang could do the same with official source a lot easier, faster, and more accurately than I could. I actually did play around with different problems that might arise, but I can't think of any. In the end, everything stays the same as it is now (pre-snapshot), except there's one set of code to work with rather than two, which is what Mojang really needs.
The only issues with my current implementation is that I use ModLoader and MLMP, which weren't designed to do all the things that are needed for a successful long term SSP/SMP modding API. However, this isn't a true issue because once again, Mojang isn't going to be using their modding APIs but rather their own.
By using this solution, everyone wins. People who want to play SSP can still play SSP as they do now (pre-snapshot). People who want to host dedi-SMP servers, can still host dedi-SMP servers as they do now. When client/server specific updates are made, they are made to the appropriate files only once, and the changes apply to SSP, SMP, or both SSP and SMP. For example, if Minecraft.java is updated, obviously nothing in SMP changes, likewise if anything in MinecraftServer.java changes, nothing in SSP is affected, but if a change is made to shared files, both SSP and SMP are updated since they use the same shared files (baring non/authoritative logic).
The real work comes in writing the perfect modding API that allows for both SSP and SMP mods to be made. Most things are pretty trivial when it comes to shared code that is the same for both SSP and SMP. For example, let's say you want to add an API to register new crafting recipes. Since that logic is the same for both client/server, that API is easy. For something like registering new GUI menus and interactions though, more work is needed to properly wrap the underlying code for SSP and SMP so the modder isn't thinking in terms of SSP or SMP, but rather just a Minecraft mod. These are the things that have to be though of anyways for any API though, so it's nothing unique to this solution.
Hopefully this idea will be considered. If anyone wants to talk about potential issues, feel free to use my thread rather than this snapshot thread, as to not get too off-topic. Based on what I'm seeing from this snapshot's feedback though so far, I feel Mojang could use some more ideas. I have spent a lot of time asking myself, "why shouldn't Mojang use this approach", and I honestly can't think of anything that is a deal breaker due to how the code is already setup.
1. You can no longer pause your worlds.
2. You can no longer play Minecraft without internet.
3. I am having trouble connecting to my own worlds.
4. Singleplayer now has a lot of bugs in it that are the reason that I don't play multiplayer much.
I really hope you remove this feature in the full 1.3 release, and I am pretty sure that lots of other people feel the same way.
So you just install development things on your machine without backing up anything? Smart.
I suppose you didn't see...
I take it back, I guess you didn't see the warning since you got it off of here? Someone please add that warning! But still.. developement version doesn't say something?
When you start a single player world it automatically starts the server. To allow others on the lan to connect, type your computer name (its kind of hard to explain getting your local IP) on the multiplayer section of others' computer
Cool story bro. Achievement Earned! "Learn a Lesson."
Haven't you learned to make backups before trying a development version. And if it was perfect it would be in the launcher.
Actually, I use MultiMC, perfect for this kind of stuff. I recommend it to everyone using the snapshot.
*Smh*