Mixing blocks and Ruins directives in one rule can sometimes be tricky, but can often work by having the simple blocks precede the directives. This includes "iinventory" directives, dungeon loot containers, command blocks, etc.
While that may work for all other Ruins "special blocks" (I'm looking at you, WallSign and StandingSign), the CommandBlock has a whole separate section of code devoted to interpreting it. I don't recommend ever combining CommandBlocks and non-CommandBlocks in the same rule; that puts you deep in the realm of undefined behavior. If you need to do that, use teBlock.
Thanks for the updates. I'm still going through, trying to fix broken stuff in my templates. I'll post again once I have something available for show 'n' tell.
Sorry about JG_WizardTower1b_CB_1v12. I appear to have included that in my pack by accident. It looks like one of my old interim work files that I was in the middle of trying to convert up to 1v12, but did not finish, yet somehow it ended up in the finished folder. I've got some cleaning up to do on that one.
Also, I guess I really DO have the new Ruins update, since everything generated by /parseruin looks very different. Thanks to QuarterAnimal for the clarification about that.
Minor detail: For the new templates created by /parseruin, I was a bit overwhelmed by walls of comments padding each of the fields. It took me a bit to sort out that it was an explanation for each field immediately preceding the default setting for that field generated by /parseruin. For greater readability, I would recommend an extra line of padding (an extra "carriage return," to use archaic parlance) between the field setting and the next wall of comments. That more clearly helps to visually group the setting with its particular explanation, IMHO.
P.S., I'm pasting the "biomesToSpawnIn" list into my new template packs from now on. It's a pretty useful reference, and a bit tricky to track down in the thread on a moment's notice. While I'm going through to try to fix things, I'm going to see if I can trim down my ridiculously long "biomesToSpawnIn" lists to rely more on that feature instead.
Hello again. Is there a way to forcefully spawn a structure at a specific point? I want to build a base around a ruins structure, and it has to be on the spawn chunk, or at least in a radius of 14 chunks from the spawn point, because it is always loaded. And even though I have set the parameter anySpawnMinDistance=0 structures still don't spawn around the spawn chunk and in 14 chunks radius from it. I have tested it in about 50 or even more worlds, took me a while.
If there would be a "spawn" folder that would contain a list of buildings to choose from, to generate at the worldspawn, then that might be how it would be organized. The vanilla game might also benefit from having a folder for which spawnpoint structures are selected, since in recent versions mojang keeps adding things to the vanilla structure list.
Is there a way to forcefully spawn a structure at a specific point?
Only by manually spawning it with /testruin.
... even though I have set the parameter anySpawnMinDistance=0 structures still don't spawn around the spawn chunk and in 14 chunks radius from it. I have tested it in about 50 or even more worlds, took me a while.
It does work--I just tried it now, and a structure spawned right on top of the spawn point the first time, with a bunch more nearby. Of course, there have to be templates eligible to spawn near the spawn point, depending on whatever biome and surface blocks are present.
Are you creating these test worlds from scratch? If so, you need to set anySpawnMinDistance=0 in config/ruins.txt, as that's the file copied into the world folder prior to initial worldgen. If you're creating the world first and editing its world/ruins.txt, you're too late--chunks around spawn have already been generated with the default anySpawnMinDistance=32.
If you're just deleting the world/region folder and letting Minecraft regenerate the same world all over again, you need to set anySpawnMinDistance=0 in world/ruins.txt. You also need to delete world/RuinsPositionsFile.txt each time; otherwise, Ruins "remembers" structures spawned from previous worldgens and considers their spawn locations occupied.
If you're already doing that and still not getting ruins near the spawn point, you're seeing behavior I'm not. There's no guarantee you'll see ruins near spawn, of course, since it's up to chance...though in 50 tries, statistically, you should've seen something.
[atomicstryker.ruins.common.RuinGenerator$FlushThread:run:127]: java.io.IOException: The system cannot find the path specified
This is the same error kellixon reported a while back. Ruins is having trouble creating RuinsPositionsFile.txt in your world folder (or one of the world/DIMxxx subfolders). I've never seen this error myself, but my best guess as to why it's happening (and why it's hard for me to recreate) is, due to the timing of separate threads, Ruins tries to write to the position file before the world folder is created. By any chance are you running with other mods that create new dimensions? I suspect it may be related to that, though I suppose it's possible for the situation to arise even with just the basic dimensions.
The twilight forest, I think, is the only mod that creates dimensions. Technically, also the Applied Energistics 2 with its spatial storage unit can create dimensions. Is this error critical? I will try launching minecraft with the system administrator elevation and see if this error happens again.
Unfortunately, since I can't reproduce it, I can't confidently characterize it, either. Since it seems to happen fairly regularly for you, can you verify that 1) it only happens when you start a new world, never when you return to an existing world, and 2) when it does happen, there's a RuinsPositionsFile.txt in the world folder and every world/DIMxxx subfolder? If the answer to both is "yes," then it's not a critical error at all, just an annoyance. Everything is working fine.
If the answer to #1 above is yes, but at least one folder is missing its RuinsPositionsFile.txt, Ruins may double-generate structures around spawn, as it's forgetting its initial pass at worldgen. I think I have a fix for that, if that's what's happening. If the answer to #1 is no, my theory regarding the cause of the error message is wrong, and I need to investigate further.
It didn't happen this time I ran the game, but the last time it happened I was creating and deleting worlds. Maybe ruins thread is still running when the game deleted the world and it's directories. I should also mention that I use OTG(and biome bundle) to generate worlds. Also, yes, there are DIMxxx subfolders for each dimensions, including twilight forest and RuinsPositionsFile.txt[/b] too this time.
When creating new worlds and deleting them, make sure to have unique filenames for each world. If there are any loose ends from naming a new world the same as a freshly deleted world, then that practice should be avoided by giving every world a previously unused name.
Minecraft itself is known to have less than perfect garbage collection systems regarding things like tile entity rendering and the like, so one should expect it in other areas as well.
I submitted a pull I think (hope?) fixes the "cannot find the path" error you've been seeing, so look for that in the next Ruins release (17.3). I'm kind of relying on you to test it, since I still haven't been able to reproduce the error myself. I'm sure I fixed A problem (or three); I'm just not sure it's THE problem.
So. Anybody care to brief me on what the current situation of the mod is?
Is it similar to 1.8/what changes have occured since then
Is it still as safe to use with (almost) everything and all, or do I have to look out?
I might want to have it in a server modpack and would like to know if it still is the mod I remember
I don't know of anything that's going to cause crashes, or "break" other programs, on a technical level. If there are any issues, it's more with aesthetics and "economy balancing." That is, if you're going to include Ruins with a modpack, I think it's just plain lazy when someone just tosses generic Ruins with the generic included templates into the modpack and leaves it at that. Rather, I think a modpack maker who bothers to include Ruins should take some effort to curate which templates are included, and by all means empty out the "generic" folder, and put templates into biome folders specific to what will actually appear in the modpack.
The primary reason for Ruins to include most of its example templates in the "generic" folder, rather than to demonstrate how you could theme things by putting your log cabins in the forest, your mini-villages in the plains, and your igloos on the ice plains, is because there are so many mods that will add new biomes, so it's the surefire way to make sure that with minimal effort, you can plop Ruins into your mix o' mods and have SOMETHING interesting happen.
For instance, The Lost City is an awesome mod that either allows you to have an Overworld that spawns with lots of ruined cities (flooded or not, in various degrees of destruction and density), OR to have a "Lost City Dimension" that you can visit once you generate the requisite resources for the "magic bed" that takes you there. Spawning a Lost City world with the default Ruins templates in the "generic" folder would result in some pretty silly results, as you might have Moai heads or spider caves randomly popping up on rooftops or in the middle of streets. Lost City doesn't create its own "city" biomes, but just uses regular terrain-gen biomes (and has options specifically compatible with Chisel mod), so unfortunately you can't work around it just by assigning Ruins templates to "non-city" biomes (since no such thing exists in that mod). For Ruins to spawn sensibly in conjunction with Lost City, you'd probably want to fine-tune templates to exclude a wider range of materials to build atop (i.e., don't build on concrete, stone slabs, cobblestone, quartz block, iron bars, brick, glass), or maybe just stick to "on-the-water" or "floating-in-the-sky" templates such as various airships or boats that are less likely to mesh strangely with buildings.
Twilight Forest isn't likely to suffer much, as the Forest is in its own dimension, and you'd have to deliberately tweak the config to get Ruins structures to start spawning there, but if you DO go that route, I'd recommend emptying out the "generic" folder and putting the templates in those biomes you specifically WANT things to pop up in. Some experimentation is in order, rather than expecting random out-of-the-box Ruins templates to play nicely with the Twilight Forest structures.
It's hard to get Ruins to work well with Mystcraft simply because Mystcraft creates additional dimensions on the fly, so you can't very well set up the config to whitelist those dimensions -- unless you basically have an exhaustive list of all possible dimension numbers right from the get-go, and just endeavor not to go so crazy with dimension-building that you go past those numbers. (For this reason, I think it'd be nice if the Ruins config could have an optional dimension "blacklist" that could be used instead of the "whitelist," but in that case, I wish it were possible to have a "Ruins pre-config" file that you could actually package with preferred settings BEFORE you have to run the program with Ruins installed. Ruins is just WEIRD in that it generates its own config file. I can see why it's necessary, for the biome-specific settings, but the OTHER settings I think should be in a separate file entirely. But I digress.)
I imagine that when Ruins comes out for Minecraft 1.13, I'll have to consider how my templates might mess up the wider range of "vanilla" structures that might appear during terrain-gen -- and hence I probably should expand the "blacklist" of blocks NOT to build my structures on top of. (I don't want my log cabin taking a chunk out of a super-rare Woodland Mansion, for instance.)
The other consideration would be the "block economy." So far as I can tell, most of the generic templates included with Ruins aren't going to break much in the way of "economy," since it's mostly stuff like cobblestone and planks. However, combine Lost City with Tinkers' Construct, and suddenly everyone on your server is likely to have maxed-out sharpness for their weapons, because quartz blocks (used as a resource in Tinkers' Construct, and hard to accumulate in vanilla Minecraft) are widely used as decorative blocks in Lost City. I have a number of templates that use quartz blocks (in lieu of "marble columns" for ruined temples and such), but I realize that as soon as you combine them with Tinkers' Construct, it's about as bad as if I made cottages out of iron and lapis lazuli blocks. For this reason, all my own quartz-heavy structures have "Quartz" in the template name, to make them easier to find and eliminate for anyone with such concerns -- but it's impractical for me to catalog each and every material or resource that MIGHT cause a problem if the new "economy" introduced in your modpack suddenly turns a previously decorative or junk item into a hot new commodity.
Another consideration is that if you have any mods that allow for moving of normally immobile blocks -- such as Command Blocks -- there are some potential exploits if you utilize any custom templates that introduce Command Blocks. The generic templates included with the Ruins package DO NOT utilize Command Blocks (except for a sample "tester" structure meant to highlight possibilities -- not to be used in actual terrain-gen), so that should be a moot point unless you go delving into peoples' add-on template packs. For that reason, and because of conflicts I've heard between Command Blocks and certain other mods, I've labeled all my Command Block using templates with "CB," and even arranged alternative packs that deliberately exclude them.
A while back, I heard that there was a mod that had problems with any templates that had cauldrons in it, because it replaced vanilla cauldrons with its own block, but I don't know the mod-name off top of my head.
I did some testing and here's what I found. Whenever I create a new world the files "RuinsPositionsFile.txt" and "ruins.txt" are only created in the original worlds folder. The interesting thing is all the information from the new world is still being written to those files in the directory that is original worlds. Steps I took are:
1) create a world with a name e.g. "world1", check if files RuinsPositionsFile and ruins are created in saves/world1 directory. they are.
2) exit to the title, create another world with a name "world2". Check to see if files RuinsPositionsFile and ruins are created in saves/world2 directory. They are not created. But the files in saves/world1 are being updated with the info from world2 world.
Maybe this is related to what I was posting before
I did some testing and ... all the information from the new world is still being written to those files in the directory that is original worlds.
Wow...that's a doozy, and it's an error that goes back at least as far as Minecraft 1.7.2. And you're right--that's very likely the culprit with regard to the missing path. Great find! Thanks for all the details; it's pretty easy to fix, now that you pointed it out. I'll submit a pull this evening, unless somebody beats me to it.
Hey guys i watched someone vid and looked at the files and i wondered if there was a way to code the rarity it spawns because i have a really op ruin i created but want it to be rare (i play an survival moded adventure with 15 mods)