Messages

31

Development / Re: Callback System

« on: February 19, 2011, 05:54:41 pm »

A simple fast question: is any code (plugin or base server) allowed to cache values from calls to getHook()? I think some frequently called hooks may benefit from such a thing - use a pre-stored value rather than do a string search every time the hook is about to be called - may increase performance.

32

Support / Re: How to report bugs?

« on: February 18, 2011, 11:20:52 pm »

On the top right corner of this page is a link Bugs

[rant]As if those were ever read [/rant]

33

Development / Re: Different compilation results? (Win)

« on: February 17, 2011, 09:51:29 am »

You can still use the do_build file if you're on Windows.

For building, yes, but not for debugging. That's the point - if one wants to debug the application, they need a proper VS project file. Then access violations can be pinpointed down to the source code line that causes them - it was so easy to find those two AVs I've reported that I've been wondering, how come noone else noticed earlier.

34

Plugins / Re: The new Plugin API

« on: February 16, 2011, 11:04:49 am »

@Gutter: nice idea, but this needs a bit more thought before actually implementing this, so that it can be done nicely:

I suggest each world gets a "style" assigned to it in the config file. Then the server triggers a "chunk needed" message whenever a new chunk needs to be generated; plugins check the "style" attribute of the world and if they handle that style, they generate the chunk; otherwise they ignore the message. If no plugin handles the message, a default generator generates the chunk.

This way we could implement other generators as plugins and they would be completely configurable as to which world, if any, they generate.
-> Nether generator
-> Heaven generator
-> Flat world generator
-> Cave-only world generator
All of these could be used for separate worlds, with warps between them.

35

Development / Re: Different compilation results? (Win)

« on: February 16, 2011, 10:58:38 am »

The console output is easy to explain.

Thanks for the pointer.

I guess the config file should get some documentationist's love, it's getting crowded with options that noone really knows about.

Both binaries are from Fador's github source. Fador uses a do_build.bat file, ...

I'm using VS2008 Express, so i can't use that bat file. I instead refreshed the VS2008 project files present in github and use those.

The access violations are already surfaced over IRC and are known. In fact, I get the issue whenever everyone disconnects or if I use Ctrl+C (or the X button on the window). Please provide other info to the proper people (even here) so they can fix it asap. The problem is being looked into already.

I've already filed two of those into the bug tracker, *including* a fix for them. It was a rather easy solution, actually. So where am I supposed to put those else? It says in the forum guidelines to post reports to the bug tracker.

See the issues here:
http://redmine.fknsrs.biz/issues/64
http://redmine.fknsrs.biz/issues/66

Hope this helps.

36

Support / Re: Mobs on mineserver

« on: February 12, 2011, 09:33:55 pm »

How come there are pigs in mineserver.be:25565 test server, then? I thought crapmobs only did giants (and I didn't see any even after enabling it in my server)

37

Development / Re: Callback System

« on: February 10, 2011, 10:36:17 pm »

I think the various hooks should be typedeffed, or even wrapped in a #define or a specific function, so that one can write:

Code: [Select]

PlayerCharPostHook(user->nick.c_str(), rawTime, msg.c_str());
or at least

Code: [Select]

(PlayerCharPostHookType(Mineserver::get()->plugin()->getHook("PlayerChatPost")))->doAll(user->nick.c_str(), rawTime, msg.c_str());
instead of

Code: [Select]

(static_cast<Hook3<bool,const char*,time_t,const char*>*>(Mineserver::get()->plugin()->getHook("PlayerChatPost")))->doAll(user->nick.c_str(), rawTime, msg.c_str());


38

Development / Different compilation results? (Win)

« on: February 10, 2011, 10:30:11 pm »

I was wondering, why am I getting such a different result between when compiling from sources and the official binary release for Windows.

I compile the sources at GitHub/Fador using MSVC2008 (had to re-create the MSVC2008 project, the one present in the sourceball is defunct); my executable is 50% smaller than the official and it DOES write things into the console while running, UNLIKE the official one (which only says "world world" and nothing else.

Are the official binaries from those sources at all, or does other stuff get thrown in?

Also both my compiled version and the official binary hit access violations rather often, I keep reporting them to the bug tracker, I was wondering if I am the only one seeing those? 'Cause noone else seems to care at all, and those are some serious issues that would HAVE to surface in other OS variants as well...

Just rambling...

39

Development / Re: Moron help ;)

« on: February 08, 2011, 02:38:07 pm »

You can also fork your own mineserver on github, then ask for a pull request when you've "finished" what you wanted to change.

That's exatly the point I hate about git, and I believe it is the killer of open-source projects: forking. "You don't like it? Fork it" It means that there are thousands of forks of good ideas and none of the forks really work.

If you are familiar with SVN (especially when it comes to GUIs) you might want to have a look at TortoiseGIT: http://code.google.com/p/tortoisegit/

It's much like TortoiseSVN, in case you've ever used that one.

Last time I tried TortoiseGit (and even before that) it didn't work at all. And their broken-English error messages were too cryptic even for me to guess their meaning.

msysGit seems to have done at least something, now I have the source, but working with it will require a lot of learning, still.

Simple Howto book:
http://progit.org/book/

Thanks, that's what I was looking for all that time and couldn't find. I guess I could give it a  hack and a whack now

40

Development / Moron help ;)

« on: February 06, 2011, 07:11:16 pm »

Hi there, fellow Java-haters ;)
I'd like to offer my help with the project. I'm a C+ programmer (C+ = C with just enough C++ to not compile in C ;) specializing in Windows development, raw WinAPI etc.

However, I'm too much of a moron to actually learn to use Git (there's no simple "how to use" book, no simple GUI windows app...) and I severely dislike other-than-mine code style.

If you still think you could use my help, count me in :)

For starters, I was thinking of something along the lines of a windows GUI for the server, showing some stats in a window, like the original server does. This could be implemented as a plugin, so not much of me intervening in the intestines of MineServer codebase. I could then send the sources to someone in charge, if appropriate.

At least that could lead to the plugin API being ironed out a bit.

41

Development / Plugin API vulnerabilities

« on: February 06, 2011, 06:46:22 pm »

After a quick browse through the plugin API, I think I see a big potential for segfaults in plugins.

The Map functions:

Code: [Select]

  unsigned char* (*getMapData_block)(int x, int z);
  unsigned char* (*getMapData_meta) (int x, int z);
  unsigned char* (*getMapData_skylight)  (int x, int z);
  unsigned char* (*getMapData_blocklight)(int x, int z);
seem to return pointers into the living data structures. Now suppose the plugin stores such a pointer and accesses it at a later time. But MineServer may have already released those chunks! BANG

Options:
  1, Leave it as-is, no plugin ever will be so stupid (the ostrich approach)
  2, Remove the routines altogether, replace with a single-block getter / setter function (will make some "terraforming" plugins painfully slow)
  3, Upon call of these routines, increment a "lock" on the chunk; provide a lock-decrement function for the plugins to call when the chunks is no longer needed; don't release the chunk until it has a nonzero lock count (can cause memory starvation if plugins hold too many locks)
  4,

42

Discussion / Re: Mineserver Runs On... (post your specs)

« on: February 06, 2011, 06:06:36 pm »

Runs on:
  * Intel Core2 Duo T9300
  * 2GiB DualChannel RAM
  * nVidia GeForce 8400M G
  * Windows XP 32-bit

But I guess it would run on almost anything that could run WinXP anyway