@SFC-Daniel

Thats what is so great about macrochip, try to put as much of the wiring inside the virtual breadboard as you possibly can.
even if you have to use more than 1 macrochip with wireless remote nodes to join up your circuits, I see you wanted 72 direct I/O ports,
remember Remote Nodes are unlimited.
I have a lighting system with 108 remote outputs for 18+ tintable lgihts for such things as Art Galleries, Club lights all with 24 different lighting modes using a self made JK Flipflop Switch-Selectable 6x4 - 24 bit Synchronous up counter, with on/off, Timed Auto Run, Manual Toggle, or set a specific Light Mode. all from 1 MiniMacroChip. only wireing seen from outside is RemoteNodes right next to the lgihts & buttons.

Nice work :D And yes already on my way to the remote world^^ Was probably to fixated on SBs way to wire things and happy to put everything insede chips without thinking too much about remote connections. I can also see wire length limitation problems as i increase elevator levels, as well as building issues.
I hope the wire length reduction will help. Thanks for the heads up^^

The Remote chips are indeed powerful and most versatile, because once you run into some interface lag with one Remote Macrochip (making it harder and harder to hit inputs/outputs with the mouse) or the wiring gets too complex, you can always just line out some wires and process them in another Remote Macrochip.
Like wiring to remote outputs, which are connected to remote inputs going into the next Remote Macrochip, leaving you with a nice range bridge as a bonus (250+250 tiles).
Building your Ele-Control modulary you could just copy the extension module for a virtually endless elevator. It's mostly a matter of indexing the input and output nodes then and with that the range limit could even help.

There is now No Range Limit for Chips/Remote Nodes, will stay Active if your the other side of the planet.

New Virtual Switch Art.

There are a few bugs:
1: Remote Inputs on the breadboard can be placed but not moved, so delete and place another one or will cause black screen. All other I/O seem to function correctly.

2:Buffer Gate Output may sometimes cause a black screen when deleteing the wire.
again just delete the buffer and place a new one. unaware if other logics do the same.
May have been my own error

Happy wiring.

Well, with the removed range limit, strange things may happen, if you called the remote nodes on the other side of a planet the same as on this side because you simply used a copy of your control circuit for a similar wiring.
That's just a matter of renaming/re-indexing the nodes though and categories will help to keep track of that. Speaking of that, it would be nice maybe to be able to restrain a remote macrochip (the control unit) to a certain category to avoid accidental naming conflicts (or is that a thing already?)

That is a thing already via the Remote Nodes not the Virtual MacroChip.
Name: Switch1
Category: Controll

Plus you have Multi-Node & Single Node I/O via the Virtual MacroChip.
http://s64.photobucket.com/user/pitbull6669er/media/Stuff/Working%20Breadboard..jpg.html

to big for pastebin, remote sensor don't work again suddenly, tried to access one and:

[21:01:50.170] [Error] Could not load image asset '/objects/wired/chips/megamacrochip/megamacrochip.png:default.1', using placeholder default.
(AssetException) No such frame default.1 in frames spec /objects/wired/chips/megamacrochip/megamacrochip.frames
[21:01:50.179] [Error] Could not load image asset '/objects/wired/chips/megamacrochip/megamacrochiplit.png:default', using placeholder default.
(AssetException) No such frame default in frames spec /objects/wired/chips/megamacrochip/megamacrochiplit.frames
[21:02:52.489] [Error] Exception caught in client main-loop
(JsonException) Cannot call get with key on Json type array, must be Object type
[0] 13f894403 Star::captureStack
[1] 13f89318e Star::StarException::StarException
[2] 13f82d2da Star::JsonException::format<Star::String>
[3] 13f838732 Star::Json::ptr
[4] 13f8356c1 Star::Json::get
[5] 140083610 Star::ScriptConsole::ScriptConsole
[6] 14003b1e1 std::_Ref_count_obj<Star::ScriptConsole>::_Ref_count_obj<Star::ScriptConsole><std::shared_ptr<Star::UniverseClient> & __ptr64,int & __ptr64,Star::Json & __ptr64>
[7] 140040a9b std::make_shared<Star::ScriptConsole,std::shared_ptr<Star::UniverseClient> & __ptr64,int & __ptr64,Star::Json & __p


stack traceback:
[C]: in ?
[C]: in field 'loadUniqueEntity'
[string "/objects/wired/remoteoutput/remoteoutput.lua"]:65: in global 'introduce'
[string "/objects/wired/remoteoutput/remoteoutput.lua"]:47: in function <[string "/objects/wired/remoteoutput/remoteoutput.lua"]:3>

