I don't want the option to disallow multiplayer on my single player worlds... I want the option to KEEP MY SINGLE PLAYER WORLDS, SINGLE PLAYER. I don't want to have to connect to a glitchy server to play single player, I like to be able to play even without an internet connection. It is NOT much hassle just to copy a single player world into a server folder if you want people to join. Who cares about lazy people, they're lazy...
yea, it's too early to tell but I do hope they optimize and bug hunt the server side more so. Experiencing mild block lag and general mp bugs in a single player world sucks. Even though the server side is hosted locally on your computer the server can still experience performance issues. The ones not complaining are the ones most likely that have high spec'd machines. I did notice a mild fps increase and some chunk loading increase, but also have experienced some block lag at times and half rendered npc villages.
One unified code base is a good thing, but experiencing things that happen in SMP in a SSP world is a turn off.
The Meaning of Life, the Universe, and Everything.
Join Date:
9/23/2011
Posts:
45
Member Details
I think it's great that they're merging SSP with SMP because not only is it what the games on steam's source engine does, but it's also a great solution to the fact that every update has different bugs for singleplayer and multiplayer.
For Everyone out there.. Back-up your .minecraft/ Make a duplicate of your .minecraft folder..
Do this every time when you are about to install a Snapshot/Mod
It is not Mojang's fault your Worlds are messed up..
I like the Server in SP thingy..
But one Question. How can others join my SP World?
So, its says on the minecraft wiki that theres hardcore mode in SMP, does that mean that when all the people on the server die, the map gets deleted or what?
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.
Rollback Post to RevisionRollBack
The optimist thinks the glass is half full,the pessimist thinks the glass is half empty,
and the engineer thinks the glass is twice the size it needs to be.
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.
yea, it's too early to tell but I do hope they optimize and bug hunt the server side more so. Experiencing mild block lag and general mp bugs in a single player world sucks. Even though the server side is hosted locally on your computer the server can still experience performance issues. The ones not complaining are the ones most likely that have high spec'd machines. I did notice a mild fps increase and some chunk loading increase, but also have experienced some block lag at times and half rendered npc villages.
One unified code base is a good thing, but experiencing things that happen in SMP in a SSP world is a turn off.
Only time will tell...
1.When you pause (ESC MENU), the game still goes on like the server.
2.Falling damage effect boots only.
Also fix the sounds!
Do this every time when you are about to install a Snapshot/Mod
It is not Mojang's fault your Worlds are messed up..
I like the Server in SP thingy..
But one Question. How can others join my SP World?
Yep.
actually no when any one person dies they get automatically banned
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumStep 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.
http://www.noobcraft.info
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.
and the engineer thinks the glass is twice the size it needs to be.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMake sure you put the 'server' folder inside the zip file into your .minecraft folder, if you haven't, then it won't work.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat'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.