I had used my own, limited converter here. I extracted each text component, replaced \" with ", put it through the converter, and then replaced " back with \". It's not perfectly reliable though, especially when any quotation marks are being used as a value instead of delimiter.
The following bit of code worked in 1.8, but is broken in 1.9 due to the JSON interpretation rules. I've tried a few converter tools, but haven't had enough luck. Additionally, all player names have been converted to hidden players by using the # symbol. Any help would be appreciated:
Thank You!! Does that make all item frames in loaded chunks invulnerable? If so how do I set a radius?
This will affect all currently loaded item frames. To undo this, simply replace the 1 with a 0. To set only frames within a specific radius, use this command:
Please tell me how you made items stay in item frames and unable to take the items from item frames?
Using command blocks, you can use the /entitydata command to set the "invulnerable" tag for frames to true. Once you have the frames in place, use the following command:
i'm stuck at the begining to where i can move around how do i fix this
This seems to be a recurring issue associated with hopper clocks. Some people have been able to redownload the map to fix this problem, but if the issue persists, you should probably try a different adventure. Sorry for the inconvenience!
1. There may be some overlap for targeting if the radii intersect. In that case, it could count some mobs multiple times. To avoid that the armor stands would have to not have their search radius intersect one another. Going by the image I imagine it'll be an armor stand per section on an island/per island, so that should work just fine.
2. This is tough to measure since it's very dependent on the spawner's settings. Creating a generic spawn with a tick delay of 0 with a SpawnRange of 200 causes the spawner to take a long time between each spawn, though no other server-side lag is present. Reducing the SpawnRange speeds it up. Testing with an armor stand shows no delay in detection nor any server-side pressure.
It sounds like the armor stand method is fairly safe, which is good. I'll try the mob spawner first and see how it goes.
1) Would there be any problem naming multiple armorstands SpawnGroupX where X=1,...,8 and each group is comprised of roughly 10 armorstands (corresponding to possible spawn locations)?
2) Would this system, executed every 30 seconds-ish, be significantly less load-heavy than mob spawners with large (~200) radii in a redstone heavy adventure map environment? Or would mob spawners be a fine solution?
As a follow up, could you write a command that sets the scoreboard objective nearMobs to the number of mobs within radius r of an armorstand? That would be helpful.
1. get X amount of armor stands named "Spawn" ( use /summon ArmorStand ~ ~ ~ {CustomName:Spawn,Invisible:1} )
2. run a command of "/spreadplayers" with "@e[type=ArmorStand,name=Spawn]" with appropriate diameter and stuff for your area
3. run an execute command to summon the mob you want ( /execute @e[type=ArmorStand,name=Spawn] ~ ~ ~ summon Zombie ~ ~ ~ )
4. repeat step 2-3 everytime you want to spawn mobs ( set it up on a timer with about 20 full-tick repeaters )
Have fun, hope this helps.
That's not bad! I may use that unless something more elegant rears its head. The issue of checking for mobs remains, but a simple /testfor is probably the best that can be done.
The spawning is for a medium scale adventure map based on floating islands which can be mined by players, so the solution needs to be simple and computationally inexpensive. Here is a sample picture:
What is an efficient (low game load) way to continuously summon custom mobs into specific areas (~100 in radius)?
The ways I can think of are:
- Use a mob spawner with a large radius, but this may cause some lag
- Summon mobs at specific preselected points, but this needs to check for the number of mobs in the area first, which may be computationally expensive
- Summon items at the player's location which fly 'randomly', then after a designated interval, check whether there are few enough mobs and the spawn point is valid (ie, on a solid block). However, this seems doable but complicated.
The detect/testforblock will target a specific Y value instead of relative, so the player can be anywhere between 0 and 255. That leaves the issue of the floor: would barriers work? Invisible blocks, yet the player will still fall onto them.
Another block option (which may change in the future) is piston_extension. They are invisible and players can fall through them, but are still detectable. Removing them will require a /setblock command.
Hydrox from reddit came up with an elegant solution: teleport an armorstand to y=0 under the player and check its position with the radius argument. I think that will be best, just because I'm a little wary of the technical blocks.
This unfortunately won't work for my uses for two reasons (neither of which were specified before). First, the player will be able to access the entire y-axis in this cylinder; they will not be restricted to the ground. Second, there can be no floor. This is due to the map being centered around floating islands.
I used a circle generator website and set the diameter to 501. The furthest-out-line-thingy was 31 blocks. (The outermost straightline before the circle starts to curve in) If you do 8 commands then you could cover 248 blocks vertically. 9 commands would cover 279. I think it would work unless it breaks some command radius limit.
The cylinder should be 501 in diameter (a 250 block radius) and stretch from floor to ceiling (y=0 to y=255). It's a large area, so the patchwork method you described would probably require 25-255 /testfor commands if arrayed vertically to give a good approximation of the cylinder, so this is not quite feasible. I'm looking for a solution which requires at most 10 commands, and even that is a lot.
0
0
Thanks so much; it worked perfectly!
0
The following bit of code worked in 1.8, but is broken in 1.9 due to the JSON interpretation rules. I've tried a few converter tools, but haven't had enough luck. Additionally, all player names have been converted to hidden players by using the # symbol. Any help would be appreciated:
blockdata -13 96 -34 {Text1:"{text:\"Best Time\",underlined:true}",Text2:"{text:\"\",extra:[{text:\"Easy\",color:dark_green},{text:\": \"},{score:{name:Easy,objective:Time}}]}",Text3:"{text:\"\",extra:[{text:\"Normal\",color:gold},{text:\": \"},{score:{name:Normal,objective:Time}}]}",Text4:"{text:\"\",extra:[{text:\"Hard\",color:dark_red},{text:\": \"},{score:{name:Hard,objective:Time}}]}"}1
This will affect all currently loaded item frames. To undo this, simply replace the 1 with a 0. To set only frames within a specific radius, use this command:
/entitydata @e[type=ItemFrame,r=5] {Invulnerable:1}
Change the 5 to whatever radius you need.
0
Using command blocks, you can use the /entitydata command to set the "invulnerable" tag for frames to true. Once you have the frames in place, use the following command:
/entitydata @e[type=ItemFrame] {Invulnerable:1}
0
This seems to be a recurring issue associated with hopper clocks. Some people have been able to redownload the map to fix this problem, but if the issue persists, you should probably try a different adventure. Sorry for the inconvenience!
0
It sounds like the armor stand method is fairly safe, which is good. I'll try the mob spawner first and see how it goes.
Thanks again.
0
Thanks as always!
Two questions:
1) Would there be any problem naming multiple armorstands SpawnGroupX where X=1,...,8 and each group is comprised of roughly 10 armorstands (corresponding to possible spawn locations)?
2) Would this system, executed every 30 seconds-ish, be significantly less load-heavy than mob spawners with large (~200) radii in a redstone heavy adventure map environment? Or would mob spawners be a fine solution?
0
As a follow up, could you write a command that sets the scoreboard objective nearMobs to the number of mobs within radius r of an armorstand? That would be helpful.
0
That's not bad! I may use that unless something more elegant rears its head. The issue of checking for mobs remains, but a simple /testfor is probably the best that can be done.
The spawning is for a medium scale adventure map based on floating islands which can be mined by players, so the solution needs to be simple and computationally inexpensive. Here is a sample picture:
0
What is an efficient (low game load) way to continuously summon custom mobs into specific areas (~100 in radius)?
The ways I can think of are:
- Use a mob spawner with a large radius, but this may cause some lag
- Summon mobs at specific preselected points, but this needs to check for the number of mobs in the area first, which may be computationally expensive
- Summon items at the player's location which fly 'randomly', then after a designated interval, check whether there are few enough mobs and the spawn point is valid (ie, on a solid block). However, this seems doable but complicated.
Any other methods are welcome, please!
0
Hydrox from reddit came up with an elegant solution: teleport an armorstand to y=0 under the player and check its position with the radius argument. I think that will be best, just because I'm a little wary of the technical blocks.
0
This unfortunately won't work for my uses for two reasons (neither of which were specified before). First, the player will be able to access the entire y-axis in this cylinder; they will not be restricted to the ground. Second, there can be no floor. This is due to the map being centered around floating islands.
0
This may be doable. Thanks for the idea.
0
The cylinder should be 501 in diameter (a 250 block radius) and stretch from floor to ceiling (y=0 to y=255). It's a large area, so the patchwork method you described would probably require 25-255 /testfor commands if arrayed vertically to give a good approximation of the cylinder, so this is not quite feasible. I'm looking for a solution which requires at most 10 commands, and even that is a lot.