[Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesecons]

[rubberduck]

i found a bug (i don't know if this is already known)

when i have mesecons t-part (normal, with the isolated t-part not tested, see image) far away from the last energy-source and i remove the t-part(see selected), something strange happens.


the mesecon-wires go out and also these connected to the energy-source.

to make it work i have to delete the energy-source and re-add it again.

this only seems to happen when a played for some time. (some minutes after restart i removed one part very far away but no problem was there)

[4aiman]

Maybe this has happened due to unloaded energy source?
What happens if you dig the 1st mesecon after they went out and readd it (instead of breaking the energy source?

[hampa16]

This is the mesecons [=minecraft redstone] mod!

Download from GitHub
Download as .zip
Download as .tar.gz

It adds some simple redstone connectors and multiple receptors and effectors.

Check out the mesecons website! Therein you will find all the information about items you need (Microcontroller, Gates, Tutorials, Craft recipes)!
mesecons.net

http://i.imgur.com/KrKzn.png
http://i.imgur.com/hyLKb.png
http://i.imgur.com/3PgqA.png

If someone wants to help me develop mesecons have a look at the developer documentation on the website. You can commit your changes on GitHub.

For Developers: GitHub project page
https://github.com/Jeija/minetest-mod-mesecons
(Send in your changes via forks + pull requests)

Dependencies: none
License:
Textures: CC-BY-SA
Code: LGPL

This mod is not for minetest v0.4.9.
Either update this mod to v0.4.9 or tell me what I'm doing wrong.
Neither say "Idk", "I don't know" nor say "No I will update this mod to v0.4.9".

[Temperest]

...or tell me what I'm doing wrong.

We can't exactly tell you what's wrong if we don't know what you're doing. Try giving some indication of what the issue is, and how you installed the mod.

Neither say "Idk", "I don't know" nor say "No I will update this mod to v0.4.9".

This mod already supports 0.4.9. I am running it on a development build, and it is working fine.

[Kilarin]

I'm running minetest 0.4.9 on a xubuntu based linux system.
I haven't been able to get mesecons to working, so I tried loading the folders one by one and found that I can load most of them just fine, but the following ones cause minetest to lock up:
mesecons_lamp
mesecons_lightstone
mesecons_mvps
mesecons_noteblock
mesecons_pressureplates
mesecons_random
mesecons_switch
(and not really tested because they depend upon mvps are mesecons_movestones and mesecons_pistons)

The progress bar gets almost to the end of "item textures", then my cpu jumps up to 99% and minetest just locks up. I tailed debug.txt while minetest was hung, and it WAS getting output, but very very slowly.

Comparing debug output from a run without mesecons_mvps and a run WITH mesecons_mvps I found the following differences which might be significant:

In the good run, the first debug line is at 11:01:29, and the SQLite3 database is opened 12 seconds later:

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

11:01:44: ACTION[main]:         .__               __                   __
11:01:44: ACTION[main]:   _____ |__| ____   _____/  |_  ____   _______/  |_
11:01:44: ACTION[main]:  /     \|  |/    \_/ __ \   __\/ __ \ /  ___/\   __\
11:01:44: ACTION[main]: |  Y Y  \  |   |  \  ___/|  | \  ___/ \___ \  |  |
11:01:44: ACTION[main]: |__|_|  /__|___|  /\___  >__|  \___  >____  > |__|
11:01:44: ACTION[main]:       \/        \/     \/          \/     \/
11:01:44: ACTION[main]: World at [/home/donald/.minetest/worlds/LearningWorld49]
11:01:44: ACTION[main]: Server for gameid="minetest" listening on 0.0.0.0:62952.
11:01:44: INFO[main]: Creating client
11:01:44: INFO[main]: Connecting to server at 127.0.0.1:62952
11:01:44: INFO[main]: Client::peerAdded(): peer->id=1
11:01:44: VERBOSE[ServerThread]: Server::peerAdded(): peer->id=2
11:01:44: INFO[main]: Client packetcounter (20s):
11:01:44: VERBOSE[ServerThread]: Server: Handling peer change: id=2, timeout=0
11:01:44: INFO[ServerThread]: Server: Maximum lag peaked to 2 s
11:01:45: INFO[ServerThread]: ServerMap: SQLite3 database opened
11:01:46: VERBOSE[ServerThread]: Server: Got TOSERVER_INIT from 127.0.0.1 (peer_id=2)


but when the mvps mod is installed, the first debug line is at 10:33:40, and we connect to the server only 8 seconds later, BUT, there is no "SQLite3 database opened" message:

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

10:33:48: ACTION[main]:         .__               __                   __
10:33:48: ACTION[main]:   _____ |__| ____   _____/  |_  ____   _______/  |_
10:33:48: ACTION[main]:  /     \|  |/    \_/ __ \   __\/ __ \ /  ___/\   __\
10:33:48: ACTION[main]: |  Y Y  \  |   |  \  ___/|  | \  ___/ \___ \  |  |
10:33:48: ACTION[main]: |__|_|  /__|___|  /\___  >__|  \___  >____  > |__|
10:33:48: ACTION[main]:       \/        \/     \/          \/     \/
10:33:48: ACTION[main]: World at [/home/donald/.minetest/worlds/LearningWorld49]
10:33:48: ACTION[main]: Server for gameid="minetest" listening on 0.0.0.0:51151.
10:33:48: INFO[main]: Creating client
10:33:48: INFO[main]: Connecting to server at 127.0.0.1:51151
10:33:48: INFO[main]: Client::peerAdded(): peer->id=1
10:33:48: INFO[main]: Client packetcounter (20s):
10:33:48: VERBOSE[ServerThread]: Server::peerAdded(): peer->id=2
10:33:48: VERBOSE[ServerThread]: Server: Handling peer change: id=2, timeout=0
10:33:48: INFO[ServerThread]: Server: Maximum lag peaked to 0.39 s
10:33:48: VERBOSE[ServerThread]: Server: Got TOSERVER_INIT from 127.0.0.1 (peer_id=2)


that message doesn't appear until over a minute later:

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

10:34:52: INFO[EmergeThread0]: ServerMap: SQLite3 database opened

without mvps the log goes from creating texture/mesh for wool:white to wool:yellow in less than a second:

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

11:01:55: INFO[main]: Lazily creating item texture and mesh for "wool:white"
11:01:55: INFO[main]: Lazily creating item texture and mesh for "wool:yellow"
11:01:55: INFO[main]: - Starting mesh update thread


but WITH mvps there is a huge delay:

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

10:33:57: INFO[main]: Lazily creating item texture and mesh for "wool:white"
10:34:52: INFO[main]: Lazily creating item texture and mesh for "wool:yellow"


Both the logs with and without mvps show these lines:

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

10:34:52: INFO[main]: Compiling high level shaders for plants_shader
10:34:52: INFO[MeshUpdateThread]: getTextureId(): Queued: name="disable_img.png"
10:34:53: INFO[main]: SourceImageCache::getOrLoad(): Loading path "/usr/share/minetest/textures/base/pack/disable_img.png"


But then the crash goes into a strange loop

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

10:34:55: VERBOSE[main]: Client: time_of_day=6006 time_speed=72 dr=940
10:34:56: VERBOSE[ServerThread]: Server: MapEditEvents:
10:34:56: VERBOSE[ServerThread]:   MEET_ADDNODE: - - - - - - - - - - - - - - 1
10:35:00: INFO[main]: Client: avg_rtt=0.002
10:35:00: INFO[ServerThread]: ServerMap: Written: 0 sector metadata files, 1 block files, 185 blocks in memory.
10:35:00: INFO[ServerThread]: ServerMap: Blocks modified by:
10:35:00: INFO[ServerThread]:   setNode, setNodeNoCheck, setNode, setNode: 1
10:35:03: VERBOSE[main]: Client: time_of_day=6115 time_speed=72 dr=995
10:35:06: VERBOSE[ServerThread]: Server: MapEditEvents:
10:35:06: VERBOSE[ServerThread]:   MEET_ADDNODE: - - - - - - - - - - - - - - 1
10:35:06: INFO[ServerThread]: ServerMap: Written: 0 sector metadata files, 1 block files, 222 blocks in memory.
10:35:06: INFO[ServerThread]: ServerMap: Blocks modified by:
10:35:06: INFO[ServerThread]:   setNodeNoCheck: - - - - - - - - - - - - - 1
10:35:07: VERBOSE[main]: Client: time_of_day=6225 time_speed=72 dr=1000
10:35:11: INFO[main]: Client packetcounter (20s):
10:35:11: INFO[main]: cmd 16 count 1
10:35:11: INFO[main]: cmd 32 count 99
10:35:11: INFO[main]: cmd 39 count 1
10:35:11: INFO[main]: cmd 41 count 4
10:35:11: INFO[main]: cmd 49 count 1
10:35:11: INFO[main]: cmd 50 count 4
10:35:11: INFO[main]: cmd 51 count 1
10:35:11: INFO[main]: cmd 52 count 1
10:35:11: INFO[main]: cmd 58 count 1
10:35:11: INFO[main]: cmd 60 count 1
10:35:11: INFO[main]: cmd 61 count 1
10:35:11: INFO[main]: cmd 65 count 1
10:35:11: INFO[main]: cmd 66 count 2
10:35:11: INFO[main]: cmd 67 count 2
10:35:11: INFO[main]: cmd 69 count 1
10:35:11: INFO[main]: cmd 78 count 1
10:35:11: INFO[main]: Client: avg_rtt=0.002
10:35:16: VERBOSE[main]: Client: time_of_day=6338 time_speed=72 dr=1000
10:35:21: VERBOSE[main]: Client: time_of_day=6458 time_speed=72 dr=1000
10:35:24: INFO[ServerThread]: Players:
10:35:24: INFO[ServerThread]: * singleplayer    RemoteClient 2: m_blocks_sent.size()=115, m_blocks_sending.size()=10, m_nearest_unsent_d=6, m_excess_gotblocks=0
10:35:24: INFO[main]: Client: avg_rtt=0.002
10:35:31: INFO[ServerThread]: ServerMap: Unloaded 8 blocks from memory, of which 0 were written, 415 blocks in memory.
10:35:35: VERBOSE[main]: Client: time_of_day=6578 time_speed=72 dr=1000
10:35:35: INFO[ServerThread]: ServerMap: Unloaded 16 blocks from memory, of which 0 were written, 399 blocks in memory.
10:35:42: VERBOSE[main]: Client: time_of_day=6698 time_speed=72 dr=1000
10:35:42: INFO[main]: Client packetcounter (20s):
10:35:42: INFO[main]: cmd 16 count 0
10:35:42: INFO[main]: cmd 32 count 53
10:35:42: INFO[main]: cmd 39 count 0
10:35:42: INFO[main]: cmd 41 count 4
10:35:42: INFO[main]: cmd 49 count 0
10:35:42: INFO[main]: cmd 50 count 0
10:35:42: INFO[main]: cmd 51 count 0
10:35:42: INFO[main]: cmd 52 count 0
10:35:42: INFO[main]: cmd 58 count 0
10:35:42: INFO[main]: cmd 60 count 0
10:35:42: INFO[main]: cmd 61 count 0
10:35:42: INFO[main]: cmd 65 count 0
10:35:42: INFO[main]: cmd 66 count 0
10:35:42: INFO[main]: cmd 67 count 0
10:35:42: INFO[main]: cmd 69 count 0
10:35:42: INFO[main]: cmd 78 count 0
10:35:42: INFO[main]: Client: avg_rtt=0.002
10:35:42: INFO[ServerThread]: ServerMap: Unloaded 12 blocks from memory, of which 0 were written, 420 blocks in memory.
10:35:46: INFO[ServerThread]: ServerMap: Unloaded 11 blocks from memory, of which 0 were written, 409 blocks in memory.
10:35:55: VERBOSE[main]: Client: time_of_day=6818 time_speed=72 dr=1000
10:35:55: INFO[ServerThread]: ServerMap: Unloaded 23 blocks from memory, of which 0 were written, 491 blocks in memory.
10:35:57: INFO[ServerThread]: ServerMap: Unloaded 11 blocks from memory, of which 0 were written, 505 blocks in memory.
10:35:57: INFO[MeshUpdateThread]: getTextureId(): Queued: name="default_torch_animated.png^[verticalframe:16:0"
10:36:00: INFO[main]: Client: avg_rtt=0.002
10:36:00: VERBOSE[ServerThread]: Server: MapEditEvents:
10:36:00: VERBOSE[ServerThread]:   MEET_ADDNODE: - - - - - - - - - - - - - - 1
10:36:00: INFO[main]: Map::getNodeMetadata(): Need to emerge (51,0,-8)
10:36:00: INFO[main]: WARNING: Map::getNodeMetadata(): Block not found
10:36:00: INFO[main]: Client::addNode() took 1ms
10:36:01: INFO[ServerThread]: ServerMap: Unloaded 19 blocks from memory, of which 0 were written, 519 blocks in memory.
10:36:01: VERBOSE[main]: Client: time_of_day=6947 time_speed=72 dr=1000
10:36:04: INFO[ServerThread]: ServerMap: Unloaded 10 blocks from memory, of which 0 were written, 509 blocks in memory.
10:36:05: INFO[ServerThread]: ServerMap: Written: 0 sector metadata files, 1 block files, 509 blocks in memory.
10:36:05: INFO[ServerThread]: ServerMap: Blocks modified by:
10:36:05: INFO[ServerThread]:   setNodeNoCheck: - - - - - - - - - - - - - 1
10:36:07: VERBOSE[main]: Client: time_of_day=7056 time_speed=72 dr=1000
10:36:07: INFO[ServerThread]: ServerMap: Unloaded 5 blocks from memory, of which 0 were written, 504 blocks in memory.
10:36:09: INFO[main]: Client packetcounter (20s):
10:36:09: INFO[main]: cmd 16 count 0
10:36:09: INFO[main]: cmd 32 count 93
10:36:09: INFO[main]: cmd 33 count 1
10:36:09: INFO[main]: cmd 39 count 0
10:36:09: INFO[main]: cmd 41 count 3
10:36:09: INFO[main]: cmd 49 count 0
10:36:09: INFO[main]: cmd 50 count 2
10:36:09: INFO[main]: cmd 51 count 0
10:36:09: INFO[main]: cmd 52 count 0
10:36:09: INFO[main]: cmd 58 count 0
10:36:09: INFO[main]: cmd 60 count 0
10:36:09: INFO[main]: cmd 61 count 0
10:36:09: INFO[main]: cmd 65 count 0
10:36:09: INFO[main]: cmd 66 count 0
10:36:09: INFO[main]: cmd 67 count 0
10:36:09: INFO[main]: cmd 69 count 0
10:36:09: INFO[main]: cmd 78 count 0
10:36:09: INFO[ServerThread]: ServerMap: Unloaded 11 blocks from memory, of which 0 were written, 526 blocks in memory.
10:36:09: INFO[ServerThread]: Players:
10:36:09: INFO[ServerThread]: * singleplayer    RemoteClient 2: m_blocks_sent.size()=235, m_blocks_sending.size()=10, m_nearest_unsent_d=4, m_excess_gotblocks=0
10:36:11: INFO[main]: Client: avg_rtt=0.002


That just keeps going until I kill minetest. Which leaves something hung up so that the only way to run minetest again is to remove mvps from the mod folder and restart the computer.

Jeija mentioned deleting the contents of the mesecon_data file, but I don't find that file anywhere in my .minetest folder.

I'd love to be playing with the full mesecons set, so if anyone knows why I'm locking up, your help would be greatly appreciated.

[IthegeekRS]

You are lucky you can fix it. I cant fix my mesecons_extrawires init.lua. I'm running 0.4.9 3rdpv2
(Blockmens 3rd person v2

[Inocudom]

Is this mod even worked on anymore? Ever since Jeija stopped working on it, it seemed to be quiet.

[Neon]

I think it's in maintenance mode. Though I don't know who is maintaining it.

[sfan5]

Is this mod even worked on anymore?

Yes, but not much.

[Temperest]

I think it's in maintenance mode. Though I don't know who is maintaining it.

We are still maintaining it, and when I can free up more time, I will likely be able to continue developing it. Until then, contributions and ideas are welcome!

[Jeija]

This mod is still developed and should work with the latest minetest versions - I run it every day with the latest minetest version from GitHub.
Actually, there is just very few things to be done in this mod. The mod is pretty much complete as it is and I only know few bugs. I don't want to add more things as these will just make it slower and heavier, but most importantly I don't want to break compatibility with older maps.
Anyways, I'm always open for ideas, bug reports etc. You just need to post them on the Issues section on GitHub.

(btw it is not true that I'm not working on it anymore: GitHub shows that my last commits are only a month old and I'm actively working on some issues.)

I also realized, that fewer people seem to play minetest and use mesecons in general, as fewer participation in discussions or the call for videos shows.
Also, the website stats show the same trend.

[Linxx]

it might be because a lot fo people don't know the mod since it hasn't been in the news in this site for a while and not much stuff has been made with it either

[Kilarin]

I'd use it if I could get it to work. See my above post for the problems I'm having.

[Jeija]

@Kilarin: I have absolutely no idea how that could possibly be happening. Especially, as mesecons_mvps does not contain any new nodes, file acces or anything, but just helper functions that are used by both the piston and the movestone (therefore mv=movestone ps=piston). Does it work when you create a new world?
Could you please try it with the latest version of minetest, mesecons and no other mods installed, does it work then?

[Kilarin]

I installed minetest_201404200513-0~2705~ubuntu12.04.1_i386
Then created a new world with no mods except for the mesecons, and I get the same lockup
Note that I ALSO get a similar lockup on some other mods, such as plantlife, so I'm not certain if this is actually directly related to mesecons, or if I'm running into some problem that the ubuntu 12.04 engine has with certain mods.

I've got a complete debug file if you think it would be of use to you, but I can't attach it because I'm getting a message "Sorry, the board attachment quota has been reached." So I put it on mediafire: http://www.mediafire.com/download/lfy4xfgkaebhy51/debug-mesecons-newworld-crash.zip

Thank you for your time and effort. Mesecons looks amazing and I appreciate how much work has gone into it!

[VoidLord]

To the Dev. team, could you implement somthing where blocks are powered (fakely)? I mean something along the lines of when a mesecon is next to a block that belongs to a conductive group or something, then it checks the block's surroundings for a mesecon conductable and has the same power state when it sees it. So you would have something like

conductive block group declaration (just a list of blocks to check)

mesecon component function {
if (adjacent block check()==conductive block) then
if (adjacent block check()==mesecons component.check power) then
mesecons component.check power="on"
...
}

Please note that the power doesn't extend through multiple blocks. Also, can you implement an element such that when more than one mesecons component is connected each individual component doesn't register conductivity with the surroudings on it's own but instead make one fuction used to check the surrouding conductive zones of all the blocks? That is just my little idea to contribute to decrease processing time by calling less functions, although there would be an interrupt when a new block is added so that the function could add more zones to it's conductivity-zone-checking-cache.

So, in summary,
1. Fake block powering by node registry branching?
2. Decreased processing time by main governing function used on a large conductive array?

Consideration is very much appreciated, implementation fifty times more so.

[Jeija]

@Kilarin: I just tried your configuration in a Virtualbox and could reproduce your problem. But I can say for sure, that it is not a mesecons bug, but it is propably in the minetest build. It worked for me when compiling the latest minetest version from the source code, there seems to be something wrong with the version in the ppa. In order to build minetest, just follow the instructions here in the section "Compiling on GNU/Linux".

@VoidLord: Could you please explain what you mean with (1)? A specific use case of what you described might be helpful to understand. There propably is a way to implement these things without adding "fake" conductors.

As I understand (2) you propose to not use recursion for the turnon / turnoff functions that change the state of the conductors / effectors. Doing that would basically mean rewriting the whole of mesecons core. While that might speed up a finished circuit somewhat, it will require a lot more memory in the map (each mesecon node has to keep track of the conductive zone(s) it is in) and might slow things done in other cases (e.g. when you're diggig a mesecon that connects two large conductive zones together, it would require updating the meta of every single mesecon node in both zones).
So therefore, while it might benefit the performance in some cases, I think the disadvantages of that implementation outweigh the advantages.

[Kilarin]

I just tried your configuration in a Virtualbox and could reproduce your problem

THAT is good to hear. At least I'm not crazy. :)

It worked for me when compiling the latest minetest version from the source code

How interesting! I'll attempt to do a build sometime today.

Thank you VERY much for putting the time and effort into researching this!

[VoidLord]

1. Well, if a block belongs to a group (just a list of blocks affected, not an actual group) and the mesecon is next to it and the block is "powered" (to be explained later), then the mesecon will turn on. Blocks are "powered" by having a conductive node next to them (might be a mesecon or something special), and they are only treated as powered by other nearby mesecons/special conducting materials, so for example there is a dirt block placed between two mesecons. Now it obviously can't acctually be "on" without changing the item registry, but that's not important right now; currently both mesecons are off; they have no current applied to them. Now the firs mesecon is switched on, and because it is switched on the mesecon on the otherside of the dirt block is also switced on, so it appears that the mesecon is powing the block but the other mesecon just expanded it's search range because the dirt block is next to it and the dirt block is lised as a coductive block somewhere.
Initial State:

mesecon off---dirt block---mesecon off

Initial Powered State:

mesecon on---dirt block---mesecon off

Final Powered State:

mesecon on---dirt block---mesecon on

2. For the function I just meant that instead of having a function that checks whether a mesecon should be on or not for each mesecon, that instead there is one function for a bunch of mesecons stringed together that is used to check whether or not they should be on.
Initial State (CPU speed, reguar checking function):

mesecon off---mesecon off---mesecon off---mesecon off---mesecon off

Pulse Applied:
->
mesecon on---mesecon off---mesecon off---mesecon off---mesecon off

Pulse Traveling
->
mesecon off---mesecon on---mesecon off---mesecon off---mesecon off etc.

Initial State (CPU speed, alternate checking function):

mesecon off---mesecon off---mesecon off---mesecon off---mesecon off

Pulse Applied:

mesecon on---mesecon on---mesecon on---mesecon on---mesecon on

Immediately After Pulse:

mesecon off---mesecon off---mesecon off---mesecon off---mesecon off

Does my answer help you understand the fake block powering? And does what I just said make sense for large groups if interconnected mesecon nodes? All of the stuff that I'm talking about really has to do with altering the range/locations where block notice other blocks geting powered and change as a result.

[VoidLord]

Use the word rules from this website instead of range and you'll probably understand what I said better.
http://mesecons.net/developers.php

[Jeija]

1. OK, I get what you're suggesting. Actually the idea of having fake conductors is quite old and gets mentioned over and over again.
Actually, you don't need to make things that complicated. The easiest thing to do would be to simply redefine the "fake conductor" block with an onstate version and an offstate version (offstate would be the one that is already registered). There is no need for any more core functionality to be added as I see it.
Simply check out the code that makes the mese block conductive (https://github.com/Jeija/minetest-mod-m ... sewire.lua), it is just the same thing!

2. That kind of is how it works already?! Assuming you are powering off a switch that is connected to a long mesecons wire. The core will then first go along the wire and check if there are any other power sources connected. If none are found, the wire is turned off using a recursive function, not checking anymore for any connected blocks. The downside in speed of recursion is not that big of a deal as I see it here. If areas are unloaded, it will even save the "pulse" as you call it and try continuing it over and over again. Did I misunderstand something you said?

[VoidLord]

Uh, no. Thank you for the answers, they were very useful. I guess I just didn't want a multi-stage vertical wire worth more than a house :), so I guess I'll decide to make gold conductive later then, seeing as it currently has about the lowest intrinsic value in the game.

[Kilarin]

I just tried your configuration in a Virtualbox and could reproduce your problem. But I can say for sure, that it is not a mesecons bug, but it is propably in the minetest build. It worked for me when compiling the latest minetest version from the source code, there seems to be something wrong with the version in the ppa. In order to build minetest, just follow the instructions here in the section "Compiling on GNU/Linux".

Tried doing a build, and my build will work fine without mesecons (didn't test any other mods). BUT, when I add mesecons, It locks up and the following was in the terminal window:

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

14:18:04: ACTION[main]:         .__               __                   __
14:18:04: ACTION[main]:   _____ |__| ____   _____/  |_  ____   _______/  |_
14:18:04: ACTION[main]:  /     \|  |/    \_/ __ \   __\/ __ \ /  ___/\   __\
14:18:04: ACTION[main]: |  Y Y  \  |   |  \  ___/|  | \  ___/ \___ \  |  |
14:18:04: ACTION[main]: |__|_|  /__|___|  /\___  >__|  \___  >____  > |__|
14:18:04: ACTION[main]:       \/        \/     \/          \/     \/
14:18:04: ACTION[main]: World at [/home/dnl/minetestcompile/minetest-minetest-e7ef4f0/bin/../worlds/testmesecons]
14:18:04: ACTION[main]: Server for gameid="minetest" listening on 0.0.0.0:56440.
Unsupported texture format
X Error: BadAlloc (insufficient resources for operation)
From call : unknown
X Error: BadDrawable (invalid Pixmap or Window parameter)
From call : unknown
X Error: BadAlloc (insufficient resources for operation)
From call : unknown
X Error: BadDrawable (invalid Pixmap or Window parameter)
From call : unknown
X Error: BadAlloc (insufficient resources for operation)
From call : unknown
X Error: BadDrawable (invalid Pixmap or Window parameter)
From call : unknown

[Jeija]

That is just weird. Is there no way you could upgrade to a more modern version of xubuntu now that 14.04 came out recently? Otherwise, you might want to try asking the question in a seperate topic or in the minetest IRC as it isn't exactly connected to mesecons. Do you have some kind of RAM shortage on your machine?
It also worked for me with 12.04 in VirtualBox with all the updates applied, but of course wasn't playable as VirtualBox does not work well with capturing the mouse. Still, the mod loaded just fine.
Unfortunately, the debug output you provided isn't exactly meaningful to me. You might want to try running it with --verbose option and try minetest and minetestserver seperately.

[Kilarin]

Is there no way you could upgrade to a more modern version of xubuntu now that 14.04 came out recently?

I should I guess. I got angry when Ubuntu put in the unity amazon search lens in 12.10 and haven't upgraded since. But since I'm using xubuntu and not unity anyway, I probably should just get over it and upgrade.

Thank you VERY much for your help. Any further questions I'll take to the bugs forum.

[ZachyGames]

is there tutorials to make a door or something with this? i wanna make a mesecon door

[Jeija]

@ZachyGames: In order to get started with Mesecons, check out http://uberi.mesecons.net/projects/Mese ... index.html. You can make doors with pistons or by connected mesecon wire to a wooden door. For more advanced stuff, go to http://uberi.mesecons.net/ .
If you want to find out about certain blocks, check out http://mesecons.net/items.php .

[gsmanners]

You can also make doors out of ghoststones and pressure plates (my favorite).

[theoluk]

I am using a mac running qwook's minetest build for mac. I think it is the version equivalent of 0.4.7. I have installed the mesecons mod, but when I try to place anything from the mod, (mesecon, piston, etc...), it gives me an error message:

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

Contents/Resources/share/mods/minetest/mesecons/mesecons/wires.lua:210:attempt to call field 'get_node' (a nil value)

Could someone please explain what this means and what I could do to fix it?
Thank You

[Jeija]

Your minetest version is far too old to be supported by the current mesecons. Can't you use this one: viewtopic.php?f=3&t=9190 ?