21–30 of 95 posts
Hi guys, I'm the author of this. Going to sleep soon but happy to answer questions when I awake if you leave them here for me.
Hi guys, I'm the author of this. Going to sleep soon but happy to answer questions when I awake if you leave them here for me.
I used to be really active within the redstone scene back then. A lot of projects we made, such as computers, relied on the fact that we could made 1 tick busses by abusing a bug with pistons. Are things like that implemented in this project?
There is no support for redstone right now. When support is added, any machines that work on beta 1.7.3 and not on TrueCraft are considered bugs in TrueCraft.
This would be a major improvement to the multi-player experience.
Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks.
Those "fixes" will completely rid the game from "hackers". Witch is the biggest problem with Minecraft (and most other multi-player games).
Earlier quoted context omitted.
Take a loot at some open source projects. The Battle For Wesnoth (c++) has many more contributors than FreeCol (Java). I'm sure that number of C# developers in the world who develop open source stuff is even smaller. If your main goal is to get as many contributors as possible, perhaps JavaScript would be the best choice. And I'm still not convinced that Java is the main cause the original Minecraft was bad. Although…
Fair enough, though I didn't mean to imply those were the only good reasons. I didn't mean to say C++ would have been a bad choice, I was mocking the recurring mentality that a project is only good if it's in C (or even lower-level languages). It's quite tiresome to deal with it, I'm sorry it didn't quite get through. Java was definitely one of the reasons the original Minecraft was bad though. It (along with bad arc…
No. It wasn't Java.
The reasons are many, but here's some: All world logic happens in a single thread (fixed in Minecraft 1.8, now there's a thread per world). Entity lookups are very badly coded (mitigated, but not fixed by CoFHCore which explicitly excludes dropped items from the lookups). There are many bad coding decisions made throughout Minecraft (a nice amount of them is fixed by FastCraft, which optimizes Minecraft and reduces its RAM usage by ~300MB; OptiFine used to be good for the GPU but 1.7/1.8 integrated most of its fixes). Every neighboring block/tile entity access loads that neighboring chunk, then marks it as unused, then unloads it every 30 seconds (not a huge issue in MC itself unless you use a lot of pistons, but a massive issue for modded servers)
Etc, etc, etc. It is possible to scale Minecraft, however nowadays it is not possible to scale Minecraft without mods and at least a basic knowledge of how the engine works.
There was an experimental mod made by nallar in 2013 which dynamically ASM-patched Minecraft and every mod to make all world logic fully threaded in multiple worker threads, as well as a separate thread for chat; however, that was really hard to maintain in practice, especially as mods grew more and more complex.
A commonly used method is to run multiple instances of Minecraft servers and use a proxy glue server like BungeeCord to treat them as separate world on one server.
Should have been implemented in Java :/ > A completely clean-room implementation of Minecraft beta 1.7.3 (circa September 2011). > To get started, sign the Contributor License Agreement to establish that you have not, in fact, ever read decompiled Minecraft code. > 'Clean room design is the method of copying a design by reverse engineering and then recreating it' Not sure why it makes sense to say in the repo you rev…
Or: Should have been implemented in a language without garbage collection pauses?
I hope you make it so that only the surface blocks are sent to the client. The time it takes to "mine" a block is enough for the latency to send the block behind it. This would be a major improvement to the multi-player experience. Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks. Those "fixes" will completely rid the game from "hackers". Witch…
Orebfuscator or Spigot.
>Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks.
What? No. You can't make sure everyone moves the same way, and this would undoubtedly lead to desyncs. If you want to make sure players don't move too fast, use NoCheatPlus or what it was called.
A far bigger issue for servers is mods like Gammabright which make all blocks have a brightness of 15, thus not requiring you to use torches or light sources, as that's very hard to work around.
Earlier quoted context omitted.
You can still play old versions. You can use the launcher to create a profile that uses the old alpha or beta versions. http://www.howtogeek.com/203196/how-to-change-your-minecraft...
Though multiplayer on these versions is dead for the most part, for obvious reasons. The authentication-related stuff also is broken in most (old) versions, same goes with skins. These can be fixed through mods, though I'm not really sure if it's worth the effort. TrueCraft seems pretty interesting. I'm always a fan of open source games, and voxel games interest me a bit more than other types of games. MineTest had/h…
As a mod developer, my plan on revitalizing Minecraft and making it more of a sandbox again was always centered about designing a modpack going in that direction - I've been working on it since December.
I don't really feel splitting the community into twenty reimplementations is a good idea myself, though.
I hope you make it so that only the surface blocks are sent to the client. The time it takes to "mine" a block is enough for the latency to send the block behind it. This would be a major improvement to the multi-player experience. Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks. Those "fixes" will completely rid the game from "hackers". Witch…
>I hope you make it so that only the surface blocks are sent to the client. The time it takes to "mine" a block is enough for the latency to send the block behind it. Orebfuscator or Spigot. >Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks. What? No. You can't make sure everyone moves the same way, and this would undoubtedly lead to desyncs. If…
Spending a lot of time in the darkness? enjoy blindness, nausea effect and being on fire next time you venture topside while the sun is out.
Earlier quoted context omitted.
Fair enough, though I didn't mean to imply those were the only good reasons. I didn't mean to say C++ would have been a bad choice, I was mocking the recurring mentality that a project is only good if it's in C (or even lower-level languages). It's quite tiresome to deal with it, I'm sorry it didn't quite get through. Java was definitely one of the reasons the original Minecraft was bad though. It (along with bad arc…
>Java was definitely one of the reasons the original Minecraft was bad though. It (along with bad architecture) was the reason behind the massive server footprint and why hosting minecraft servers is extremely expensive and completely unscalable. No. It wasn't Java. The reasons are many, but here's some: All world logic happens in a single thread (fixed in Minecraft 1.8, now there's a thread per world). Entity lookup…
I'm well aware of all those efforts. I'm also well aware of the insanity behind them and just how much effort was required for it all. Java really didn't help the entire matter.