FOSS gamedev and creative worlds

Hi to all developers. I started developing few features, but I have by chance found, what various developers developing its too.

I propose create list - "who does what?" and write what u do, to avoid duplicate work. Now maybe write it here, but need place for that or in wiki (if celeron55 approved).

Of course, also this list can be used for team working at any features.

Hey Longer.

It is true, there's a lot of forks out there, I guess because people have different ideas about what they want.

Depending on how good you are with C++, reading and understanding the minetest engine I'll add you as developer to my repos.

http://bitbucket.org/spongie/

Current changes include:
- Arbitrary player inventory sizes (currently hardcoded)
- Optional, alternative, dual wield controls
- Slightly updated UI
- Screenshot
- Simple direction working (for chests and furnaces)
- Some minor bugfixes.

Upcoming changes:
- Decaying leaves
- Growing trees
- Animated tiles (i.e map object faces)
- Animated UI
- 3D models for some of the map objects
- Whatever my test players put in my issue tracker :)

My aproach is simple: I want my client to remain comaptible with the original servers. That is, you should be able to play the original celeron55 servers using my client, although my server + my client will add some new features currently not available in the upstream repos.

What gets added? Anything that is a good feature that doesn't break the celeron55 compatibility, basically.
I have a few very kind test players who test botht he client and server (thanks, by the way), they feed me new feature ideas constantly.

Somehow I managed to screw up the fork thingy on bitbucket, but the idea is to not change the API too much so I can merge upstream patches with my fork. Hopefully these changes are subtle and popular enough to do the opposite, i.e merge my commits into celeron's upstream.

Celeron has not responded regarding this, it's understandable. You get exhausted writing all the boring crap that goes into an engine, we're joining late at the fun part now.

My fork - https://bitbucket.org/LongerDev/minetest

Current changes:
- add texture cube (inventory) to sand, tree, wood and mese (sand count read is better and standart view on all elements is true)
- add backround to info text (this title visivbled on hover cursor on chest, sign etc)

Also I have branch - add_sound, now frozen, so as I finded in other fork it feature (not finished too, but progress is better)

Now in my TODO:
- add title with name of element on hover cursor on elements in inventory
- drag and drop elements in inventory
- change tourch model on 3d

My fork - https://github.com/Bahamada/minetest-delta

Current changes:
- hughe refactoring (master - branch)
- working sound (OpenAL) (Audio - branch)
- TNT (not working) (TNT - Branch)

Nice merge work at your fork, bahamada!

I propose create list - "who does what?" and write what u do, to avoid duplicate work. Now maybe write it here, but need place for that or in wiki (if celeron55 approved).

This might be a good idea, I haven't been able to keep up even myself. So:
http://celeron.55.lt/~celeron55/minetest/wiki/doku.php?id=forks

Celeron has not responded regarding this, it's understandable. You get exhausted writing all the boring crap that goes into an engine, we're joining late at the fun part now.

I am totally overwhelmed by the huge amount of forks everywhere and really am currently not able to organize this. If I'd start looking through every fork out there, it'd take all of my time.

The best way to get your code into vanilla Minetest is to first ask me if I would like to have that or those features/fixes and then send me a patch (or multiple patches for multiple features/fixes) against the vanilla codebase by when your feature/fix is ready.

The smaller the patch, the better. It will save everyone's time and frustration. And be ready to fine-tune your patch if I so request.

I also might want to eg. quickly modify the framework to better accomodate your kind of an addition before merging the addition.

What I do require from patches is that the coding style is kept similar to what is already used in the codebase. Quite like ANSI, but not exactly (at least formatting of comments differs, and "if(" instead of "if (").

I must once again stress that unlike until two months ago, I am currently working 8 hours a day in a company as a programmer and it takes most of my energy. This will last until the end of July.

I hope all of this makes sense.

I propose create list - "who does what?" and write what u do, to avoid duplicate work. Now maybe write it here, but need place for that or in wiki (if celeron55 approved).

Hmm, actually, the fork list approach isn't the best one for generically organizing this. A page that is organized not on a per-fork basis but on a per-feature basis is needed, making personal attempts and forks equally valued. (well, mostly they are the same thing, but a fork is often considered being more large-scale.)

I'll go and create something like this instead. 8)

I created these pages:
http://celeron.55.lt/~celeron55/minetest/wiki/doku.php?id=contrib
http://celeron.55.lt/~celeron55/minetest/wiki/doku.php?id=whodoeswhat

I also thought about using the bitbucket issue tracker for this purpose, but I think it doesn't fit that well for managing things that people are doing completely outside of the particular repository.

