FOSS gamedev and creative worlds

I don't want to get anyone too excited, but this just happened:



Here's where the fun starts: 0.7a. :)

--> Now includes map mod, which lets you control settings for the map (though I haven't figured out how to make this work properly for multiplayer, yet).

EDIT: Now with proper githubbing goodness: https://github.com/gsmanners/minetest/tree/gsmapper
And available as a pull request for your pulling pleasure: https://github.com/minetest/minetest/pull/1209

EDIT: 0.3 (using some more proper drawing routines)
0.3c (better texture clean up, proper scanning, fixed a few bugs)
0.4b (more fixes, player marker, one big optimization for non-tracking mode)
0.4e (fixes/workarounds and stuff, not too sure but I think it works mostly)
0.5a (radar mode implemented)
0.5b (a few fixes)
0.6 (optimized with tracking in mind, doesn't need quite so long a cool down)
0.6b (a few more fixes)
0.7a (dynamic colors, initial release)

What must be done with this to get it to work?

You might want to show this to the community of the following fork of Minetest too:
http://freeminer.org/
The developers of that fork are more likely to accept this.

I'm excited. But the patching is not too straightforward. Can you tell me how to get this compiled?

@Inocudom: Please don't be such a sadist. The Minetest developers will pull stuff that is fit to merge. This is the reason why minetest is also much more stable and lighter than FM. End of Story.

Yes, but the developers of Minetest can be a little cautious with pulling features.

Why, I say, why aren't people talking about this feature?

hoodedice wrote:The Minetest developers will pull stuff that is fit to merge. This is the reason why minetest is also much more stable and lighter than FM.

[citation needed]

mauvebic wrote:

hoodedice wrote:The Minetest developers will pull stuff that is fit to merge. This is the reason why minetest is also much more stable and lighter than FM.

[citation needed]

citation: Original research.

@Ino: Because it doesn't have a 'download' button.

hoodedice wrote:citation: Original research.

Real researchers usually publish their work along with their conclusions :P I say this because just 24 hours ago, something was pulled to MT that made it totally unplayable. So obviously MT is not immune to pulling "unfit" stuff :-)

mauvebic wrote:

hoodedice wrote:citation: Original research.

Real researchers usually publish their work along with their conclusions :P I say this because just 24 hours ago, something was pulled to MT that made it totally unplayable. So obviously MT is not immune to pulling "unfit" stuff :-)

I agree about the research. put some of your own stats into it (number of errors, normal fps, cpu usage, data usage, graphics rendering, etc.).

