I've got something. I'm not terribly familiar with spread loading or the spreadplayer command in general, so this might not work...
The idea is:
What if I loaded a huge ammount of chunks at once, detected an ArmorStand named ?"TempTeleport" or something? and starting running an execute command with a spreadplayers relative to it.
If you want to load all chunks the thing could be in, in a small map like Laingral (2000x2000 blocks) you'd need about 45K command blocks, in a map like RageCraft it's probably going to be something like... 390625 ((10,000/16)^2, or a 10,000 by 10,000 area) command blocks.
Since they're fill strips, you can fit as much in them if you want. The most complete option would allow you to fit 16*16*256/3*2 (Only 2/3 can be filled with cmd blocks, you need something to trigger it) = 45K command blocks in one chunk
390625/45,000=9. You'd need to fill 9 CHUNKS with command blocks, from top to bottom, to be able to load a map. What would that do to the game?
Imagine if you loaded up the world, and you'd setup a system to detect loading the world. The player would enter the game. Usually, the server loads a 12x12 chunk area before allowing you to join (spawn chunks), which takes roughly 5 seconds on an average pc.
12*12 = 144. 390625/144 = 2712. So, it'd take 2712*5 = 2712 minutes, or 226 hours to load the entire map. If your RAM could even handle that, which it probably can't.
Ok, so imagine if you were to spread it out over time. You'd still have to load 390625 thousand chunks somehow.
I just thought of something, actually. I don't feel like trying this, but it might work.
It is possible to load chunks temporarily by teleporitng an armorstand relative, /tp @e[type=ArmorStand] ~ ~ ~1 will make it load new chunks if it runs into them.
So, what can we do?
Imagine if a player places down an armostand at x=10,000. We can then use binary search to determine the coordinates of the armorstand and store them in a scoreboard.
Once we have those, we can, once the server gets restarted, invert this binary search to start up the chunk loader. This would require to load about 32 chunks I think, which is quite doable, but it's really complex. If you guys really wanted me to, I'd make you guys a box that you can blob down in your world for this all to work, once I got some spare time. It'd take a few 100 command blocks and some time fiddling around, but it's far more doable then loading the entire world.
Actually, the idea is that a single spreadplayer command will spread over a large area, say 2000x2000. Possibly with multiple entities to speed things up. Every entity will load one of the chunks in the 2000x2000 area, eventually the RNG will load the chunk that your armor stand is in. Then a separate command will trigger, spreadplayering relative to the armorstands location and disabling the first command block.
3 command blocks.
Edit: I just noticed reread the bottom of your post. time might be an issue... Though as far as I know the spreadplayer command loads "lazy" chunks which probably/possibly load faster than active ones.
Actually, the idea is that a single spreadplayer command will spread over a large area, say 2000x2000. Possibly with multiple entities to speed things up. Every entity will load one of the chunks in the 2000x2000 area, eventually the RNG will load the chunk that your armor stand is in. Then a separate command will trigger, spreadplayering relative to the armorstands location and disabling the first command block.
3 command blocks.
Edit: I just noticed reread the bottom of your post. time might be an issue... Though as far as I know the spreadplayer command loads "lazy" chunks which probably/possibly load faster than active ones.
I don't know about loading the chunks that way, but still.
2000x2000 chunks means 4,000,000 chunks. If you were to load 1,000 chunks on average every tick (20 times per second), ticks would get slowed down to 1/50th of their normal speed (the game would only update once every 2.5 seconds, making combat already impossible), and it would on average still take 4,000 ticks, or 10,000 seconds, or 3 hours, to load everything it never missed one. If you setup <10 entities, the server wouldn't lag, but if RNG went perfect it would take 400,000 ticks before everything loaded. That's 400,000/20 = 20,000 seconds or 6 hours.
Loading every chunk just isn't a thing. I recommend the binary search method. It's complicated, high-tech stuff, but it works theoretically. The only issue with that method is, that you'd need to resummon your chunk loader every tick, and also load 40 other chunks per teleporter you want loaded, because even without restarting the server, your teleporter will unload every 10,000 ticks or so because of the chunk loader glitch.
Well, ACTUALLY Ok take a look at the following. Whenever the player spawns the entity, we use binary search on it to determine it's location. Then, once the player demands to be teleported to that location, we just invert the binary search to get the player there. We don't even need chunk loaders.
I don't have the time to actually setup a working sample because I want to finish rogue ASAP, and it could take me 1-2 hours I dno't want to waste. I hope anyone gets my idea and sets up a sample? Maybe?
I don't know about loading the chunks that way, but still.
2000x2000 chunks means 4,000,000 chunks. If you were to load 1,000 chunks on average every tick (20 times per second), ticks would get slowed down to 1/50th of their normal speed (the game would only update once every 2.5 seconds, making combat already impossible), and it would on average still take 4,000 ticks, or 10,000 seconds, or 3 hours, to load everything it never missed one. If you setup <10 entities, the server wouldn't lag, but if RNG went perfect it would take 400,000 ticks before everything loaded. That's 400,000/20 = 20,000 seconds or 6 hours.
Loading every chunk just isn't a thing. I recommend the binary search method. It's complicated, high-tech stuff, but it works theoretically. The only issue with that method is, that you'd need to resummon your chunk loader every tick, and also load 40 other chunks per teleporter you want loaded, because even without restarting the server, your teleporter will unload every 10,000 ticks or so because of the chunk loader glitch.
Well, ACTUALLY Ok take a look at the following. Whenever the player spawns the entity, we use binary search on it to determine it's location. Then, once the player demands to be teleported to that location, we just invert the binary search to get the player there. We don't even need chunk loaders.
I don't have the time to actually setup a working sample because I want to finish rogue ASAP, and it could take me 1-2 hours I dno't want to waste. I hope anyone gets my idea and sets up a sample? Maybe?
Okay, I'm an idiot. That works much better. Would tping more than 1 block relative work. I once had a bedrock box generator, that TPed chickens along the Axises to generate the wall. They'd test to see how close they were to the intended size and use bigger TPs and Fills as able. I think I had to teleport the player as well, to keep the chunks loaded...
Well, you can actually reliably teleport an entity in the direction of the spawn chunks. Have an entity at spawn (entity A) in always-loaded chunks and create the entity (B) that you want to teleport in spawn's direction. Then, execute at entity B to testfor entity A, using large dx and dz values. (Something like "/execute @e[name=B] ~ ~ ~ testfor @e[y=0,dx=1000000,dy=256,dz=1000000,name=A]" will find entity A if it's in the northeast direction.) Use similar tests for northwest, southeast, and southwest. Then, use spreadplayers to teleport entity B in whatever direction the tests indicated - say, northeast - and repeat the tests. (Spreadplayers will load the chunk if it's unloaded, as I recall - though I don't believe it's entity-loading, so you'll need to create a 5x5 grid of spreadplayers'ed entities. This will eventually make a lot of these entities build up, so have a clock running in spawn that kills them - they'll only be killed if they're in entity-loaded chunks.) If A is still northeast of B, repeat. If not, test for A to the northwest and southeast of B - if one of those works, B has passed A on the Z or X axis, so you don't need to keep spreadplayers-ing the entity in the corresponding direction. Also, each time you use spreadplayers to teleport B, add to a pair of scoreboard objectives (for X and Z axes).
When you want to teleport the player back to the temporary teleporter, use those scoreboard objectives to determine in which direction to spreadplayers an entity. When you've spread the entity a number of times equal to the scoreboard objective, the chunk with the temporary teleporter will be loaded, and you can teleport the player.
Rollback Post to RevisionRollBack
Mapmaker and LPer of Complete The Monument (CTM) maps.
Creator/owner of the CTM Community Mapping Server - ask about it on the CTM Community thread!
Current projects:
Thanatos - a subterranean semi-open-world urban CTM
Titan's Revolt - a collaborative project run by ProjectCTM; sequel to Pantheon
Pinnacle - a "sketch" mini-CTM intended for newer players (nearing completion!)
Well, you can actually reliably teleport an entity in the direction of the spawn chunks. Have an entity at spawn (entity A) in always-loaded chunks and create the entity (B) that you want to teleport in spawn's direction. Then, execute at entity B to testfor entity A, using large dx and dz values. (Something like "/execute @e[name=B] ~ ~ ~ testfor @e[y=0,dx=1000000,dy=256,dz=1000000,name=A]" will find entity A if it's in the northeast direction.) Use similar tests for northwest, southeast, and southwest. Then, use spreadplayers to teleport entity B in whatever direction the tests indicated - say, northeast - and repeat the tests. (Spreadplayers will load the chunk if it's unloaded, as I recall - though I don't believe it's entity-loading, so you'll need to create a 5x5 grid of spreadplayers'ed entities. This will eventually make a lot of these entities build up, so have a clock running in spawn that kills them - they'll only be killed if they're in entity-loaded chunks.) If A is still northeast of B, repeat. If not, test for A to the northwest and southeast of B - if one of those works, B has passed A on the Z or X axis, so you don't need to keep spreadplayers-ing the entity in the corresponding direction. Also, each time you use spreadplayers to teleport B, add to a pair of scoreboard objectives (for X and Z axes).
When you want to teleport the player back to the temporary teleporter, use those scoreboard objectives to determine in which direction to spreadplayers an entity. When you've spread the entity a number of times equal to the scoreboard objective, the chunk with the temporary teleporter will be loaded, and you can teleport the player.
Well, you can actually reliably teleport an entity in the direction of the spawn chunks. Have an entity at spawn (entity A) in always-loaded chunks and create the entity (B) that you want to teleport in spawn's direction. Then, execute at entity B to testfor entity A, using large dx and dz values. (Something like "/execute @e[name=B] ~ ~ ~ testfor @e[y=0,dx=1000000,dy=256,dz=1000000,name=A]" will find entity A if it's in the northeast direction.) Use similar tests for northwest, southeast, and southwest. Then, use spreadplayers to teleport entity B in whatever direction the tests indicated - say, northeast - and repeat the tests. (Spreadplayers will load the chunk if it's unloaded, as I recall - though I don't believe it's entity-loading, so you'll need to create a 5x5 grid of spreadplayers'ed entities. This will eventually make a lot of these entities build up, so have a clock running in spawn that kills them - they'll only be killed if they're in entity-loaded chunks.) If A is still northeast of B, repeat. If not, test for A to the northwest and southeast of B - if one of those works, B has passed A on the Z or X axis, so you don't need to keep spreadplayers-ing the entity in the corresponding direction. Also, each time you use spreadplayers to teleport B, add to a pair of scoreboard objectives (for X and Z axes).
When you want to teleport the player back to the temporary teleporter, use those scoreboard objectives to determine in which direction to spreadplayers an entity. When you've spread the entity a number of times equal to the scoreboard objective, the chunk with the temporary teleporter will be loaded, and you can teleport the player.
This is basically what I referred to as binary search, if I understand what you mean, yet I/the video I linked was using the worlds edge instead of spawn chunks. Is that right? I don't follow exactly what you say.
Alrighty guys. I have made names for my I2 areas. Some of them are not that unique, but one of them has quite the unorthodox meaning on the contrary to its name.
nice sounding names, on the brink of hell is my favorite of the three . i think its interesting that you give areas names before actually making the area, i do the complete opposite! Different mapmakers do different things
I just began a new thread for CTM Guides. I plan to continue this one, however. So follow it as much as you can! Sorry if it doesn't look great right now, I can't figure out how to separate lines from each other.
Hey there, all. I stream CTMs as well as other indie games, Minecraft servers and probably that's it. I'm your supreme overlord too so I command you to CHECK ME OUT: www.twitch.tv/techniclepanther
Hey guys, quick question here. I have basically finished making my own little CTM map, and I've encountered a bit of an issue. I am (as I'd assume most of you are) a big fan of Vechs, and had intended on using Kamyu's populate chests program to assist me in creating randomized chest loot. However, I now know that the program isn't really compatible with 1.8.1. So I am at a standstill right now, with over 300 empty chests in my map (in addition to my basic "potions" or "blocks" chests) that I really don't want to have to go through and fill myself. Is there any usable and reliable alternative to doing this manually?
What do you guys use when creating loot?
Hey guys, quick question here. I have basically finished making my own little CTM map, and I've encountered a bit of an issue. I am (as I'd assume most of you are) a big fan of Vechs, and had intended on using Kamyu's populate chests program to assist me in creating randomized chest loot. However, I now know that the program isn't really compatible with 1.8.1. So I am at a standstill right now, with over 300 empty chests in my map (in addition to my basic "potions" or "blocks" chests) that I really don't want to have to go through and fill myself. Is there any usable and reliable alternative to doing this manually?
What do you guys use when creating loot?
Most of us just do it by hand; it's a lot easier to balance everything just the way you want it, and it generally leads to higher-quality maps. Really, I recommend using hand-placed loot; 300 chests isn't actually too many. Most of the time, when people want to use random loot, they're being lazy, and random loot will not cover up that laziness. I guarantee you, if you don't take the time to do random loot right, that laziness will show through in the final product.
Nevertheless, I created a random loot filter for MCEdit not too long ago. Before I give you the link, though, there are a few things you really need to know about random loot...
1. Don't do it like Vechs did in Inferno Mines. That loot was unbalanced in all the worst ways - primarily due to the fact that he only had 2 "tiers" of loot. Make a lot of tiers - somewhere between one per intersection and one per area.
2. This filter is NOT a way to avoid hand-placing at least a little bit of loot. You need to place at least some special or important items by hand. The map will end up being much better for it, trust me.
3. The filter is not particularly easy to use. For one thing, you need to know NBT formatting to do anything more complicated than unenchanted items without custom names or lore. Check out "chunk format" and "<player>.dat format" on the Minecraft wiki. Additionally, you'll need to create individual .txt files for each tier of loot; the filter works by filling every empty chest in the selection based on a file that you specify when you run the filter.
Anyway, here you go. Use it with care. (Also read the "README" file inside the zip file; I probably explained stuff better in there than I did here.)
Hey guys, quick question here. I have basically finished making my own little CTM map, and I've encountered a bit of an issue. I am (as I'd assume most of you are) a big fan of Vechs, and had intended on using Kamyu's populate chests program to assist me in creating randomized chest loot. However, I now know that the program isn't really compatible with 1.8.1. So I am at a standstill right now, with over 300 empty chests in my map (in addition to my basic "potions" or "blocks" chests) that I really don't want to have to go through and fill myself. Is there any usable and reliable alternative to doing this manually?
What do you guys use when creating loot?
Basically, either use what Tasch made, following his directions carefully as to not end up with something horribly unbalanced, or get ready to design your loot curve by hand. And designing it by hand isn't a bad thing. In fact, most of us here would likely be far more interested if you did it manually. It lets you, the creator, determine what a player has rather than leaving it up to chance, and also lets you think of what a player could want in a specific situation, and then offer it somewhere along the way.
Basically: Never use Random Loot for your whole map. You're free to be as big a fan of Vechs as you like, but don't repeat his mistakes with random loot. Your work will come out worse for it.
How can I make a ROM-Hack Hard map enjoyable for a player game play wise? Very tough and possible or any other way?
make the player think more about their environment than the mobs, first off, and then create custom mobs in such a way that they become a part of the environment. you also want to be setting an obstacle for the player to overcome at every point in the map, so make sure to lead the player on with interesting and seemingly difficult things at the beginning of areas so that they want to stick with the area and overcome it. all about keeping the player on a track to keep interest in the map and overcome it.
The idea is:
What if I loaded a huge ammount of chunks at once, detected an ArmorStand named ?"TempTeleport" or something? and starting running an execute command with a spreadplayers relative to it.
Something like this:
Command Block #1: "/testfor @e[type=ArmorStand,Name=TempTeleport]
With a NOT gate leading to:
Command Block #2: "/spreadplayers 0 0 1000 16 false @e[name=chunkloader]"
And also have a handful of entities named chunkloader
The aboe command won't necessarily load the chunk your "TempTeleport" is in on the first try. But it will eventually.
Then either off Command Block #1 without a NOT gate, or with a knew command block that is identical to command block #1:
Command Block #3: "/spreadplayers ~ ~ 0 1 false @e[name=chunkloader]"
Viola! A chunk loader that will sorta survive a reboot.
That could work, and the idea is nice, but...
If you want to load all chunks the thing could be in, in a small map like Laingral (2000x2000 blocks) you'd need about 45K command blocks, in a map like RageCraft it's probably going to be something like... 390625 ((10,000/16)^2, or a 10,000 by 10,000 area) command blocks.
Since they're fill strips, you can fit as much in them if you want. The most complete option would allow you to fit 16*16*256/3*2 (Only 2/3 can be filled with cmd blocks, you need something to trigger it) = 45K command blocks in one chunk
390625/45,000=9. You'd need to fill 9 CHUNKS with command blocks, from top to bottom, to be able to load a map. What would that do to the game?
Imagine if you loaded up the world, and you'd setup a system to detect loading the world. The player would enter the game. Usually, the server loads a 12x12 chunk area before allowing you to join (spawn chunks), which takes roughly 5 seconds on an average pc.
12*12 = 144. 390625/144 = 2712. So, it'd take 2712*5 = 2712 minutes, or 226 hours to load the entire map. If your RAM could even handle that, which it probably can't.
Ok, so imagine if you were to spread it out over time. You'd still have to load 390625 thousand chunks somehow.
I just thought of something, actually. I don't feel like trying this, but it might work.
It is possible to load chunks temporarily by teleporitng an armorstand relative, /tp @e[type=ArmorStand] ~ ~ ~1 will make it load new chunks if it runs into them.
So, what can we do?
Imagine if a player places down an armostand at x=10,000. We can then use binary search to determine the coordinates of the armorstand and store them in a scoreboard.
Once we have those, we can, once the server gets restarted, invert this binary search to start up the chunk loader. This would require to load about 32 chunks I think, which is quite doable, but it's really complex. If you guys really wanted me to, I'd make you guys a box that you can blob down in your world for this all to work, once I got some spare time. It'd take a few 100 command blocks and some time fiddling around, but it's far more doable then loading the entire world.
3 command blocks.
Edit: I just noticed reread the bottom of your post. time might be an issue... Though as far as I know the spreadplayer command loads "lazy" chunks which probably/possibly load faster than active ones.
I don't know about loading the chunks that way, but still.
2000x2000 chunks means 4,000,000 chunks. If you were to load 1,000 chunks on average every tick (20 times per second), ticks would get slowed down to 1/50th of their normal speed (the game would only update once every 2.5 seconds, making combat already impossible), and it would on average still take 4,000 ticks, or 10,000 seconds, or 3 hours, to load everything it never missed one. If you setup <10 entities, the server wouldn't lag, but if RNG went perfect it would take 400,000 ticks before everything loaded. That's 400,000/20 = 20,000 seconds or 6 hours.
Loading every chunk just isn't a thing. I recommend the binary search method. It's complicated, high-tech stuff, but it works theoretically. The only issue with that method is, that you'd need to resummon your chunk loader every tick, and also load 40 other chunks per teleporter you want loaded, because even without restarting the server, your teleporter will unload every 10,000 ticks or so because of the chunk loader glitch.
Well, ACTUALLY
Ok take a look at the following. Whenever the player spawns the entity, we use binary search on it to determine it's location. Then, once the player demands to be teleported to that location, we just invert the binary search to get the player there. We don't even need chunk loaders.
I don't have the time to actually setup a working sample because I want to finish rogue ASAP, and it could take me 1-2 hours I dno't want to waste. I hope anyone gets my idea and sets up a sample? Maybe?
Okay, I'm an idiot. That works much better. Would tping more than 1 block relative work. I once had a bedrock box generator, that TPed chickens along the Axises to generate the wall. They'd test to see how close they were to the intended size and use bigger TPs and Fills as able. I think I had to teleport the player as well, to keep the chunks loaded...
Nope.... If only....
Yes, you can. You have to manually determine the position though, see the vid I linked above.
When you want to teleport the player back to the temporary teleporter, use those scoreboard objectives to determine in which direction to spreadplayers an entity. When you've spread the entity a number of times equal to the scoreboard objective, the chunk with the temporary teleporter will be loaded, and you can teleport the player.
This is basically what I referred to as binary search, if I understand what you mean, yet I/the video I linked was using the worlds edge instead of spawn chunks. Is that right? I don't follow exactly what you say.
The bad part is that an entire area needs to be redone
http://www.minecraft...red-emblem-ctm/
http://www.minecraft...red-emblem-ctm/
Here's the link to it: http://www.minecraftforum.net/forums/mapping-and-modding/maps/maps-discussion/2353171-ctm-map-guide-hub
Hey there, all. I stream CTMs as well as other indie games, Minecraft servers and probably that's it. I'm your supreme overlord too so I command you to CHECK ME OUT: www.twitch.tv/techniclepanther
What do you guys use when creating loot?
Most of us just do it by hand; it's a lot easier to balance everything just the way you want it, and it generally leads to higher-quality maps. Really, I recommend using hand-placed loot; 300 chests isn't actually too many. Most of the time, when people want to use random loot, they're being lazy, and random loot will not cover up that laziness. I guarantee you, if you don't take the time to do random loot right, that laziness will show through in the final product.
Nevertheless, I created a random loot filter for MCEdit not too long ago. Before I give you the link, though, there are a few things you really need to know about random loot...
1. Don't do it like Vechs did in Inferno Mines. That loot was unbalanced in all the worst ways - primarily due to the fact that he only had 2 "tiers" of loot. Make a lot of tiers - somewhere between one per intersection and one per area.
2. This filter is NOT a way to avoid hand-placing at least a little bit of loot. You need to place at least some special or important items by hand. The map will end up being much better for it, trust me.
3. The filter is not particularly easy to use. For one thing, you need to know NBT formatting to do anything more complicated than unenchanted items without custom names or lore. Check out "chunk format" and "<player>.dat format" on the Minecraft wiki. Additionally, you'll need to create individual .txt files for each tier of loot; the filter works by filling every empty chest in the selection based on a file that you specify when you run the filter.
Anyway, here you go. Use it with care. (Also read the "README" file inside the zip file; I probably explained stuff better in there than I did here.)
Basically, either use what Tasch made, following his directions carefully as to not end up with something horribly unbalanced, or get ready to design your loot curve by hand. And designing it by hand isn't a bad thing. In fact, most of us here would likely be far more interested if you did it manually. It lets you, the creator, determine what a player has rather than leaving it up to chance, and also lets you think of what a player could want in a specific situation, and then offer it somewhere along the way.
Basically: Never use Random Loot for your whole map. You're free to be as big a fan of Vechs as you like, but don't repeat his mistakes with random loot. Your work will come out worse for it.
make the player think more about their environment than the mobs, first off, and then create custom mobs in such a way that they become a part of the environment. you also want to be setting an obstacle for the player to overcome at every point in the map, so make sure to lead the player on with interesting and seemingly difficult things at the beginning of areas so that they want to stick with the area and overcome it. all about keeping the player on a track to keep interest in the map and overcome it.