I will now take contributions as patches against vanilla Minetest-c55. That way I will be able to handle a reasonable amount of them with a reasonable amount of headache.

bahamada: I am interested in including your addition of OpenAL support, can you provide a clean patch for it?

And to everyone else, too: I would like to at least have all your bugfixes as patches or some kind of descriptions.

I won't be asking people to send their code to me, because I don't have the time to keep track of every small thing everyone is doing.

So just contact me once you know other people approve what you've done. I won't kill you. Most of the time. 8)

Well, Bahamada's fork is very interesting!

But I would suggest to use OGG/FLAC files instead WAV files because they are too heavy... Is it possible?
Also, the Audio class doesn't work, m_ListenerPos/Vel/Ori seem to cause some errors at the class constructor part. I don't know how to fix this.

cisoun wrote:But I would suggest to use OGG/FLAC files instead

it's possible and easy.

cisoun wrote:Also, the Audio class doesn't work, m_ListenerPos/Vel/Ori seem to cause some errors at the class constructor part. I don't know how to fix this.

Give errors log here or him.

celeron55 wrote:I also might want to eg. quickly modify the framework to better accomodate your kind of an addition before merging the addition.

I was expecting this which is why I've set my additions to be as non-intrusive as possible. I will make another fork (doh!) that is completely 100% according to your specs and only add the popular by demand features that do not affect backwards compatibility with serialization. I'll use my own repos as an experimental "trying out some crazy shit" repos.

When it comes to the framework, it is unfortunately lacking as it is. I see that you like C (as me), but it's not an efficient API strategy for C++ in the long run.
I see a lot of potential refactoring of static data and C-style object handling that could be rewritten as a clean C++ object oriented API with the use of completely dynamic data and all the fancy OO stuff.

What I'd like to do is help you (in any way shape or form you want) to refactor your vanilla engine to a very moddable C++ API. I don't see any point in adding massive changes to the current API if it's about to change.

I think step one would be for you to decide how you will make a better C++ API for the game-related objects, in particular since the comments in code say mapblockobjects are deprecated(?). Maybe start by writing a wiki page "this is how I would like the API to look" with pseudocode examples or just prototypes and we can add comments to it until you say "yep, this is it, let's do it!" and I'll help you implement best I can.

Good luck to everyone and thanks again to celeron for his inspiring efforts!

@cisoun: that could be a problem with the static initalizer list... I get warnings from that, but currently I dunno whats the "right" way to initalize the array. But this should be a smaller issue...
(Edit: Warning detail: extended initializer lists only available with -std=c++0x or -std=gnu++0x)

@spongie: You could look into my master... I did much refactoring and also encapuslated stuff in classes etc...

celeron55 wrote:bahamada: I am interested in including your addition of OpenAL support, can you provide a clean patch for it?

Yes this should be no Problem...

Edit: https://bitbucket.org/celeron55/minetest/pull-request/2/audio-subsystem

See issue #19 http://bitbucket.org/celeron55/minetest/issue/19/new-input-controls.

I will make a test implementation as a suggestion and we'll see where it goes from there. If celeron likes this idea, put my name up in the whodoeswhat wiki. :)

Input refactoring test implementation here:

http://bitbucket.org/spongie/minetest-spongie/changeset/f69d72ff4e2d

- Replaces InputHandler with abstract NewInputHandler (I know, I don't know why I kept the old one) that handles presses, releases and states of keyboard, mouse buttons and joystick buttons. Also reads mouse position and joystick axes realtime.
The current only implementation is IrrlichtInputHandler which uses Irrlicht to get input.
- Adds Controller, abstract type for setting up control variables based on settings.
- Implemented Controller's: GameController (used while playing) and MenuController (will be used when a menu or window is active).

Todo:
- Dynamic binding of keys, mouse and joystick axes to each possible control.
- Integrate MenuController with the UI.
- Complete the joystick portion in GameController.

Any number of Controller implementations can be written for any type of control interface, say vehicles, in game, controlling the cursor in menus using a joystick etc. A controller is updated from any number of NewInputHandler implemenations, this means we can easily add 3rd party input without changing any game controllers or game code.

It's getting late and I've been working on this all day so, cheers and good night!

So this is what has become of suggestion for replacing the old controls.

Overview:
http://bitbucket.org/spongie/minetest-spongie/wiki/Home

It's looking OK. It's quite comfortable playing the game with joystick.

There's still an issue with Irrlicht mouse events and using setPointer to keep the cursor in the middle of the screen. I'm hoping I'll figure it out soon tho.