OldCoder general development

[octacian]

Thanks, I'll read that over several times and make sure I understand. paramat pointed me to use the new LBMs, so I'll probably try and apply some of the above to them.

[OldCoder]

Thanks, I'll read that over several times and make sure I understand. paramat pointed me to use the new LBMs, so I'll probably try and apply some of the above to them.

LBMs may be all that you need.

The approach that I outlined isn't necessarily recommended for general applications. It's what I used in "codersea", though, and may be suitable for some purposes.

[octacian]

Thanks, I'll read that over several times and make sure I understand. paramat pointed me to use the new LBMs, so I'll probably try and apply some of the above to them.

LBMs may be all that you need.

The approach that I outlined isn't necessarily recommended for general applications. It's what I used in "codersea", though, and may be suitable for some purposes.

I honestly don't quite get LBMs; they seem pretty well the same as ABMs to me, though I do see that they seem more general. I also understand that they only run at startup, but that's the only difference I see.

[OldCoder]

I honestly don't quite get LBMs; they seem pretty well the same as ABMs to me, though I do see that they seem more general. I also understand that they only run at startup, but that's the only difference I see.

LBMs are designed to support the processing of nodes on a "once and only once" basis. It appears that this is the primary special feature supported.

So, LBMs should be able to handle dynamic ore generation without the need for the kludge that "codersea" relies on. However, they don't support the "neighbors" feature that ABMs offer, so "codersea's" ABM-based approach will be the better way to go in some cases.

[OldCoder]

My Windows Minetest clients have been updated. You can download the latest releases using these links:

For 32-bit Windows: http://minetest.org/minetest-oldcoder-win32.zip

For 64-bit Windows: http://minetest.org/minetest-oldcoder-win64.zip

Features and/or changes are as follows:

1) I've enabled the use of Freetype2. To see the results, review the 1st screenshot below.

2) The console F10 change that the core devs made recently has been modified. In my version, the F10 key opens a text console that takes up 60% of the screen as opposed to 100%.

I'll add a preference later which lets the player specify the F10 console height. That's how the official version should handle it, so I might submit the change as a pull request.

3) My Windows builds include a preloaded cache and are compiled using gcc -O3. These changes tend to make both startup and runtime faster. -Os might be faster than -O3 in some cases, so I might try that setting at some point.

Here's a set of Before and After screenshots which illustrates the Freetype2 change. The screen on the left is without Freetype2. The screen on the right is with Freetype2.





As a bonus, here's a screenshot of Deep Winter. I actually made the Freetype2 change in exchange for the screenshot.




This is just a clip from the full screenshot, which is pretty large. To see the whole thing, click on the following link:

http://minetest.org/images/160716_deep_winter_full.jpg

Deep Winter is an ancient city located in the frozen wastes of a forgotten world.

When the glaciers crept over the land, an unknown number of years ago, the people fled or perished, but the walls endured and refused to break.

Much of the city is now frozen solid, contained within the glacier that slid across it. Along the walls strange purple light burns in place of warm gold flame and the only sound is of the wind.

Explorers sometimes brave the cold and quiet ruins, looking for answers, searching for history. But there is no library and there are no carvings on the buildings. No statues. No memories. Whoever these people were, they are gone without so much as a whisper.

Only the wind and the walls remain.

[TumeniNodes]

That is beautiful!!

[OldCoder]

We've seen a number of Minetest logins recently that use nicks of the form "Sadie" followed by four digits. Sometimes fewer digits, sometimes more, and occasionally with letters added.

This started around July 1. I've had about 200 different visitors myself of this type in the last three weeks.

Most of the "Sadie's" don't talk. Out of the 200 or so that have visited my worlds, only two seem to have said more than a few words. One of those is polite and the other is a troll.

These nicks often behave like bots. But least two of them do talk and a few of the rest try to build. This might be one person testing a bot. Or it might be multiple people using a new Minetest client. If so, it's not clear what the new client is designed to do or why there's an emphasis on "Sadie" nicks.

