Implement a simple RCON commandline utility (in the Tools folder) that could be used to send and receive arbitrary data to / from the server using the RCON protocol.

This will allow us to set up some automated tests.

We changed most of the .ini files in the repo into .example.ini. Now it would make sense if the server read the .example.ini files instead of .ini files whenever the .ini file is missing. This behavior would be even beneficial for all .ini files, not only those used by the server.

How about we change the cIniFile to automatically read from .example.ini if the .ini file cannot be found? Of course, it would be nice to have the ability to switch off this redirection, if required. So:

bool cIniFile::ReadFile(bool a_AllowExampleRedirect = true);

Any comments?

This happens only in the PerWorldThreads branch.

When viewing the server in the serverlist in the 1.6.2 client, the client is unable to parse the server's playercount, displaying "???" instead.

The console seems to be spammed with messages each time an entity takes damage, for example:

Player on Fire: cPlayer was dealt dtOnFire damage: Raw 1, Final 1 (0 covered by armor)
Squid Attack: cSquid was dealt dtAttack damage: Raw 1, Final 1 (0 covered by armor)

I don't believe that this is expected behaviour? Or have I accidentally changed a config option somewhere?

At the moment, the files in the repository are varied in their line endings and also what type of indentation they use.

It would be good to agree on one standard and stick to it. I think it would be a good idea to use Unix line endings as that's the git best practice, but I have no idea about the tabs. Tabs or spaces, and how many spaces is a tab?

The client crashes when a plugin uses KickPlayer to kick a player, such as the Core /ban command. The console does not output any errors.

This also occurs with Player:GetClientHandle():Kick(Reason).

A piston is able to push or pull a water block. This creates interesting scenarios...

Tabcomplete works when you are pressing tab on the first word like so:

cheesed<tab>ummy10

but when you do it on the second or extra words it doesn't work:

/tp cheese<tab> ........

Unfortunately #14 breaks Player:SetGameMode(Split[2]). Console shows: Player setting invalid gamemode.

Additionaly, when a squid is on fire and taking damage, the conslole is spammed with cSquid on fire messages.

They should be knocked back, and TNT and sand should be nudged.

Add the packet handling for tab-completion packets.

LOGINFO, LOGWARN, LOGWARNING, and LOGERROR all do not colour text as expected.

My terminal definitely supports 256 colour mode, this, I tested.

A carpet does not correctly drop as an item if the carpet underneath it disappears or it is pushed by a piston onto air.

The code from cPlayer that implements drowning should be moved to cPawn, so that all mobs will take drowning damage (unless they are water-inhabitants)

Carpet blocks can be placed on other carpets.

If one moves oneself to a high place and jumps off, then upon gaining sufficient speed, attempts a teleport command which places oneself above a solid block, such as the /spawn command often does, one will find oneself dead due to the fall speed accumulated from fall previously killing oneself once one hits the ground.

As a summary (sorry about the complicated description): Fall speed isn't reset if you teleport mid-air. You can die by doing /spawn whilst falling.

I feel this is strictly speaking an enhancement - it's not part of vanilla functionality, but is somewhat widely accepted as to what a teleport command should do, at least in the Bukkit world.

Additional information: this only happens when you are falling and teleport to something below you, such as falling from the sky above spawn, then teleporting to spawn below.

Redstone devices such as pistons and repeaters are able to receive a signal (i.e extend/light up) but do not retract/go off when the power source is removed, UNLESS there is a redstone update nearby.

For example, a piston will not retract unless one places a second torch next to or diagonal to it; a line of repeaters will not correctly power off unless you place a torch next to them; redstone dust follows this.

Video (sorry for low quality, my upload speed is low):
https://copy.com/WHaaDWpEHXg0 (Removed)

If a player comes higher then Y255 the server wil crash without giving a crashdump with the error:
cChunk::UnboundedRelGetBlockType: requesting a block with a_RelY out of range: 256 Verification failed: a_Chunk.UnboundedRelGetBlockType(RelX, RelY, RelZ, BlockIn), file ..\source\Player.cpp, line 1333

A new player (one that does not have a player.json file) will spawn with half a heart of health. Hunger and saturation seem to be fine, however.

When the extended arm of a piston is broken, an uncollectable phantom stone block is dropped. The piston base stays intact.

Lava is supposed to burn! Not just be orange juice!

TNT can blow up water, and isn't pushed by it.

Quartz stairs are not classed as stairs according to the server, so they cannot be placed in different orientations.

