Modders: Give feedback to the core developers

[Kilarin]

I've got a suggestions for the developers:

Put the "creative mode" check box in the "Configure" section so that it will be set for each world separately. I think it's the intuitive way to do it. I've created worlds that I use in creative mode, and worlds that I do NOT use in creative mode. I should be able to set the default for each just like I set which mods are active for each.

[Calinou]

What about being able to hide/show the entity collision_box? When sitting in a car, this box just looks ugly...

You can resize the collision box to be a flat square that sits low in the car, still visible when entering the car but out of the way when driving, here's what i did in my 'mesecar' mod:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local boat = {
   physical = true,
   collisionbox = {-0.6,0.75,-0.6, 0.6,0.75,0.6},
   visual = "mesh",
   visual_size = {x=1,y=1.6},
   mesh = "mesecar.x",
   textures = {"mesecar_mesecar.png"},
   --stepheight = 1.1,
   driver = nil,
   v = 0,
}

This might work, but still is a dirty solution :/

What if you make it higher than the player's eye height while they are attached to the car? Will the box be pointed, since the player will be inside it?

[dgm5555]

Put the "creative mode" check box in the "Configure" section so that it will be set for each world separately

+1 (and include damage). The tickboxes could stay where they are, but reflect the currently selected world.

I'd also vote for some enhancements to the mods tab:-
1. enabling manually installing and updating of github based mods. I presume it's doing something like this already, as there seems to be some sort of version control for some mods.
Enhancements to this would be
2. a (?title only) search of common mod locations (eg the forum Mod Releases, MMDB, and possibly a search for 'betas' in Modding General)
3. Link from minetest to the webpage (since the modstore often cuts off description)
4. Alternatively, I'm guessing the 'modstore' is generated from MMDB. Would there be anyway of automatically generating MMDB entries for mods placed in Mod Releases. [The argument that manually entered entried in MMDB is 'better quality' is false, as a number of mods found by the modstore are unable to be installed anyway (I presume because there's no zipfile), so are essentially 'dead links'.]
5. possibly selecting default mods from here for particular games (rather than having to copy to the minetest_games/mods (or equiv) folder)

[Wuzzy]

I think some sort of mod profiler would be pretty useful. Basically, the mod profiler just measures how much time each mod eats away on a running server.
This would be useful for developers who want to optimize speeds but also for server operators who put a lot of mods on their server and there’s one mod which slows down everything, but it is hard to find out which one.

[Kilarin]

I've got a core development request. One that I don't think would be too complicated, but would REALLY make it easier for me to use the game.
in minetest.conf I can set screenshot_path = path/to/folder/ to make the screenshots go wherever I want.
What I CANT do is to give the screenshot a name. What would be wonderful would be if hitting shift-f12 (or ctrl or alt, whatever) would not just take a screenshot, but also let the user type in a name for the file.

[Sokomine]

What I CANT do is to give the screenshot a name. What would be wonderful would be if hitting shift-f12 (or ctrl or alt, whatever) would not just take a screenshot, but also let the user type in a name for the file.

I'm not sure if entering a filename whenever doing a screenshot would be very comftable when playing the game. Instead, I'd prefer screenshots to be named screenshot_servername_port_date_time.png

[Linuxdirk]

Just one thing: in-client mod updates. (Mods provide a version number and an update check URL and latest version URL.)

[Kilarin]

I'm not sure if entering a filename whenever doing a screenshot would be very comftable when playing the game. Instead, I'd prefer screenshots to be named screenshot_servername_port_date_time.png

Thats why I specified a different keystroke. I know a lot of people want to just hit f12 and take that screenshot. But me, I often need to record where that screenshot was taken if I ever want to find it again and document it correctly when I post it. Thats why I proposed that f12 work the way it always has, but shift-f12 (or ctrl or alt or whatever) be set to give me the option to name the screenshot file.

[Evergreen]

Just one thing: in-client mod updates. (Mods provide a version number and an update check URL and latest version URL.)

If mmdb takes off, I think that should be a goal.

[TenPlus1]

A way to configure mods without editing text files would be handy, clicking the mod from the list and a small configure button appearing next to it with entry boxes, tick boxes etc... This would also be handy for enabling/disabling map features like jungles, caves, ridges etc.

[Linuxdirk]

If mmdb takes off, I think that should be a goal.

I like the idea of extended meta data more.

Currently we have no version information at all. I think about a meta.cfg for mods/modpacks.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

[info]
name = My great mod(pack)
version = 1.0.2
author = John D. Random
url = http://example.com/my_great_mod/info.php

[depends]
mod_number_1 = >1.0
secondmod = any
third = 3.0 optional
number_four = 2.*
fifth_one = 2.5.4

