Messages

1

Discussion / Re: What does Mineserver need to get off the ground quickly?

« on: April 01, 2011, 09:02:24 am »

Hi there,
in my opinion, Mineserver currently has quite a lot of developers, but no project leader. This results in "every feature is worked on by *someone*, but no-one really knows who, when, how...; every feature is in its own git repository and altogether the place is a mess"
As far as I know, there's no suggested path, other than looking at the wiki which has a <sarcasm> really great page on roadmap </sarcasm>.
The question is, are you good enough to even make Mineserver compile? ;)

Alright, don't read this post, I'm in a terrible mood today and I'm really bitter :P

2

Support / Re: Error at end of build. (Visual Studio 2010 build pack)

« on: March 18, 2011, 10:52:37 am »

This seems to be a somewhat new error, I haven't run into that before.
The code is weird around that place, the comments say it all

As long as there are no build errors, you are all set. Still, before running the server, make sure the config.cfg and related files are in the same folder as the executable (copy them from /files if needed; the executable should be in /bin/Debug or /bin/Release)
PACKAGE and INSTALL are virtual targets used by CMake, you don't need to worry about those.

3

Support / Re: Error at end of build. (Visual Studio 2010 build pack)

« on: March 18, 2011, 10:16:05 am »

Sorry, I'm not on irc

For mineserver sources in c:\mineserver, set to the following:

Code: [Select]

NOISE_LIBRARY="c:\mineserver/lib/libnoise.lib"
NOISE_INCLUDE_DIR="include"
EVENT_LIBRARY="c:\mineserver/lib/libevent.lib"
EVENT_INCLUDE_DIR="include"
ZLIB_LIBRARY="c:\mineserver/lib/zlibwapi.lib"
ZLIB_INCLUDE="include"


4

Development / Re: Plugin API vulnerabilities

« on: March 18, 2011, 09:55:49 am »

When a discussion over plugin API goes down the drain into a discussion of trolling and encyclopedia-citing, I'd call everyone involved a troll.

Please stop this madnes.

Please delete all the posts not on topic.

5

Discussion / Re: What does Mineserver need to get off the ground quickly?

« on: March 18, 2011, 09:53:39 am »

[flame]
I think that Mineserver needs, most of all, some experienced C++ coders to look at it, frown and redesign it from the ground up

Other than that, it mainly needs to get the devs off of irc and start actually developing, taking care of the bugtracker (which one of the many?)
[/flame]

6

Support / Re: Error at end of build. (Visual Studio 2010 build pack)

« on: March 18, 2011, 09:50:53 am »

Hi,
with CMake You need a little bit more patience, since it is not yet finished for the MSVC builds and probably needs a bit more tweaking.

First of all, you do need the MSVC build pack. Extract its contents to the root folder of where you put mineserver sources (so that you have the /src, /plugins, /files from Git together with /include and /lib from the build pack)

Then you need to run CMake, point it to the source dir and hit Configure. It will work for a while and then list a few values in red and finish with the error messages complaining about dependencies.
In the red values, look for ZLIB_INCLUDE_DIR, ZLIB_LIBRARY, EVENT_INCLUDE_DIR, EVENT_LIBRARY, NOISE_INCLUDE_DIR and NOISE_LIBRARY. You need to rewrite those to point to the msvc build pack's include directories (*_INCULDE_DIR) and the specific *.lib files (*_LIBRARY)

Then hit Configure again, this time you shouldn't see more errors in the progress window, just one warning about missing curses (that's okay). Now you can click Generate and the project files and the solution file are generated for you.

Open those and compile with MSVC.

You might run into compiler error complaining about missing stdint.h.
If so, edit the main CMakeLists.txt and insert this line after IF (MSVC_IDE):

Code: [Select]

include_directories(${PROJECT_SOURCE_DIR}/include)

Generate again in CMake and recompile in MSVC. If there's any more problems, post them here and I'll try to help as best as I can

7

Discussion / Re: no .com unless someone wins lotto

« on: March 15, 2011, 01:03:14 pm »

mineserver.ms finally got set up, the best I could do was a HTML redirect to mineserver.be

8

Support / Re: Error at end of build. (Visual Studio 2010 build pack)

« on: March 15, 2011, 10:20:22 am »