As of commit cc708f7, the Core wouldn't load because the function HandleDownfallCommand is missing.

The new eating handlers are great, but browsing the code, I believe you've left some out:

Potato
Poisonous potato
Baked potato
Pumpkin pie
Enchanted golden apple
Carrot
Golden carrot
Cake (whole and sliced) - not sure, haven't tested.

One cannot place a block on top of a normal or redstone torch.

Currently the Lua API file, API.txt, is generated by the Debuggers plugin. It'd be better to have a separate plugin for this, both because the other functions in the Debuggers plugin are polluting the global namespace and people may want to keep the API writing, but not use any other Debuggers' functionality.

Pistons can be powered through their front face, so as to break their power source.

The webadmin and world each run in a different thread, and plugins may cause a deadlock if they try to manipulate a world as a direct response to a webadmin request. We need an article explaining this and perhaps an API extension to simplify workarounds.

Original title: Deadlock between webserver and world-tick over PluginCS / ChunkmapCS

Original content:
When requesting a world-save-all from the webadmin, it is possible for the server to become deadlocked. The webserver has acquired the PluginCS and wants ChunkMapCS (in cChunkMap::SaveAllChunks() ), while the tick thread has the ChunkMapCS and wants the PluginCS (in cPlayer::Tick() )

This was reproduced in a server with a single online player running on localhost; OS WinXP 32-bit

It only seems to exist in order to hold software licenses and example files. Should the contents be cleaned out and moved into the MCServer folder? (Side note - should that folder be called MCServer or renamed to something different?).

For example, armoured zombies sometimes drop their armour and plain zombies sometimes drop iron.

The project needs a README file to be presentable on GitHub

This would make it able to compile on macs, and also if people don't want to use gcc.

The main issue seems to be that Crypto++ does not support clang :(

The Apache license needs to be dropped into the code, so it's clear that the code is in fact apache licensed.

A piston is able to push an extended piston to create extremely bugged scenarios with detached arms everywhere.

We have quite a few places that each use lua_state *, and each implements its own helper functions, such as PushFunction or ReportErrors(), and its own memory management for the Lua state.

We should refactor this, make a cLuaState class that would wrap the lua_state * and have accessor functions for all the low-level work.

It's basically core, but with more features. I say we pull it in 😄

Everyone else agree?

To save RAM, the server should implement some form of sparsing or compression.

I think this is a very long-term goal, but it will be very worthwhile to implement.

The block action packet (0x36) is either not sent or not always sent to the client. 95% of the time, a piston extends or retracts without animation.

It seems QueueSetBlock doesn't tick the correct number of ticks.

We have most of the parts working (UI, enchantments, etc.), so it'd be a good time to actually implement the enchanting on the enchantment table.

If there's an error while loading the Core plugin, or the Core is not loaded at all, the server emits a misleading message, "unknown command, type 'help' for all commands" on an unknown command, but 'help' doesn't work.

As for the reload, there's no way to reload the Core plugin if there's an error in it, the server must be stopped and restarted.

Therefore, it would make sense to implement both of these console commands directly in the server, rather than in the Core.

The tabs as they are now are hard coded in the template. They are not added with the Plugin:AddWebTab() function.

When a sign is placed, no text editor is shown in the client and there's no way to edit the sign text.

TNT should explode on a redstone signal.

As reported in forum http://forum.mc-server.org/showthread.php?tid=1208&pid=9340#pid9340 , door state isn't saved. I believe this is because toggling the door won't mark the chunk as dirty, thus skipping saving.

Does anyone want MCS to automatically generate download it's configurations files like the vanilla server?

Currently, only a few options are automatically generated (a bit of Server, Gamemode, Authentication, and Rcon) and the code is scattered everywhere this will be a problem if the admin inadvertently deletes the included inis. Additionally, this will allow four file distributions (plugins, webadmin, server, readme), as well as increased resistance against errors produced by code not using example.inis (especially plugins).

Would it be good to put it all at the start, and does it go into root.cpp or something?

The virtual method hooks are not used anymore in the Lua API, remove them altogether

The Squirrel bindings are a failure, we should completely remove them to clean up the code.

A piston can be duplicated. Please see video: ~~https://copy.com/nH0h90by0RB2~~(Removed)
Details:
A sticky retracts, pulling a piston with it. The pulled piston contacts the redtorch at it's destination and expands, presumably before the server can delete the original block (of the pulled piston), and therefore is able to push it out of the area marked for deletion and therefore duplicating it.

Additional bugs occur due to a piston being able to push an extended piston.