If you want to try it out, go ahead and unpack the 0.4.9 source somewhere and then do the diff for game.cpp. Then edit the CMakeLists.txt so that it includes gsmapper.cpp in the list under where it says "Client sources". Oh, and make sure you have hud_map = true in your conf (or you'll get shader timeouts and stuff).

If that just went over your head then you'll want to have a look at this:

http://dev.minetest.net/Compiling_Minetest

I kind of like the idea behind Freeminer, but I honestly just think of it like the experimental branch of Minetest. It's pretty cool, but it could take a while to win me over.

Novacain wrote:put some of your own stats into it (number of errors, normal fps, cpu usage, data usage, graphics rendering, etc.).

I hope that's addressed to the other guy, since i'm not the one making unfounded claims :p But in case it isn't, the issue im referring to is here with the relevant discussion here.

mauvebic wrote:

Novacain wrote:put some of your own stats into it (number of errors, normal fps, cpu usage, data usage, graphics rendering, etc.).

I hope that's addressed to the other guy, since i'm not the one making unfounded claims :p But in case it isn't, the issue im referring to is here with the relevant discussion here.

The stuff has been since fixed. See next day.

hoodedice wrote:The stuff has been since fixed. See next day.

I know, i've been keeping up. I was simply demonstrating that MT devs are no more infallible than FM devs.

mauvebic wrote:

hoodedice wrote:The stuff has been since fixed. See next day.

I know, i've been keeping up. I was simply demonstrating that MT devs are no more infallible than FM devs.

I never said they were SuperMen. It's just that MT's code is much more thoroughly checked before merging.

mauvebic wrote:

Novacain wrote:put some of your own stats into it (number of errors, normal fps, cpu usage, data usage, graphics rendering, etc.).

I hope that's addressed to the other guy, since i'm not the one making unfounded claims :p But in case it isn't, the issue im referring to is here with the relevant discussion here.

I was just supporting your statement, no worries.

hoodedice wrote:I never said they were SuperMen. It's just that MT's code is much more thoroughly checked before merging.

Of course but the fact that mistakes happen disproves the notion that only things that are fit gets pulled :P

Novacain wrote:I was just supporting your statement, no worries.

That's what I figured, but quotes within quotes tend to be confusing :P

Slowly moving toward a mapper that might actually be usable...

gsmanners wrote:Slowly moving toward a mapper that might actually be usable...

Is there a way that this mapper would be able to show blocks that are from mods?

Currently, this converts any block by name to a specific color. Those colors are defined in the gsMapper constructor, but I'll probably load those from a file somewhere in a future version.

gsmanners wrote:Currently, this converts any block by name to a specific color. Those colors are defined in the gsMapper constructor, but I'll probably load those from a file somewhere in a future version.

How about VanessaE's colors.txt?

If it'll be of use, you're more than welcome to use my colors.txt:

http://digitalaudioconcepts.com/vanessa/hobbies/minetest/colors.txt

VanessaE wrote:If it'll be of use, you're more than welcome to use my colors.txt:

http://digitalaudioconcepts.com/vanessa/hobbies/minetest/colors.txt

Still no plasticbox support in there, I see.

Inocudom wrote:Yes, but the developers of Minetest can be a little cautious with pulling features.

Why, I say, why aren't people talking about this feature?

'Cause we're too busy trying it out.

Well, there's really not much to talk about just yet. It's barely more than a proof-of-concept code at the moment.

Thanks for the colors.txt, by the way. That'll be helpful, though I doubt I'll be supporting more than 256 entries in my color table. I don't think I need all the overhead of a huge color table on top of everything else. It also seems kind of silly to me to need more than 30 or 40 colors, anyway. Good maps give you highly simplified information IMHO.

gsmanners wrote:Well, there's really not much to talk about just yet. It's barely more than a proof-of-concept code at the moment.

Thanks for the colors.txt, by the way. That'll be helpful, though I doubt I'll be supporting more than 256 entries in my color table. I don't think I need all the overhead of a huge color table on top of everything else. It also seems kind of silly to me to need more than 30 or 40 colors, anyway. Good maps give you highly simplified information IMHO.

If your minimap feature is ever added to Minetest, the color limit could end up being configurable.

The color limit is whatever you want. I just don't think it's all that big a deal. Still, you multiply the number of nodes to scan through by 100, you increase the overhead by 100.

Well, I'll figure something out. Meanwhile... I think I more or less have this player marker thing working.

EDIT: Stuff like this is starting up...

[spoiler][/spoiler]

EDIT #2: Okay, let's see... Time to sort out my todo list here:

- Load up a color config file on construct.
- Load/save above map info somewhere.
- Other player markers.
- Custom markers.
- Custom annotations.
- Custom lines (borders).
- X, Y, Z info (probably won't bother).

Just a few things before I'll call this finished, but this is a nice stopping point for now.

gsmanners wrote:The color limit is whatever you want. I just don't think it's all that big a deal. Still, you multiply the number of nodes to scan through by 100, you increase the overhead by 100.

Well, I'll figure something out. Meanwhile... I think I more or less have this player marker thing working.

EDIT: Stuff like this is starting up...

[spoiler]http://i.imgur.com/KeWSNIp.jpg[/spoiler]

EDIT #2: Okay, let's see... Time to sort out my todo list here:

- Load up a color config file on construct.
- Load/save above map info somewhere.
- Other player markers.
- Custom markers.
- Custom annotations.
- Custom lines (borders).
- X, Y, Z info (probably won't bother).

Just a few things before I'll call this finished, but this is a nice stopping point for now.

hmmm, instead of color maps for some nodes you could scan all registered nodes at startup and process their textures (tops) to get color info from them

RealBadAngel wrote:

gsmanners wrote:The color limit is whatever you want. I just don't think it's all that big a deal. Still, you multiply the number of nodes to scan through by 100, you increase the overhead by 100.

Well, I'll figure something out. Meanwhile... I think I more or less have this player marker thing working.

EDIT: Stuff like this is starting up...

[spoiler]http://i.imgur.com/KeWSNIp.jpg[/spoiler]

EDIT #2: Okay, let's see... Time to sort out my todo list here:

- Load up a color config file on construct.
- Load/save above map info somewhere.
- Other player markers.
- Custom markers.
- Custom annotations.
- Custom lines (borders).
- X, Y, Z info (probably won't bother).

Just a few things before I'll call this finished, but this is a nice stopping point for now.

hmmm, instead of color maps for some nodes you could scan all registered nodes at startup and process their textures (tops) to get color info from them

That is an interesting suggestion to make to gsmanners, RealBadAngel.

RealBadAngel wrote:hmmm, instead of color maps for some nodes you could scan all registered nodes at startup and process their textures (tops) to get color info from them

Color maps are easier. Plus, I'd feel obliged to make the spec configurable (which would mean a redesign for that).

If you want to try doing it, you're welcome but I think I'll pass on that.

Why do you compete?

You guys should not fight.

This looks very interesting.

(Posted this to subscribe)