[update]
interval = 5
check = http://example.com/my_great_mod/version.txt
download = http://example.com/my_great_mod/mod_%s.tar.gz

[info] allows mod authors to give information about the mod being viewable in client (maybe an image.png as screenshot/logo/icon), includig mod name, author name and an URL for more information about the mod.

[depends] makes it possible to define what other mods the mod depends on allowing < and > for “older than” or “newer than”, “any“ for – any version of the mod, an additional “optional” after the version indicator if the mods only is an optional dependency to the mod and * as wildcard character. The block can be omitted if it’s a mod pack.

[update] contains update parameters. interval is the check-interval in days. After X days the client checks for an update. The URL given for check returns only one string, the latest version of the mod. If the version is higher than info/version the client loads the new mod from the URL given in download and installs it.

[addi]

If mmdb takes off, I think that should be a goal.

I like the idea of extended meta data more.

Currently we have no version information at all. I think about a meta.cfg for mods/modpacks.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

[info]
name = My great mod(pack)
version = 1.0.2
author = John D. Random
url = http://example.com/my_great_mod/info.php

[depends]
mod_number_1 = >1.0
secondmod = any
third = 3.0 optional
number_four = 2.*
fifth_one = 2.5.4

[update]
interval = 5
check = http://example.com/my_great_mod/version.txt
download = http://example.com/my_great_mod/mod_%s.tar.gz

[info] allows mod authors to give information about the mod being viewable in client (maybe an image.png as screenshot/logo/icon), includig mod name, author name and an URL for more information about the mod.

[depends] makes it possible to define what other mods the mod depends on allowing < and > for “older than” or “newer than”, “any“ for – any version of the mod, an additional “optional” after the version indicator if the mods only is an optional dependency to the mod and * as wildcard character. The block can be omitted if it’s a mod pack.

[update] contains update parameters. interval is the check-interval in days. After X days the client checks for an update. The URL given for check returns only one string, the latest version of the mod. If the version is higher than info/version the client loads the new mod from the URL given in download and installs it.

your format is ini format, not cfg format.
i would suggest using something like appinfo.json format. i know its used in WebOS, but json is more dynamical than cfg and also human-readable.

the update intervall should be set by client, not by mod.

[Evergreen]

I think a json config file to provide information would be a great idea. To go along with that, a better mod selection formspec would be nice as well.

[Linuxdirk]

your format is ini format, not cfg format.

Of shit, you’re right. I meant meta.ini … My brain is on stand-by for unknown reason :D

but json is more dynamical than cfg and also human-readable.

Why over-complicate it? Prettified JSON would look like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

{
    "info":{
        "name":"My great mod(pack)",
        "version":"1.0.2",
        "author":"John D. Random",
        "url":"http://example.com/my_great_mod/info.php"
    },
    "depends":{
        "mod_number_1":">1.0",
        "secondmod":"any",
        "third":"3.0 optional",
        "number_four":"2.*",
        "fifth_one":"2.5.4"
    },
    "update":{
        "interval":"5",
        "check":"http://example.com/my_great_mod/version.txt",
        "download":"http://example.com/my_great_mod/mod_%s.tar.gz"
    }
}

I don’t see any advantage in it. Parsing JSON or INI syntax isn’t that much of a big deal and INI syntax is easier to write.

JSON is awesome when you want to save space when transferring it because you can put anything in one line without spaces (except in the strings if you want them there).

[addi]

Why over-complicate it? Prettified JSON would look like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

{
    "info":{
        "name":"My great mod(pack)",
        "version":"1.0.2",
        "author":"John D. Random",
        "url":"http://example.com/my_great_mod/info.php"
    },
    "depends":{
        "mod_number_1":">1.0",
        "secondmod":"any",
        "third":"3.0 optional",
        "number_four":"2.*",
        "fifth_one":"2.5.4"
    },
    "update":{
        "interval":"5",
        "check":"http://example.com/my_great_mod/version.txt",
        "download":"http://example.com/my_great_mod/mod_%s.tar.gz"
    }
}

I don’t see any advantage in it. Parsing JSON or INI syntax isn’t that much of a big deal and INI syntax is easier to write.

JSON is awesome when you want to save space when transferring it because you can put anything in one line without spaces (except in the strings if you want them there).

yeah json is a bit more complicated, but its already implemented in minetest, and its much more powerfull than ini or cfg.
also JSON is a designed to share data between diffrent programs or programming languages. So the moddb can it also read, as the minetest engine or a 3rd party program, or a human.

[Linuxdirk]

yeah json is a bit more complicated, but its already implemented in minetest

Okay, then it should be done in JSON :)