larspensjo / ephenation-server Goto Github PK

If information is requested for a player that is no longer connect, a nil pointer reference may be used.

Instead of losing it, it should go back into the inventory. That way, it can be cached in for experience points.

When a player jumps, there is no test for a roof. That makes it possible to jump "above" the roof, and see what is behind. The algorithm for test falling down, however, can detect that the feet are on "solid gound", and prevent the player from coming back to start position again.

the client simulator will request the chunk for the coordinate of the player. But there is only one global coordinate saved for all instances, which will contain the coordinate of the last report from these instances.

When a chunk is requested from another instance, it may be too far away from the position of that player, and the request sometimes gets rejected by the server.

Lamps should be permeable, just like monsters, players and vegetation.

1. Every territory can grant one achievement.
2. Granted achievements are stored in the player data, as an array of id, where the id is the owner of the territory.
3. Any achievement can only be granted once to each player.
4. The mechanism to grant an achievement shall be handled by the activator blocks.

The client will now sometimes send an error message, as a string, with this command.
It shall be logged.

When jumping, the player falls back into the water to a depth that is not consistent. It may vary from time to time. That can make it hard to get out of water up to solid ground.

You can only climb up, using SPACE. When the top is reached, the player can fall down again.

Players and monsters are managed in quadtrees. But the world is 3D, so a full octree should be used. As it is currently, the quadtree is used to find players or monsters near each other, with an additional manual test for difference elevation.

There is no test if the monster is dead.

It is possible to create a magical portal that is not on the ground. A player will then fall down, making it impossible to travel to another portal.

The portal should be disabled if it is not on ground or if it is inside any material like traps or rock.

ephenation-server

Please help me

$ go install -v ./...
src/chunkdb/chunkdb.go:26:2: import "ephenationdb": cannot find package
src/chunkdb/chunkdb.go:30:2: import "mysql": cannot find package
src/cmd/clientsimulator/ListenForMessages.go:27:2: import "client_prot": cannot find package
src/cmd/server/worldDB.go:34:2: import "DynamicBuffer": cannot find package
src/cmd/server/createchunk.go:22:2: import "chunkdb": cannot find package
src/cmd/server/ObjectList.go:23:2: import "inventory": cannot find package
src/cmd/server/active_blocks.go:27:2: import "keys": cannot find package
src/cmd/server/doTest.go:33:2: import "license": cannot find package
src/cmd/server/active_blocks.go:30:2: import "quadtree": cannot find package
src/cmd/server/active_blocks.go:31:2: import "score": cannot find package
src/cmd/server/pheenadv.go:34:2: import "superchunk": cannot find package
src/cmd/server/procs.go:34:2: import "timerstats": cannot find package
src/cmd/server/pheenadv.go:36:2: import "traffic": cannot find package
src/cmd/server/active_blocks.go:35:2: import "twof": cannot find package

It would be used to improve the quality of equipment or items in the inventory.

The design of the inventory list too complex. A simpler system can be used where every object is defined by a 4 character string and has a level.

The client can request access to any chunk today. Requests too far from the player shall be denied.

The current SQL communication is based on an old library that is no longer supported. There is now better support with Go1, and a standard solution should be used.

It is now possible to create one magical portal per chunk. This would quickly lead to chaos if players use one portal for every chunk (which is the current limitation).

A more reasonable limitation would possibly be at most one portal per territory.

MongoDB is a nosql DB, which may be better suited than MySQL for Ephenation. This would use "labix.org/v2/mgo"

If there is a communication error, it may happen that the player is disconnected and not saved.

Use a fork from github.com/robfig/config as a tag.

The current version has changed path, and is no longer compatible.

When the player tries to move at an angle towards the wall, he will not move at all. The current algorithm extrapolates the "next position", and stops the movement if it is inside a wall.

Instead, the player should be moved in parallel to the wall.

In case of an incomplete message read from the client in combination of continuous read timeout, the server will busy wait until the connection is closed.
This will generate a lot of log messages.