Minecraft Forums

I'm fleshing out my series' of statues and airships. The plan is to go all out on Atlantis. As always, the builds speak for themselves.

Each player has a cache that is used to display other players' skins. This is refreshed when they log in, not when the player who changes their skin logs in.

Select the contents of the second rule and put it after a comma into the first, then remove the second rule. Print the contents of the first rule three more times, after commas for each one.

There are other ways to weight each one, and the contents of each option needs to be correct, or potentially failing past the point if it runs into contents that throw an error, which you can check by printing the other rule by itself to make sure it prints when called.

The /testruin command loads a template called with it from disk every time it is executed, as it was designed for testing so it needs to get the new files. Anything that spawns in with /testruin should be checked to make sure it can place the file into the world instantly.

Other than that, minecraft itself is designed to operate in vertical sections of the world, from 0 to 255, and is set up better for vertical spawning than for flat spawns with an extremely wide footprint.

There are certain steps that are commonly handled by editing the TML files in a text editor, this is one of them.

After the air (that needs to spawn in as air) is filled in with an otherwise unused block, the structure is saved as a template, and the entry in the file is changed to "air" instead of whatever block was used to represent it for the save.

This is usually one of the very last steps of structure development, as saving it again after spawning will undo the step.

I would guess that you are in a superflat world, since Ruins tries to keep from breaking the bottom of the world, as bedrock is meant to be permanent in general.

Those blocks look exactly like the most widely used signature blocks from Chisel (also used in the Crashlanding 1.6 pack).

I dusted off my old 1.7 reactor room template from the summer of 2015 and identified the blocks as:

chisel:factoryblock-6 for the yellow-black striped caution blocks (they also make an orange-white set)

chisel:factoryblock-1 for the main blocks in the rusted girders.

chisel:stonebricksmooth-10 and 12 for the cement texture (or I might be thinking of chisel:cobblestone-10 which was a block I tended to use a lot)

I remember that some chisel blocks' names were changed slightly in later versions of the game, and in 1.7 Tinkers Construct had the super-fun slime-pads that launched players a hundred blocks into the air with a hang glider, which were an integral part of all my bases, and even now I find a place to put a vertical shaft in my facilities just in case they bring the block back.

I've uploaded my updated set, link is in the sig line.

The Statue of liberty arm in the ocean might break the immersion, so a heads up on that, can't remember if it was in the previous release.

A few of the ships were overhauled and the new houses are labelled as shacks and sheds.

When starting a new world, under superflat there is a customize button.

The next screen shows the layers in the world in blocks. At the lower right is a button called "Presets", press it to go to the next screen.

At the top of that screen it has a box with text in it. That is the world code, and there are videos explaining it in detail. To add more dirt layers change the corresponding number.

The text in the box is a very long line., press ALT and A at the same time to select the entire line, then ALT-C and ALT-V to bring it into a text file so you can see the entire line at once while editing it.

I just now checked all this in 1.13.2, the text box for the world code is just in a slightly different place from where it was in previous versions.

Looking good.

Just be aware that areas covered with auto-lamps such as cities can have extreme lag spikes at every sunrise and sunset, on the order of a full second, using just as many lamps as pictured above (70 or so). Of course they would produce the most lag per lamp if each lamp was in it's own chunk.

Join my discord for the latest information: https://discord.gg/9xZuaA4

If you dont want to loose items or blocks in 1.7, make sure to open your worlds with the latest 1.6.4 atleast once.

Want to show your support? Buy me a drink

Latest update video

Always backup your world before updating.

Read the Todo List before making suggestions

Read the Frequently Asked Questions and Starting Information before asking questions

Downloads

Custom NPCs Download alternative

• Requires Forge, download here

German download: here

Older Downloads

External Dialog Editor

• 1.7.10b and lower: download (last updated 19-jun-2014)
• 1.7.10c and higher: download (last updated 24-aug-2015)
• source code

Information

This mod adds a set of tools to create npcs with different roles/jobs and other functions. It gives Creative Players a way to liven up their world with fully Customizable NPCs.

• Starting info
• Installation Guide
• Content Packs
• Frequently Asked Questions
• Todo and current plans
• Changelog
• Items
• Dialog Setup
• Factions Setup
• Roles
• Jobs
• Fan Made Machinima
• Adventure Maps
• Bug/Issue Tracker

Main developer: Noppes Co developer:

• DarkSignal, check out his Newgrounds Page

Ex developer

• smokeysamcat

Notes

• Licensed under the Creative Commons BY-NC
• If you want to use it for a modpack, include a link to this thread
• If you want to use this mod for an adventure map go ahead. No need to ask for permission
• People who do youtube videos on this mod, feel free to post them here

Resource Packs

• Dokucraft 32x32 resource pack Download by sm284614
• BDCraft/Sphanx
• Oblisgr HD Skins

Permissions