There may not be a problem, but I'm going to block most of the "Sadie's" to see if this leads to an explanation.

If you'd like to block the "Sadie's" as well, install the following mod:

http://minetest.org/mods/name_restrictions.zip

This is my fork of Shadow Ninja's mod of the same name. This version blocks the majority of the "Sadie's", but whitelists the one who seems to be real and is not a troll.

[OldCoder]

Shiftus the Architect asked me today for tips related to making a Minetest cloud node of his own, one that could be broken. I thought I'd offer code for a sample mod of this type that novice modders could use as a starting point for other nodes.

The sample mod is named "loudcloud". It creates a cloud node that says "Ouch" when you punch it and drops cooked bacon if you break it.

The "bacon" mod is needed for this to work. However, "loudcloud" will still run if "bacon" is missing; the cloud node will simply drop a block of wood instead in this case.

Here's a loud proud unbowed bacon-dropping cloud produced by the mod:




To create the cloud, in this case, I used Minetest worldedit to fill a region with "loudcloud:cloud" nodes. The mod could be extended to create clouds automatically. Other possible features might include raining, literally, cats and dogs.

<Mary> It's raining cats and dogs
<William> I know; I just stepped in a poodle

As a technical note, Amaz and Gary White point out that, if you're in Creative mode, breaking cloud nodes will only get you one piece of bacon at a time, regardless of the number of nodes that you break. You need to eat the bacon before more will appear.

The "loudcloud" mod can be downloaded from this link:

http://minetest.org/mods/loudcloud.zip

The mod consists of four files:

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

init.lua               - The mod's Lua code, presented below
depends.txt            - The mod's dependency file, also presented below
sounds/cloud_ouch.ogg  - A sound file, included in the ZIP file
textures/loudcloud.png - A PNG texture file, included in the ZIP file


"depends.txt" consists of two lines:

default
bacon?

The question mark "?" after "bacon" here indicates that the "bacon" mod is a dependency, but is optional. In other words, "loudcloud" would like to use the "bacon" mod, but can be loaded without it.

For more information, see the comments in "init.lua" or in the copy pasted below:

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

-- "depends.txt" should list the "bacon" mod.

-- If the "bacon"  mod  is  present,  this  code
-- sets  "cloud_drop" to "bacon:cooked".  Other-
-- wise, "cloud_drop" is left as "default:wood".

local cloud_drop  = "default:wood"
local prefer_drop = "bacon:cooked"

if minetest.registered_items [prefer_drop] then
    cloud_drop = prefer_drop
end                   

-- This code registers a  cloud node  that  says
-- "ouch" when somebody punches it, that can  be
-- broken by hand, and  that drops  cooked bacon
-- when it's broken.

-- The cloud tile is simply a copy of  "default_
-- cloud.png",  which comes  with minetest_game.
-- The PNG file should be  placed in a subdirec-
-- tory of the mod directory named "textures".

-- The sound file is an  Ogg-format  sound  clip
-- obtained from the Web and renamed to  "cloud_
-- ouch.ogg".  The  ".ogg"   filename  extension
-- should be omitted in the Lua code. The ".ogg"
-- file itself should be placed in  a  subdirec-
-- tory of the mod directory named "sounds".

minetest.register_node ("loudcloud:cloud" , {
    description = "Loud Cloud"          ,
    tiles = { "loudcloud.png" }         ,
    is_ground_content     = false       ,
    drop                  = cloud_drop  ,
    paramtype2            = "facedir"   ,

    groups                = {
        choppy                  = 3 ,
        cracky                  = 2 ,
        oddly_breakable_by_hand = 2 ,
    } ,
    legacy_facedir_simple = true        ,
    sounds = {
        dig  = "cloud_ouch" ,
        gain = 0.20         ,
    }                                   ,
})


[OldCoder]