World had unsanely slow fps last session then i reloaded now iam on my flying ship.. seems the whole planet has blown up. help in sight?

Are you using the most recent update ?

ok i see the problems:

Looks like Storms taking the night off though.

I see. I haven't made big use of the categor< tag yet, but I recognized the potential of it immediately when categories were introduced. amazing mod that!

No idea how the megamacrochip changed but fixed.

Ok ship stopped and i could choose a beaming deistination, and chose my home planet, then i beamed until my ram was fully used(12gb) then i had to end SB with an excerpt of the log:

[16:36:49.690] [Info] UniverseServer: Warping player 1 to ClientShipWorld:dfce65e366d4c4fea8f73f4f516fcc2a=964.75.1042.75
[16:37:54.350] [Info] UniverseServer: Loading celestial world 61740983:-991300670:-257301254:9
[16:37:55.910] [Info] UniverseServer: Warping player 1 to CelestialWorld:61740983:-991300670:-257301254:9=0bfcfcf2075b385545d784cb0eac10dd
[16:37:56.760] [Info] Client received world stop packet, leaving: Removed
[16:37:57.857] [Info] MChip2715,732
[16:37:57.872] [Info] MChip2718,710
[16:48:34.233] [Info] Root: Writing runtime configuration to '..\storage\starbound.config'
[17:04:59.298] [Error] Exception while calling script init: (LuaInstructionLimitReached)
[0] 13fd84403 Star::captureStack
[1] 13fd8318e Star::StarException::StarException
[2] 13fd578cd Star::LuaEngine::handleError
[3] 13ff2683d Star::LuaEngine::callFunction<>
[4] 13ff29ee1 Star::LuaFunction::invoke<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> >
[5] 14036f413 Star::LuaContext::invokePath<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> >
[6] 140370e57 Star::LuaBaseComponent::init
[7] 13fffb4be Star::Object::init
[8] 14027188a Star::WorldGenerator::initEntity
[9] 1402ee94c Star::WorldStorage::loadSectorToLevel
[10] 1402ee1a3 Star::WorldStorage::loadSector
[11] 1402eec26 Star::WorldStorage::loadUniqueEntity
[12] 1403ec5c3 <lambda_1844ddae174ee01f3038da91ef881d2f>::operator()
[13] 1403c02bf std::_Invoker_functor::_Call<<lambda_1844ddae174ee01f3038da91ef881d2f> & __ptr64,Star::LuaEngine & __ptr64,unsigned __int64,Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> * __ptr64>
[14] 1403d5660 std::invoke<<lambda_1844ddae174ee01f3038da91ef881d2f> & __ptr64,Star::LuaEngine & __ptr64,unsigned __int64,Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> * __ptr64>
[15] 1403c7ba9 std::_Invoke_ret<Star::Variant<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData>,Star::LuaVariadic<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> > >,<lambda_1844ddae174ee01f3038da91ef881d2f> & __ptr64,Star::LuaEngine & __ptr64,unsigned __int64,Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> * __ptr64>
[16] 1403f8b8b std::_Func_impl<<lambda_1844ddae174ee01f3038da91ef881d2f>,std::allocator<int>,Star::Variant<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData>,Star::LuaVariadic<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> > >,Star::LuaEngine & __ptr64,unsigned __int64,Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> * __ptr64>::_Do_call
[17] 13fd51e8d std::_Func_class<Star::Variant<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData>,Star::LuaVariadic<Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> > >,Star::LuaEngine & __ptr64,unsigned __int64,Star::Variant<Star::Empty,bool,__int64,double,Star::String,Star::LuaTable,Star::LuaFunction,Star::LuaThread,Star::LuaUserData> * __ptr64>::operator()
[18] 13fd50f24 <lambda_a03bcae4599b53751a446949639a4d5e>::operator()
[19] 13fcdb6a8 luaD_precall
[20] 13fcf4451 luaV_execute
[21] 13fcdb1b3 luaD_call
[22] 13fcdb98b luaD_rawrunprotected
[23] 13fcdb3c0 luaD_pcall
[24] 13fcd18d4 lua_pcallk

repeats with the same data from line 0-24 i think 100 times +

Not sure what time Storms back but i think you might need to delete your world files
ive not installed the current Version of Wip.

ill grab it now and check it out.

hmm not sure whats causing that... maybe a loop of some kind thats not being escaped. Seems linked to world uniqueId's though which suggests the chips/remotes are involved somewhere. :(