If you are using mcpc+ there are multiple permissions you can use

 customnpcs.npc.gui customnpcs.npc.create customnpcs.npc.edit customnpcs.npc.delete customnpcs.npc.reset customnpcs.npc.freeze customnpcs.npc.ai customnpcs.npc.stats customnpcs.npc.display customnpcs.npc.inventory customnpcs.npc.advanced customnpcs.spawner.mob customnpcs.spawner.create customnpcs.global.playerdata customnpcs.global.bank customnpcs.global.dialog customnpcs.global.transport customnpcs.global.faction customnpcs.global.quest customnpcs.global.recipe customnpcs.global.naturalspawn customnpcs.mounter customnpcs.pather customnpcs.villager 

Video

Tutorial/Show Off by SCMowns

Credits

Without these guys this mod wouldnt have been possible, they are awesome. Thanks for all your support.

• For skins:xSparky, willxo, DrakonsLTU, arugaicastle, Kasumi10102, meecube, DiggyDiggyHole1223, Jimorrison, MrTylon, DrakonsLTU, GingerNinjaSam, C0NV3X, fatacemcafee, MineWarCrafter, Eliwood407, NethanielShade, Tcc, MineWarCrafter, rhaidenp, Zach8460, araelb123, Gurinderm101, gui_maldito, Fox0427
• For items: Torzel, C0NV3X, Eliwood407, Scorpinax, llama66613, meecube, lazeckvar, werff, DiggyDiggyHole, Moety5, adscomics, tobbiusness
• For blocks: Redmann, tobbiusness, MineWarCrafter, owned645
• Making/Imporving models: Verdana, CarbonLord, DjGyarados, Jimorrison, Solidfire
• For banners: KingMiner, Bosch, Darkcrafter31, MrTylon, aditya25
• For extensive testing and being awesome on the forums: Darkcrafter31, MrTylon, Mr. Rinkachi, Kasumi10102, Archadeas, belldyl, Collserra, Taj, willxo, CarbonLord, C0NV3X, Eliwood407, Mikieee, tobbiusness, Charanor
• For translations: CZ:fritol33, DE:Waringham, Datixum, PL:Patrykgazing, RU:Overbolt, BR:Teraxo, ID:aditya25, KR:Cuz, FR:DjefNukem, AR:matias491, CN:miguo
• Special Thanks to: Verdana for letting me use the pony model, KodaichiZero for letting me use his grooving animation, TheKyleb for letting me use his music.

Banners

<a href="http://www.minecraftforum.net/topic/833003-"><img src='http://i.imgur.com/m6yxj.png' /></a>

<a href="http://www.minecraftforum.net/topic/833003-"><img src='http://i.imgur.com/MZMYs.png' /></a>

<a href="http://www.minecraftforum.net/topic/833003-"><img src='http://img560.imageshack.us/img560/7007/customnpcbanner3.png' /></a>

<a href="http://www.minecraftforum.net/topic/833003-"><img src='http://i.imgur.com/42bg6.gif' /></a>

~

Quote from Gillymoth»

Considering the sheer number of templates in any given biome (or in any given spawning list), I'm wondering what the maximum total value is for the spawn-weighting system.

Currently, a little over two billion--2,147,483,647. In the next version of Ruins, which allows fractional weights, it'll be on the order of a hundred thousand centillion. As you said, though, the danger of overflow (going over the maximum value) now or underflow (going under the finest precision) later is negligible, unless you're actively trying to break things with pathological weight values.

A word of caution when using weight to control "rarity," however; while it's one of the factors in determining how frequently a particular template spawns, it's not the only--or even necessarily the most important--one. A template's weight only specifies how likely it is to be selected, relative to other templates eligible to spawn in the same biome, for consideration. Once selected, the template's chances of actually spawning a structure depends entirely on the stringency of its surface criteria (acceptable_target_blocks, allowable_overhang, max_leveling, the area of its footprint) and proximity limits (uniqueMinDistance, leveling_buffer). It's also worth noting the higher the value of configuration parameter tries_per_chunk_normal, the more significant these other factors can become.

Bottom line: it's not true to say that, if template A has weight=2 and template B has weight=1, there will be (statistically) twice as many A structures as B (unless A and B are identical in every other relevant way). If A has a bigger footprint, for example, you may very well see more instances of B than A, despite their weights. The best you can reliably say is increasing/decreasing a template's weight makes it more common/rare than it was before the change; it doesn't specify how rarely it actually spawns structures in absolute terms. The only practical way to gauge rarity is by experimenting.

Version 17.2 highlights, in case anyone's interested, because it's been a while:

* New config parameter enableFixedWidthRuleIds:If set to true, all rule IDs in templates generated by /parseruin are left-padded with zeroes to make them all the same width so things line up nicely. Purely cosmetic. If set to false, no padding is added, as before. The default is false. Note the dimension 0 configuration setting of this parameter applies to all dimensions, so only world/ruins.txt (or equivalent) needs to be edited to modify its value. Settings in the various DIMxxx subfolders are ignored.

* New template parameter biomeTypesToSpawnIn: Optionally specify biome types in which this template should spawn (in addition to those explicitly listed as biomesToSpawnIn). In theory, this eliminates the need to anticipate custom biomes added by other mods, using descriptive tags instead of specific names (e.g., biomeTypesToSpawnIn=COLD,DRY to spawn in any COLD or DRY biome). It can be more than just a simple list; logical operators are supported to construct more complex expressions, as detailed in an earlier post.