It's time to talk skins
Skins are mostly the same size
The basics are not a great surprise
But skins serve a purpose
Skins can be a porpoise
A cat, a battery, or a tree
Anything that makes somebody go, "Gee
that is what I'd like to be"
Skins are useful and they are free
It's time to talk skins

MT started out with 2D skins, which are still supported. Note: I use them myself for my fork of CoRNeRNoTe's Critters.

In Fall 2013 or Spring 2014, MT added support for 3D MC-compatible skins, stored on-disk as 64x32 PNG files.

3D skins were a positive development. However, MT lagged behind MC because MC added support for higher-resolution 64x64 skins in Fall 2014.

In Fall 2016, Jordach addressed this issue through the creation of a MT patch-set that added 64x64 skin support while preserving backwards compatibility with 64x32 skins.

In fact, Jordach noted, the patch-set supported even higher resolutions, as long as the width-to-height ratio was either:

* one to one (for example, 256x256 PNG files) or
* two to one (for example, 256x128 PNG files)

Technical note: Powers of two were, and remain, best in this context. So, for example, 128x128, 128x64, 256x256, and 256x128 are all good sizes.

The patch-set operated at the mod level. In other words, no changes to the MT core were needed.

As of Fall 2017, the patch-set is available for MT modders and server hosts to use, but it hasn't made its way into standard "minetest_game". This upgrade is past due. Check out the results:



64x64 support adds significant detail and I'm not aware of any strong arguments against adoption.

One objection might be that this feature requires the "player_textures" mod and not everybody will want to use it. However, there's a possible solution. We'll come back to this issue further down.

Here's how to make the change yourself. If you're not a Coder, it's tricky, but as the screenshot shows, the results are worth it.

You'll need MT 0.4.14 or above, the "player_textures" mod, and a working knowledge of patch files and modding in general.

Note: This feature is intended for use with worlds based on "player_textures" as opposed to "warddrobe" or other skin mods.

Step #1: Shut down the world that you'd like to upgrade.

Step #2: Download the following ZIP file. Unpack it in a temporary directory somewhere.

http://minetest.org/mods/skins32to64.zip

Step #3: Add the following setting to your world's "minetest.conf" file:

secure.enable_security = false

Step #4: Remove any mods, except for "default", that contain files named "character.b3d" or "character.x".

Step #5: The ZIP file "skins32to64.zip" includes the following text file:

player_textures/init.lua

Replace the "init.lua" file in your copy of the "player_textures" mod with the version from the ZIP file.

Note: The file in question was based originally on:

https://raw.githubusercontent.com/Jorda ... s/init.lua

The original version shouldn't be used without an edit. Specifically, the following lines should be commented out or deleted:

minetest.chat_send_all(tostring(width))
minetest.chat_send_all(tostring(height))

My version comments out the lines in question.

Step #6: The ZIP file "skins32to64.zip" includes a patch file named "player.lua.patch". Apply the patch to your copy of "default/player.lua".

The patch may not apply cleanly. If it doesn't, the changes are very simple; review them and make them manually.

Step #7: The ZIP file "skins32to64.zip" includes these four PNG files:

player_textures/textures/player_generic64.png
player_textures/textures/player_sally64x32.png
player_textures/textures/player_sally64x64.png
player_textures/textures/ptextures_transparent.png

Copy these four PNG files into the "textures" subdirectory of your copy of the "player_textures" mod.

"player_generic64.png" was obtained originally from:

https://raw.githubusercontent.com/Jorda ... player.png

"ptextures_transparent.png" was obtained originally from:

https://raw.githubusercontent.com/Jorda ... parent.png

Step #8: The ZIP file "skins32to64.zip" includes these two files:

default/models/character.png
default/models/character.x

Copy both files into the "models" subdirectory of your copy of the "default" mod.

These two files were obtained originally from:

https://raw.githubusercontent.com/Jorda ... racter.png

https://raw.githubusercontent.com/Jorda ... haracter.x

Step #9: Restart the world.

