Introducing /autoprogram

[mort96]

Hi! I've added a command to OREUtils called /autoprogram. The purpose of the command is to let you programmatically create instructions for how to program a CPU's program memory.

Update: I just made some changes to the command and associated file format. The video which was linked here is thus wrong, and was removed. I will create a new video explaining the updated format soon.

[LordDecapo]

I love this... loves this so much.

[AFtExploision]

Truly a perfect solution

[Xray_Doc]

Thanks mister

[tokumei]

Why does no one delete the flippin' spam? Especially when it's two pages long.

[Magic :^)]

maybe i missed it in the video, but how do you/autoprogram know what orientation the data will be in when pasted? e.g. will it go north south east or west?

[Apuly]

I'm guessing it's based on your orientation.

[Magic :^)]

cool beans, I'm definitely parsing my programs into this .prog format in the near future ^^

[Promethean]

Does it handle three-dimensional arrays if the .prog has both ; and | characters? Because if so, it looks to me like an alternative to //schem load in many cases (with the advantages of knowing which air blocks erase existing blocks and which ones don't, and being already defined for block IDs above 255). Also, can it set the 4-bit block-data field? (I'm experimenting with fence gates as a storage medium.)

[Apuly]

Looking at the video, it can handle 3 dimension, it just wasn't demonstrated in the video, so you can use it as an alternative to //schem load. I just don't think it's a good alternative, because the importing and exporting of files would be a pain in dah bum.

Frankly, I am not sure if it supports block-data. Personally I think that the additional data is added based on your orientation.

[Magic :^)]

The orientation part does have an advantage over schematics though. Also i think this is a much easier format to understand than a .schem file

[Phase]

I'd love to see this evolve into a schem loader.

[mort96]

I just made some changes to this command and the associated format. Backwards compatibility was broken, but the format is now way more versatile; you can assign metadata to blocks, you can rotate torches and other rotatable blocks relative to the player's rotation, and the format is just generally more flexible. I'll create a new video soon to explain the changes.

[LordDecapo]

Yayayayayayayayyaayayyayayayaya. Thanks u mort!!

[Magic :^)]

^ what lord said

[Magic :^)]

Do you have a list of the autoprogram syntax stuffs?
I wanna make a binary -> autoprogram template thing.
I can make do without the syntax for now, but it would be nice to have it in case I make the wrong assumptions on how autoprogram handles the data. I'd also like to make sure that none of the templating syntax clashes :3

Also: any intention on making it compatible with 1.8? and/or could you link the source?

[Chibill]

I am going to work on it for 1.8 Magic.

[Magic :^)]

could you give me the syntax or source code so I can work around the format? I don't want to have to use escape characters xD

EDIT: from the yt video it looks like autoprogram doesn't use bracket characters, so I'll use those.
() {} []

be graaand like

[Magazorb]

Hey mort, why not invest in some version control, it will let people maintain work on older versions even when you get newer versions rather then forcing them to restart if theirs a filesystem change.

[Magic :^)]

ahhhhhhhhhhhh

I looked at the yt video again, and it looks like that there is no support for vertically oriented words, and the ; and | type operators only go in one direction...

chi if you're adapting this, could you look into making it easier to navigate?

(I'm still making the templater either way though, I'm making good progress with the recursive parsing ^^)

[Chibill]

I could try... I might not even be able to get it working...

[Magic :^)]

I could try... I might not even be able to get it working...

I could look at it too if you could link the source

I dunno how much help I'd be though, as I'm not big into Java..

EDIT:
You can make autoprogram a lot simpler if you want. My template parser can be heavily scripted so all you need to do is allow 1 block movement in 3 dimensions.
With that done, the programmer can use their own template for navigating bit widths and placing blocks etc.

The biggest requirement after that would be some kind of rotation support, or at least a way to declare custom block metadata so the rotation could be hardcoded. I could implement the rotation from my side via a command line argument before converting to autoprogram if need be.

[Magic :^)]

I've done did the thingay btw:
http://forum.openredstone.org/showthread...&pid=35738

[Magic :^)]

My conversion program is pretty close to perfect now, I'm just dawdling about adding more non-essential features on a whim.

I wanna get some good documentation done with examples of autoprog templates and output but....

I have no idea where to find a decent explanation of how to use the autoprog format xD
I've pieced together the general syntax from the source code and that one youtube video, but I'd like some clarification on:
- how blocks are placed relative to your position
- how blocks are rotated relative to your position (and the limitations if any)
- how to define custom blocks and metadata for said blocks

also, there is no operator in the source code to do x -= 1
that's kinda important?