* New template parameter biomesToNotSpawnIn: Optionally specify a list of biomes in which this template should absolutely not spawn, even if the biome type criteria are met.

* New template parameter requiredMods: Optionally specify mods which must be active (or not active) for this template to be loaded at all (e.g., requiredMods=quark+biomesoplenty to load only if both Quark and Biomes O' Plenty are active, presumably because it uses blocks from these mods). Logical expressions are supported, as above.

* Bug fix: teBlocks work now! Also, duplicate teBlocks in a parsed structure no longer unnecessarily create separate rules.

* Bug fix: Spawned ruins no longer float above the ground. Unless they were designed to, of course.

* Bug fix: Terrain leveling is a bit cleaner, and /undoruin now reverts leveling effects.

* ...plus a number of other less-interesting, esoteric bug fixes, performance enhancements, and preparations for Minecraft 1.13.

There have been some changes to the new biomeTypesToSpawnIn template parameter. It now accepts full-blown logical expressions rather than just a glorified list. As a result, the proposed new biomeTypesToNotSpawnIn parameter is no longer necessary and has been eliminated. Here's a brief primer:

The biomesToSpawnIn parameter works the same as before--it's a simple list of biomes IDs, and the template will spawn in those biomes regardless of biomeTypesToSpawnIn and biomesToNotSpawnIn settings. The biomesToNotSpawnIn parameter is still there, and it too is a simple list of biomes IDs, filtering out any specific biomes you want to exclude even if they meet the biomeTypesToSpawnIn criterion.

Another new template parameter was added, requiredMods, allowing you to declare any mods that need to be present for the template to load, but...

Quote from Gillymoth»

Of course, changing how the generation is handled would break a lot of things, and could be toggled if a specific structure shouldn't be rotated freely, but the option would be there. What do you think?

Given that this and other transformations discussed earlier in the thread have limited and very particular application, I think what you're really doing is making the case for is a beefed-up API so addon mods can manipulate ruins arbitrarily before they're made manifest in the world. Don't get me wrong--I love the idea of transformations like this. I'm just not sure they're within the scope of the Ruins mod itself.

I feel a template would pretty much have to be designed from the ground up (no pun intended) with specific transformations in mind. There's a whole host of issues that'd prevent general-use templates from employing them. In the case of non-cardinal rotation, for instance, a template author would need to take into account connected blocks (e.g., glass panes, fences, redstone, rails, beds) not lining up as expected, corner blocks meant to be accessible possibly being hidden behind walls, and--arguably most important--unintended block duplication. That treasure chest with a super duper magic sword buried at the bottom of your dungeon might just be super duplicated.

Still, none of that's not a deal breaker. One could design templates specifically with all that in mind--templates not relying on connectivity, without critical corner blocks, and devoid of especially valuable contents. Landscaping elements, maybe. Because transformations require so many special considerations, though, and therefore shouldn't typically be applied to templates in general, I don't know they belong in the Ruins mod proper. Again, AtomicStryker's call.

Quote from Jordan_Peacock»

I have gotten the impression that only the central target block is checked against acceptable_target_blocks, but that it checks all the blocks at the target layer (within the footprint) against unacceptable_target_blocks, so a really long exclusion list could take a while to do all the comparisons. (Am I right or wrong on either point? It'd be useful to know for sure. )

I already explained which blocks are ignored, and how you can (minimally) affect that list. The lists of unacceptable and acceptable blocks you can specify explicitly. If the unacceptable list is empty (which both lists are if you don't set them), it means no blocks are unacceptable, as you might expect (though some might end up that way by default). If the acceptable list is empty, however, that's interpreted as though it lists every block in the game.

Now, armed with that information, you can see it never makes sense to list both acceptable_target_blocks and unacceptable_target_blocks. Either specify a whitelist of acceptable blocks and all others are automatically unacceptable, or specify a blacklist of unacceptable blocks and all others are automatically acceptable. There's also no point in putting ignored blocks on either list.

The surface on which Ruins is considering placing a structure is checked throughout the entire area of that structure's footprint. In every [X, Z] position, the topmost non-ignored block, if any, must not be unacceptable. If even just one is, the spawn fails. Only acceptable blocks and "holes" are allowed. If the number of holes exceeds allowable_overhang, the spawn also fails. Note only the surface is checked--if the surface passes muster, any number of unacceptable blocks can otherwise occur within the volume of space the structure is going to occupy.

To further complicate matters, none of this applies to structures spawned via /testruin, which completely disregards the whole acceptable vs. unacceptable thing. That is, unless you use an underscore (_) as the Y-coordinate, in which case it does consider acceptability, but only at the one specified [X, Z] position, not the entire footprint. Adjoining templates obey all the normal rules, though. Whew!

Performancewise, it is true shorter lists require less processing time than longer ones. Among all the calculations going on, however, that's nowhere near the tallest pole in the tent, so I wouldn't spend a lot of effort optimizing target block lists...but if hypermiling's your thing, knock yourself out.