The "player_..." PNG files that we added in step 7 are skins that you can use to test the changes. To try them out, simply play MT using the names listed on the left below:

generic64 - Generic 64x64 skin
sally64x32 - Sample 64x32 skin from the screenshot
sally64x66 - Sample 64x64 skin from the screenshot

To integrate this feature into "minetest_game", we could proceed as follows:

(a) Define a new "minetest.conf" parameter named "skins32". The default setting would be false.

(b) Make the "player.lua" change indicated in the patch file, but modify it to support the "skins32" flag. If the flag was true, the change would be disabled.

(c) Add Jordach's version of the "player_textures" mod, but modify it to support the same flag. If the flag was true, the mod would be disabled.

[sparky]

Is this compatible with 3d_armor?

[OldCoder]

Is this compatible with 3d_armor?

I tested compatibility with a number of mods last night, including 3d_armor. Results are that the latest versions of most mods seem to be compatible with the upgrade, but 3d_armor is an exception.

If minetest_game is modified to support 64x64 skins, 3d_armor will still work, but only if a world is limited to 64x32 skins.

[stu]

I have also made a version of the player model with MC 1.8 skin support, exported as .b3d and also incorporates recent changes to the armature. https://github.com/stujones11/minetest-models/tree/master/character/skin_format-1.8 I have also posted some skin conversion tools here https://github.com/stujones11/skin-converter

There is a MTG issue https://github.com/minetest/minetest_game/issues/1235 if you want to show your support for updating the player skin format, the MT game devs do not seem too keen on the idea

Re. 3d_armor, the 0.5.0-dev branch already has builtin support for skin format 1.8, however, it is a little out-dated now. Naturally, if MTG were to update the model, I can easily update the armor model to suit.

[OldCoder]

The patchset posted above addresses some of the problems mentioned in issue 1235. So far, it seems to be a seamless, backwards-compatible, upgrade, except for 3d_armor compatibility. Both 64x32 and 64x64 skins can be used with modified "_games".

If the proposed changes are made, 3d_armor 0.5.0-dev works with 64x32 skins, but it doesn't work with 64x64. If a version that's compatible with the patchset can be provided, this will increase chances of formal integration.

If not, there is no real argument against the new feature, regardless, as 3d_armor will still work after the change. It simply won't be possible to use 64x64 skins on a world that has 3d_armor and this is already the case.

As a technical note, the patchset theoretically supports even larger skins, for example, 128x128 or 128x64. But these would probably be rare enough that 3d_armor wouldn't need to support them initially.

[stu]

The multi-format model approach is unlikely to be accepted in MTG due to its excessive file size but I could be wrong. I personally support the idea of a clean upgrade as older skins can be easily converted to the new format and are pretty much obsolete now anyway. I might also point out that the model in this patch-set will not work with my wield3d mod due to attachement problems with directx and the afore mentioned changes to the armature.

[OldCoder]

1. The multi-format model approach is unlikely to be accepted in MTG due to its excessive file size but I could be wrong. 2. I personally support the idea of a clean upgrade as older skins can be easily converted to the new format and are pretty much obsolete now anyway. 3. I might also point out that the model in this patch-set will not work with my wield3d mod due to attachment problems with directx and the aforementioned changes to the armature.

1. What file size are you referring to? The patchset adds just 30 KB to the size of "character.x". Additionally, the increase in size of a typical skin PNG file in the transition from 64x32 to 64x64 is negligible.

2. People won't agree to break all of the existing worlds out there. The option of converting skins doesn't make a significant difference. Backwards compatibility is most likely a requirement for integration of the changes.

3. If 3d_armor can't be modified to work with the patchset, this is O.K. The mod will still work after the changes are integrated. It simply won't support 64x64 skins, which is already the case (at least for the release version).

[stu]

The patchset adds just 30 KB to the size of "character.x".

