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

UOAbigail
Member
 
Posts: 19
Joined: Mon Feb 24, 2014 13:07

by UOAbigail » Fri Mar 07, 2014 19:45

sfan5 wrote:Furnaces unfortanely have this bug, actually pistons should never move furnaces or chests anyway.
To get your map to work again you should try updating to 0.4.9 stable, the problem seems to fixed there.
(It may also be sufficent to just use a recent minetest_game from https://github.com/minetest/minetest_game)


Greetings ;)

If the above does not work for you and the map still crashes upon loading, it should work if you disable mesecons long enough to destroy the now 'unknown node' that was the piston.

Then you can reload the map after re-enabling mesecons.

Peace
UOAbigail
 

User avatar
Jeija
Member
 
Posts: 686
Joined: Fri Dec 23, 2011 21:46
Location: Nürtingen, Germany

by Jeija » Wed Mar 19, 2014 21:12

Unfortunately, the current promotional YouTube Video (https://www.youtube.com/watch?v=6kmeQj6iW5k) is so horribly out of date (it was actually made before mesecons were first published) that people will rather decide not to install mesecons, because it seems quite limited.

We need a new video

I would definitely like to feature some of your ideas and projects in this video, so I encourage you to send in your creations as a video (preferably) or as a map (if you're unable to record yourself).
Just post a link to it here, on the GitHub issue or send an email to me. I will collect them all and cut together a short video (collaboratively, if someone decides to join in).
You may also just note down your idea for a single scene or the concept of the whole video.
A native English speaker who could comment on the video would also be nice, but not necessary.

Your shots should meet the following requirements:

  • 1080p or more, shows minetest in fullscreen (I recommend glc)
  • 30 fps or more (unless it is supposed to become a timelapse)
  • Features either a single mesecons item or a machine
  • May also contain digilines or another mod (please write which one it is)
  • May contain ingame sounds, though not necessary
  • Also allowed are projects like the mesecons <--> real life interface (https://www.youtube.com/watch?v=jo_GT6a4M90) or similar ideas
  • May either be showcase-like (like the old video) or explanatory (tutorial-like, e.g. explain the concept of gates, luacontroller)

Please send them in until Saturday, 12th April 2014, the Video will then hopefully be ready on the 20th April 2014.
Last edited by Jeija on Thu Mar 20, 2014 07:44, edited 1 time in total.
Redstone for minetest: Mesecons (mesecons.net)
 

Iqualfragile
Member
 
Posts: 160
Joined: Tue Sep 18, 2012 22:11

by Iqualfragile » Thu Mar 20, 2014 01:19

There is a nice machine on my server, which automatically farms, crafts and sorts items, but its a bit more pipeworks then mesecon, maybe you could take a look at it and tell me if it would still qualify?
Gr8 b8, m8. I rel8, str8 appreci8, and congratul8. I r8 this b8 an 8/8. Plz no h8, I'm str8 ir8. Cr8 more, can't w8. We should convers8, I won't ber8, my number is 8888888, ask for N8. No calls l8 or out of st8. If on a d8, ask K8 to loc8. Even with a full pl8, I always have time to communic8 so don't hesit8.
 

User avatar
Jeija
Member
 
Posts: 686
Joined: Fri Dec 23, 2011 21:46
Location: Nürtingen, Germany

by Jeija » Thu Mar 20, 2014 06:42

It will most likely qualify, but in a section at the end of the video where we show compatibility with other mods like digilines, pipeworks, ...
What's your server's Address / Port?
Redstone for minetest: Mesecons (mesecons.net)
 

Nore
Developer
 
Posts: 501
Joined: Wed Nov 28, 2012 11:35
GitHub: Ekdohibs

by Nore » Thu Mar 20, 2014 19:06

Several contraptions here: a game of life machine, and a new multiplier (multiplies numbers up to 255)... However, I can't do videos, so I will post the world here.
Attachments
game_of_life.zip
(7.77 MiB) Downloaded 50 times
 

User avatar
rubberduck
Member
 
Posts: 498
Joined: Thu Feb 27, 2014 19:19
Location: error 404 - location not found
IRC: rbduck
In-game: rubberduck or zombee

by rubberduck » Fri Mar 21, 2014 21:27

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.
Image

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)
My game (not minetest): http://forum.freegamedev.net/viewtopic.php?f=22&t=6800

my mods: gold_and_gem, meseconductors

a penguin throws an apple through a window

sometimes i change my "forum location" via user control panel
 

4aiman
Member
 
Posts: 1208
Joined: Mon Jul 30, 2012 05:47

by 4aiman » Sat Mar 22, 2014 11:33

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
Member
 
Posts: 194
Joined: Sat Jun 29, 2013 04:20

by hampa16 » Sun Mar 23, 2014 23:12

Jeija wrote: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".
Rex 2 Double 9
=RomanFox2=
SoulKiller35
 

Temperest
Member
 
Posts: 651
Joined: Tue Nov 15, 2011 23:13
GitHub: Uberi

by Temperest » Mon Mar 24, 2014 00:29

hampa16 wrote:...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.
WorldEdit 1.0 released

The Mesecons Laboratory - the art of Mesecons circuitry
Latest article: Mesecons Basics.
 

Kilarin
Member
 
Posts: 778
Joined: Mon Mar 10, 2014 00:36

by Kilarin » Thu Apr 10, 2014 20:06

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:

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:
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:

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:

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:
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:
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
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
Member
 
Posts: 33
Joined: Sat Sep 14, 2013 00:00

by IthegeekRS » Fri Apr 18, 2014 14:17

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
 

User avatar
Inocudom
Member
 
Posts: 3080
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

by Inocudom » Fri Apr 18, 2014 20:16

Is this mod even worked on anymore? Ever since Jeija stopped working on it, it seemed to be quiet.
You can now find my videos at BitChute: https://www.bitchute.com/channel/some_cheeky_jinuskian/
 

User avatar
Neon
Member
 
Posts: 126
Joined: Thu Aug 15, 2013 02:03
In-game: Neon

by Neon » Sat Apr 19, 2014 01:34

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

User avatar
sfan5
Moderator
 
Posts: 3829
Joined: Wed Aug 24, 2011 09:44
Location: Germany
GitHub: sfan5
IRC: sfan5

by sfan5 » Sat Apr 19, 2014 06:14

Inocudom wrote:Is this mod even worked on anymore?

Yes, but not much.
Mods: Mesecons | WorldEdit | Nuke & Minetest builds for Windows (32-bit & 64-bit)
 

Temperest
Member
 
Posts: 651
Joined: Tue Nov 15, 2011 23:13
GitHub: Uberi

Re:

by Temperest » Sun Apr 20, 2014 03:04

Neon wrote: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!
 

User avatar
Jeija
Member
 
Posts: 686
Joined: Fri Dec 23, 2011 21:46
Location: Nürtingen, Germany

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Jeija » Sun Apr 20, 2014 10:21

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.
 

User avatar
Linxx
Member
 
Posts: 406
Joined: Wed May 16, 2012 00:37

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Linxx » Sun Apr 20, 2014 13:28

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
Member
 
Posts: 778
Joined: Mon Mar 10, 2014 00:36

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Kilarin » Sun Apr 20, 2014 14:06

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

User avatar
Jeija
Member
 
Posts: 686
Joined: Fri Dec 23, 2011 21:46
Location: Nürtingen, Germany

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Jeija » Sun Apr 20, 2014 14:12

@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
Member
 
Posts: 778
Joined: Mon Mar 10, 2014 00:36

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Kilarin » Sun Apr 20, 2014 14:41

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!
 

User avatar
VoidLord
Member
 
Posts: 46
Joined: Sun Jan 20, 2013 16:07
Location: SPACE! WHAT!?

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by VoidLord » Sun Apr 20, 2014 22:55

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.
 

User avatar
Jeija
Member
 
Posts: 686
Joined: Fri Dec 23, 2011 21:46
Location: Nürtingen, Germany

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Jeija » Mon Apr 21, 2014 08:26

@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
Member
 
Posts: 778
Joined: Mon Mar 10, 2014 00:36

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by Kilarin » Mon Apr 21, 2014 13:36

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

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

Jeija wrote: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!
 

User avatar
VoidLord
Member
 
Posts: 46
Joined: Sun Jan 20, 2013 16:07
Location: SPACE! WHAT!?

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by VoidLord » Mon Apr 21, 2014 20:16

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.
 

User avatar
VoidLord
Member
 
Posts: 46
Joined: Sun Jan 20, 2013 16:07
Location: SPACE! WHAT!?

Re: [Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesec

by VoidLord » Mon Apr 21, 2014 20:20

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

PreviousNext

Return to Mod Releases



Who is online

Users browsing this forum: No registered users and 7 guests