Alright, try modifying the $/plugins/CMakeLists.txt file around the line 94 like this:

Code: [Select]

#
# install
#
install(TARGETS ${TARGETS}
  DESTINATION ${CONFIG_DIR_LIB}/
)

Then use CMake again.

This seems to be required for windows builds.

9

Support / Re: Error at end of build. (Visual Studio 2010 build pack)

« on: March 14, 2011, 10:39:49 pm »

Could you try installing CMake (www.cmake.org), pointing it to the sources, letting it generate the VS project and compiling those? That will be the preferred compilation path in the future, it should already give better results than the BAT script in the VS2010 buildpack.

10

Development / Re: Plugin API vulnerabilities

« on: March 14, 2011, 04:02:38 pm »

Threads are used to an advantage whenever there are two or more tasks that are very losely coupled (that is, they interact minimally or not at all, either via messages, shared data or otherwise)

Redstone circuits and tracks (and world physics, maybe) are ideal candidates - they each run calculations that are independent of each other. Therefore putting them to separate threads would mean negligible harm on single-core processors and a huge gain on multicore and multithread machines (which, don't forget, are dominant in the consumer electronics today)

However, we're straying more and more away from the subject - API replacement.

Tell me one single reason why the old API should stay and the new API should not be implemented. Oh, and "already written" is not a reason

11

Development / Unified plugin entrypoint name

« on: March 14, 2011, 01:17:11 pm »

I was wondering, why do plugins export their entrypoint based on the plugins name? Why can't we have a single well-defined name for a plugin entrypoint, such as mineserver_plugin_init() and mineserver_plugin_shutdown() instead of <pluginname>_init and <pluginname>_shutdown() ?

The only theoretical reason why current state is better that I can think of is multiple "modules" in a single executable. However, this makes very little sense and is a very little benefit compared to the amount of work required to make the current state work.

12

Development / Re: Unified building

« on: March 14, 2011, 01:12:17 pm »

ad includes:
For linux, single include / lib dir makes sense, because noone really uses any other compiler than gcc.
For windows, where there's thousands of compilers, each binary-incompatible with the others, such a "repository" is a no-go, libs from one compiler cannot be used by the other, so it's actually better to make libraries project-local.
Not to mention versioning, which is zeroish for windows.

13

Development / Re: Plugin API vulnerabilities

« on: March 14, 2011, 01:08:48 pm »

I think some of the more advanced features, such as minecart tracks or redmine circuitry would very much benefit from the ability to run in separate threads. If for no other reason, then because they might be in for a lot of work if the track / circuit is too large, and not be able to process data fast enough to keep even with the 200ms timer.

And if one thing goes MT, then the whole must go MT, otherwise the mess is unbearable.

Just imagine the lag if you wanted to place a block and it took ~0.5 sec just because the server is very busy calculating your circuit.

MT should be always considered, from the beginning, because if not, then converting ST into MT will be a pain in the *** when one day it is actually needed. If nowhere else, then the interfaces (that are expected to get stable) need to be MT-compatible, if nothing else.

I think my last offer for interface is fully in line with that - it can be made MT-safe very easily if needed, yet it doesn't add any cost for ST. And in fact it provides great benefits, since consumers of that interface won't have to worry about chunks, internal data storage, swapping etc. That's clean interface design.

14

Development / Re: Cross-compiling for Popcorn Hour

« on: March 14, 2011, 01:00:02 pm »

that SMP863x is unknown arch/device/whatever to me...

Basically, Popcorn Hour is just a media player box (see http://reviews.productwiki.com/popcorn-hour-a-110/ ), internally it runs some kind of mutilated linux and the community provides some nice apps, such as svn server, http server etc.

So no, I don't think mingw would be of any use in this case.

15

Development / Re: Unified building

« on: March 11, 2011, 07:32:32 pm »

Okay, we're almost there, but not yet

The include dir needs to be set for individual plugins as well - some of them use stdint.h, which is not in MSVC, so we need to point the compiler into the build pack

Also, $mineserver_depends CMake var doesn't seem to do anything with regards to input libraries for the linker - adding ws2_32 and winmm into the var doesn't include them for linking in the VS project file. We really need to do a

Code: [Select]

link_libraries(ws2_32.lib winmm.lib)
for Win32 platform