Last I checked, Jordach's model was approx 350k vs 85k for the current b3d player model, those kb's will quickly add up on a busy server. But don't get me wrong, I am not knocking what you are doing here, unfortunately, there is no easy way for me to support these changes in the 3d_armor mod or I would.

[OldCoder]

Last I checked, Jordach's model was approx 350k vs 85k for the current b3d player model, those kb's will quickly add up on a busy server. But don't get me wrong, I am not knocking what you are doing here, unfortunately, there is no easy way for me to support these changes in the 3d_armor mod or I would.

I'm not sure that I follow. There should be only one of these models per "_game", shouldn't there? Are you referring to RAM usage as opposed to disk space?

Thanks for the remarks, regardless.

[stu]

Last I checked, Jordach's model was approx 350k vs 85k for the current b3d player model, those kb's will quickly add up on a busy server. But don't get me wrong, I am not knocking what you are doing here, unfortunately, there is no easy way for me to support these changes in the 3d_armor mod or I would.

I'm not sure that I follow. There should be only one of these models per "_game", shouldn't there? Are you referring to RAM usage as opposed to disk space?

Thanks for the remarks, regardless.

I was mostly thinking of server bandwidth though I realize that it's not such a big deal. However, that is just one of the reasons that I think would make it unlikely to be accepted in MTG.

[OldCoder]

Sparky asked, "Do you know where I can get lib_mount? It's required by some car mods and animals, to be able to mount them."

"lib_mount" is easy to obtain and install. This tutorial will discuss installation and testing. As a bonus, we'll throw in the "vehicles" mod at no extra charge.

I hadn't tried these mods yet, myself, until today. But now I'm able to answer the question, "What would the Dukes of Hazzard be like if it was filmed in Minetest?"



1. "lib_mount" is available from the github page at:

https://github.com/blert2112/lib_mount

The direct download link for a "lib_mount" git snapshot is:

https://github.com/blert2112/lib_mount/ ... master.zip

2. To install or update "lib_mount" under Linux, cd to the appropriate "_game" directory and execute:

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

rm -fr lib_mount lib_mount-master master.zip
wget https://github.com/blert2112/lib_mount/archive/master.zip
unzip master.zip && rm master.zip
mv lib_mount-master lib_mount


3. If you'd like to test "lib_mount", install "vehicle_mash":

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

rm -fr vehicle_mash vehicle_mash-master master.zip
wget https://github.com/blert2112/vehicle_mash/archive/master.zip
unzip master.zip && rm master.zip
mv vehicle_mash-master vehicle_mash


This is a mod that adds about 27 vehicles based on "lib_mount".

4. Optional: Try D00Med's "vehicles" mod as well. This is a fork of "lib_mount" that includes some pre-installed vehicles:

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

rm -fr vehicles vehicles-master master.zip
wget https://github.com/D00Med/vehicles/archive/master.zip
unzip master.zip && rm master.zip
mv vehicles-master vehicles


5. When the 1st and/or 2nd mods are installed, restart your MT world.

6. If you installed "vehicles_mash" or "vehicles":

Visit your world. Allow extra time for loading, during the first visit, because new media will need to load. Log-in as the world owner.

7. If you installed "vehicles_mash":

* Turn on flying
* Find a lake or ocean
* Teleport to exactly height zero there
* Execute the command: /spawnentity vehicle_mash:hover_blue
* This should create a blue hovercraft
* To enter the vehicle, right-click on it
* To drive the vehicle, use the Forward key
* To steer it, use the mouse
* To exit the vehicle, right-click on its center

Hovercraft from "vehicle_mash" mod:



8. If you installed "vehicles":

* Find some flat territory that has a little room
* Turn off flying
* Create a police car: /spawnentity vehicles:policecar
* To enter the vehicle, right-click on it
* To drive the vehicle, use the Forward key
* To steer it, use the mouse
* To exit the vehicle, right-click on its center

Driving police car from "vehicles" mod:



Note: The PC F7 key was used here to switch to a view from behind the driver.