In fact, if I can work out how to do it, the Forge Mod will change to use a special stick as the wand, so that it does not need the client-side mod, but that's another issue.
Statistics: Posted by stevesh — Fri Mar 11, 2016 3:56 pm
]]>
The idea I had previously about how to do this was to have a per-plan option of 'static'. In this case, the random seed for the plan would be saved, and if it was called again then the same seed would be re-used. This would mean that you could (eg) have a plan that plants a random banner; but call this plan multiple times from within a parent plan, and always get the same banner as the randomisation would only be done the first time.
Doing it this way would mean not having to deal with the complexity of rlative vs absolute coordinates, which are mae even more complex when you realise that our frame of reference is also being rotated - so we don't even know which direction is our X-axis any more.
Statistics: Posted by stevesh — Fri Mar 11, 2016 3:54 pm
]]>
the idea is when you use fill in vanilla MC then ~ signifies relative coordinates (when placed before a coordinate). In your mod it might be otherwise around and that is if I use ~ I would refer to the absolute coordinates. The use case I'm imagining is:
- randomly generate a block at absolute ~0,~0,~0 at the start of blueprint (it's on the edge so I suppose there is nothing to worry about).
- when building for example the 3x3 house then ask in every _stonebrick_mossy what is that block at ~0,~0,~0 ? when cobblestone use cobblestone, when wood use wood etc.
It might contribute to the randomisation.
Thanks for your hard work,
Howlington
Statistics: Posted by howlington — Sun Jan 24, 2016 4:31 am
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
In particular, it doesnt work for CLONE, TESTFORBLOCKS, some EXECUTE and custom commands. It also fails in odd cases where the X coordinate is relative and the Z is absolute...
However, it does work for the example cfg you posted above.
I have this in the 2.7 beta for MC1.8 at the moment. I'd let you have a copy but I think you use MC1.7.10, am I right?
Statistics: Posted by stevesh — Sat Oct 03, 2015 6:40 pm
]]>
Solution tested and working in v2.7beta1 for minecraft 1.8 (still need to port to 1.7 branch)
Also fixed the problem of armour stands in 1.8 not rotating correctly.
2.7 will be released 'soon' -- IE once I've ported the changes to the 1.7.10 branch and packkaged it all up.
Statistics: Posted by stevesh — Sat Oct 03, 2015 4:31 pm
]]>
Yes, currently very little of the metadata in a Tile Entity is modified by rotation.
In v2.7, the rotation of Mobs (including minecarts and armour stands) is preserved and rotated, as is any entity with a 'Pos' and 'Rotation' attribute.
There is also a new provision (initially made for Carpenters Blocks addin) that allows you to (in the config file) specify a tile entity type, and a corresponding attribute and its rotation states. This is intended to handle custom blocks that hold their rotation in their tile entity. A separate rule allows you to define rotation states for custom blocks that hold their rotation state in their DV as with normal blocks.
The problem here is that command blocks have just a large text Command attribute, which would need to be parsed, any relative coordinates identified and modified and then a new command string generated. This would not be a simple procedure. This is made even more complex by rotations -- so "~3 0 ~" would rotate a quarter-turn to become "~ 0 ~-3" and it would be even more complex if you had something like "~2 0 0", not to mention for commands with multiple coordinate sets.
Commands to be affected would include blockdata, execute, fill, clone, particle, setitem, setblock, spawn, spawnpoint, stats, summon, testforblock, testforblocks, tp; I can see how many of these would be in common usage in many adventure structures and would need to rotate properly
I can see a way to eventually achieve it, but I hate writing string parsing in Java - I've been spolit by the easy functions in Perl...
Statistics: Posted by stevesh — Fri Oct 02, 2015 11:41 am
]]>
this will be peculiar. When you copy a plan which contains command blocks and those commands place blocks relatively to the command block position with tilde ~ those relative coordinates are not rotated. I have included an example. (There is a button missing on one of the cobblestones on ground level to activate the command chain). When you place the example facing positive Z everything is fine. When you place it facing any other direction it messes up.
Thanks for your hard work.
tmp.cfg
Statistics: Posted by howlington — Thu Oct 01, 2015 11:27 am
]]>