huin / chunkymonkey Goto Github PK
View Code? Open in Web Editor NEWThis project forked from stefanha/chunkymonkey
(unmaintained) Minecraft Beta multiplayer server
License: MIT License
This project forked from stefanha/chunkymonkey
(unmaintained) Minecraft Beta multiplayer server
License: MIT License
Implement a recipe system that can be defined by an external data file.
(this is more like a note to self)
I didn't actually test this, but unless this is handled client-side we are probably destroying all items from chunks as soon as they are unsubscribed. I didn't confirm but I believe we unsubscribe right after a player moves away from that chunk.
The desired behavior is that dropped items remain spawned for at least 5 minutes, so the player is able to recover them.
Player state currently includes:
Later on it will include health, being on fire, etc.
This must be made compatible with how the Notchian SMP server does its storage.
Block interaction currently only allows for block placement. This needs to be extended to allow for 3x3 crafting, furnace operation and other special block interactions.
Since we don't have a mailing list (not saying we need one) I'd like to discuss here a few style changes:
Release 57 brings in channel-read time checking for if a channel is closed. The current use of channels should be checked to see if there are places where this could benefit the codebase.
This might need inventory management completed first.
This isn't important for the core server, but potentially useful for anyone using the chunkymonkey/proto package for a client.
Probably worth working on the recipe stuff first, as this might use some of the same concepts/code.
In order to be able to increase unit test coverage, a mocking library is required. GoMock ( https://code.google.com/p/gomock/ - not to be confused with the package of the same name that I [huin] wrote) should be fit for this purpose. It is hoped that GoMock will compile against the latest stable "release" tags of the official Go toolchain.
Please add comments to this issue if there are any concerns about this choice.
Item position, velocity etc. needs to be simulated server-side. For now it should be enough to simply simulate simple friction and gravity. Water movement effects can wait.
The record and playback package is a useful tool, but is currently used only in the server code, which also restricts its usefulness. It would be useful to place the recorder into a proxy relay (perhaps the intercept program, selected by command line flag), and playback into yet another program.
This could aid some automated/repetitive testing of the server, and allow for more flexible testing of client interactions.
My proposal:
src/chunkymonkey:
*block
*chunk
*chunkstore
*inventory
*itemtype
*mob
*nbt
*player
*recipe
entity.go
game.go
gamerules.go
interfaces.go
item.go
physics.go
physics_test.go
proto.go
proto_test.go
record.go
server_auth.go
slot.go
slot_test.go
types.go
types_test.go
worldstore.go
src/main:
chunkymonkey.go
src/util:
*datatests
*dumpblockdefs
*inspectlevel
*intercept
You can see a preview here:
https://github.com/nictuku/chunkymonkey/tree/directories-fix
I think this looks much better. Are you folks OK with this layout? Then I'll spend more time on this. Just FYI there are two problems with my current change:
for some reason godag is only being able to compile the whole tree, not individual pieces.
gd # works
gd src # works
gd src/chunkymonkey # does not work, even if I see various -L and -I parameters
before running tests (gd -t) I always have to do gd -c.
gd -c ; gd -t ; works
gd -c ; gd ; gd -t # does not work
I'll contact godag folks about this later.
Only basic definitions for now, no need to add any specialised logic for them.
When blocks are added or removed, the lighting needs to be updated.
This might need basic inventory management completed first.
This design work should naturally happen before anything else in this milestone (even if not in detail). Work on this should help make clear how the multiple servers architecture will look.
This includes mobs, items, inventory contents etc.
At the very least a seed value should be read from configuration.
I'd like to add basic mobs support - that is, have the ability to spawn mobs, but initially without any strong AI, which of course we should also add later.
If anybody else wants to work on this, please contact me via github so we can sync up and avoid duplicating work.
The current design makes use of both synchronous locking mechanisms, and also passing functions via channels. This could likely stand some improvement. I don't have clear ideas about what shape it should take, but I'd like to foster some discussion about how to:
Go should provide some very good concurrency patterns that can be utilized, but I feel that it's being used in a very cludgy way.
When two players use the same workbench at the same time, they should see the items in the workbench crafting area that the other has placed, and be able to take items (both crafted and input).
This bug overlaps somewhat with the workbench not dropping items when the window is closed. The items should drop when the last player closes the window.
fmt.Errorf doesn't do what the code thinks it does. See http://golang.org/pkg/fmt/#Errorf
$ grep -nr fmt.Errorf src/
src/inspectlevel/inspectlevel.go:70: fmt.Errorf("Error loading world: %s\n", err)
src/inspectlevel/inspectlevel.go:79: fmt.Errorf("Error loading chunk: %s\n", err)
Clients can be crashed if sent malformed color codes or over-long messages via chat. This should be prevented.
Items should be ejected from the workbench inventory into the chunk when no players have a connected crafting window open.
To reproduce:
Expected:
This might be a simple case of making the torch non-attachable (if it isn't already), but there seems to be some quirks around how the placed block acts after being placed when it is subsequently dug. The client acts as if the server has told it that the block has been placed, but upon digging, the server acts as if it has not.
For value in doing this, it's specifically important to move physics into the chunk layer. Chunks will need to receive "tick" messages from the game loop.
Chunk access to data that changes will have to be isolated to be thread-safe. For this reason things like physics that need to access the changeable chunk data need to be run inside the chunk goroutine. Small messages from players digging etc. can happily be sent to the chunk goroutine for action.
The eventual aim is to have the current game loop serve as:
for the chunk loop to serve:
Interactions between the game loop, chunks and players should be kept to smallish async messages as much as possible - avoiding cases where a goroutine should block for a reply.
The notchian client doesn't send a "finished digging" packet for these block types. They should be destroyed on first hit.
I've made a change in my fork that removes the dependency on the 'godag' program for building chunkymonkey. Instead we will be using gb, which has the advantage that it can produce scripts and Makefiles that allow anyone to build the software without installing additional software.
The structure is a bit more stringent, with everything that is a package under pkg and everything that produces a command under cmd. This also makes it a bit more obvious when looking at the source where in the package hierarchy something lies. I've included a script that will update the build scripts.
Basic usage (all commands run in src)
# clean everything
gb -c
# clean then build
gb -cb
# build only pkg
gb -Pb
# build only cmd
gb -Cb
The scripts included work as well without using gb:
# clean everything
./build.sh clean
# build everything
./build.sh
# build only pkg
./build-pkg.sh
# build only cmd
./build-cmd.sh
Take a look at master on my fork and see what you think. I think its an improvement, hopefully I'm not the only one. Don't bother trying to pull, just let me know and I'll push it to the main repository if its okay.
The master Makefile at the root needs to be updated or removed, it likely will not work any longer but I wasn't sure where we wanted those targets to end up.
In a notchian server, pressing Q with a item in hand results in the item being dropped - or more properly, thrown.
This currently doesn't work in chunkymonkey.
Minecraft presents several views onto "inventories" via windows that combine several inventories together.
Put player data like inventory into the shard (allowing for atomic inventory transactions)
The chunk module addresses blocks in multiple ways (BlockXyz, ChunkXz+SubChunkXyz, index, shift), depending on context. These get passed as separate parameters a lot, and should be consolidated (including when passed to block aspects).
At some point chunkymonkey needs modding capabilities.
I write this down to consider this in the issue #30 about concurrency design.
I am just writing down some ideas and information.
Here is a list of possible language bindings for Go;
https://bitbucket.org/rj/golang-javascriptcore/ - This is a wrapper for WebKit's javascript engine for Go
http://github.com/afitz/golua - Go wrapper for LUA's C API cgo
https://bitbucket.org/binet/go-python - go bindings for CPython C-API lib
Pure Go can only be supported if the end-user compiles Go and chunkymonkey by himself.
This way he could patch the source code.
Another idea is to have modules which run independent from chunkymonkey and communicate over network with chunkymonkey. With this idea all languages are supported if they have network support. The downside is probably execution speed.
The plan is to run one master goroutine per "shard" of chunks.
Implement all recipes in Beta 1.5 (or at least, those known on the wiki).
The minecraft community needs a way to bring a notchian server down for maintenance.
While it doesn't make sense currently to bring chunkymonkey down for maintenance (no permanent storage), it might be useful for admins of notchian servers to run a chunkymonkey server on the same port, so that users are kicked with a helpful message when they try to login to the server.
Initially, a command line flag would be sufficient.
Putting a live server under maintenance without a restart would be a bit trickier, but doable. That's much lower priority though, at least until we have a commands system.
I have a candidate change for this already.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.