Currently, this is only a concept I'm interested in. Since my knowledge of C is very limited, I would need help to do this, so this can only happen if I could get a volunteer. Ideally this would be a Prizm project, as I don't have any TI calculator to test on, but I'm willing to budge on this.
This program would allow you to create Redstone circuits out of various vanilla Minecraft components inside individual save files containing 512•512•256 block 'worlds'.
The editor would allow you to place redstone components, tile entities, a few types of entities, edit tile entity contents, among other things. The view would be of a single 2D layer at a time, to avoid rendering fiascos.
After saving from the editor, you would be able to run the simulator, which would allow you to move a "Player(Self)" entity around the circuitry, to flip levers, hit buttons, trigger proximity sensors, or just simply observe the circuitry simulation.
In addition to these two features, the program could possibly include an exporter/importer. The exporter would convert a save file into an MCEdit-compatible .schematic file, which could be put on a computer and pasted into a PC world with MCEdit. The importer would reverse this process, but might possibly be harder to code.
Things not simulated in the simulator would include fire spread, explosions, and other things that would quickly become RAM-intensive.
I'm posting to ask if such a project seems plausible, and if so, whether or not somebody would like volunteer to help me?
I think what you really need to do first is find out how much RAM each red stone component takes. Perhaps starting a flat world and adding in a simple circuit while monitoring your RAM usage could give you an idea; let the base be when you are in the world with no red stone and take notes in MC's RAM usage has you add and activate circuits.
I don't know any programming to help you on this, but I can certainly try it as you build it.
comicIDIOT wrote:
I think what you really need to do first is find out how much RAM each red stone component takes. Perhaps starting a flat world and adding in a simple circuit while monitoring your RAM usage could give you an idea; let the base be when you are in the world with no red stone and take notes in MC's RAM usage has you add and activate circuits.
I don't know any programming to help you on this, but I can certainly try it as you build it.
The issue with testing the actual RAM usage in Minecraft is that Minecraft simulates a whole lot more, like lighting, even with a simple circuit. For the purposes of this program, near-irrelevant things like that would be ignored.
The entire simulation would be carried out in a form similar to Minecraft's block updates. If a lever in the simulation is flicked, it updates the lever, then the block that the lever is connected to, then that block updates all surrounding blocks, which if one of them is a redstone wire, then it would become powered, then update more redstone wires as it follows the circuit
There's no reason for the program to be as fast as real Minecraft, just that it maintains an accurate scale of time. If it's easy to lag the program through enough block updates in a single 'tick', then solutions could be derived.
Noted, but if you keep track of the RAM/CPU usage of Minecraft on a flat world then build your circuit and track the RAM/CPU again over the same 20 minutes, you should be able to figure out how much more usage the circuit is requiring.
comic, please note that Java is terribly bloated im this case to get an accurate RAM usage for the map. I suggest to find out what data is needed. If you do something 2D only using an anvil-like format (minimalized to support only the bare essentials),then you will start to have an idea of what is required memory-wise. If chunks are properly stored and loaded/unloaded, then I can see this on the prizm.
I know some C, and I have a TI-Nspire and a TI-84 keypad for it. I might be able to help.
Well, for what needs and doesn't need to be simulated, I've compiled a fairly general list.
Things that need to be simulated include:
-Redstone interactions(Powering blocks, other redstone components, etc.)
-Tile entity interactions(Such as hoppers removing from or placing items into something else)
-Entity motion and collision(Mainly for item entities, minecart entities, and the like, for canal systems and whatnot. Instead of an actual complicated collision map, depending on the general shape and placement of a block, assumptions can be made taking entity dimensions into account.)
-Tile Entity functions(Furnaces need to smelt, brewing stands need to brew, to allow for testing of those in automated systems using hoppers or the like)
-Mechanism functions(Pistons need to extend, droppers need to drop item entities, doors need to open/close)
-Fluid Flow(This is one thing that could consume a lot of RAM. A way to circumvent this somewhat easily would be to calculate the flow when a fluid block is placed in the editor, rather than in the simulation, and schedule its flow for the simulation. This would need to identify moving blocks for alternate paths though. An alternative would be to calculate every possible permutation of each of the 8 fluid levels throughout the entire circuit when you save it, this would be time consuming but would save a lot of memory)
-Minecart interactions(Such as minecart coupling, movement, etc.)
-Time(At least, in terms of ticks. The actual time of day used in a circuit simulation would probably be a single attribute set per save, and not change unless you manually edit the attribute)
-Plant growth(To a degree, most types of plants aren't necessary, most likely included would be melon/pumpkin, vine, sugar cane growth, which all use the same clock)
-Player control(Not sure if this'd be called simulation, in simulations, you'd be given the option to control a 'player' and move around and interact with redstone components like tripwires, levers, or pressure plates; and fluids.
However, things that would not be simulated:
-Fire Spread(Fire would still be placeable for some purposes, but spread is nearly irrelevant)
-Explosions(Again, fairly irrelevant, for this reason TNT would not be included in the simulator)
-Mob Spawning(While actually relevant, would be a memory consumer, you should be able to make assumptions about where mobs can spawn and place a dummy entity to test a system)
-Commands(Some commands would be relevant, but there would be too many irrelevant commands to justify simulating command blocks)
-Decay(This excludes entity decay, but things like ice melting, leaf block decay, etc. aren't all that necessary)
-Projectiles(This is iffy, but from what I can tell, simulating projectiles wouldn't be relevant enough to justify the difficulty in coding and simulating efficiently, the projectile function of dispensers would be ignored)
-Portals(Although used in some circuits, portals would require simulation of multiple dimensions, which isn't all that worth it)
-Weather
-Mob behavior(For the most part, it may be possible to have something like a Dummy(Livestock) entity that moves around randomly only if a player is within 32 blocks, like regular Minecraft)
-Light(Very irrelevant and memory consuming)
-Most entity-specific features, excluding inventory for Player and Dummy(Player) entities
-Other things that shouldn't need to be mentioned
I cannot program in C because I don't know how, plus I prefer on-calc programming, instead of programming code on a pc, converting it then sending it to my calc. I know a bit of ICE and a lot about Basic. I program the TI 84 Plus CE.
I am already started working on a redstone simulator in ice, but I do not have screenshots or any releases. I plan to have a 10*10 world. First I will add redstone dust, redstone torch, and a lamp to simulate redstone circuitry. Then I will release it as an alpha preview. But it will not have saving or loading yet, and first I will have individual variables containing block IDs, like BLOCKAA, BLOCKAB, BLOCKAC...BLOCKHI,BLOCKJJ. First letter after BLOCK is the row, next letter is the column.
This thread was last posted in in 2013, and this project isn't even for the same graphing calculator, so I doubt that your new information is in any way relevant. If you are just posting here because you have the same idea, please create or use a newer thread.
Also, using variable names like that is strongly discouraged in basically every programming language, please just use lists.