Does anyone know of a way to have RUINSTRIGGER detect the player from a greater distance ?
RUINSTRIGGER fires when a player gets within about 72 blocks; that's hardcoded. Check out post 4505 for an alternative to RUINSTRIGGER you may find more appropriate. It works in the latest version of Ruins.
So I think the NBT tag might be too long and complex for it to parse.
Nope. Ruins should be able to handle even brobdingnagian NBT specs like that. You found a legitimate bug. To the extent a bug can be legitimate. Thanks!
EDIT: Oh, wait...that's probably not what you asked. When I hear "parser," I think the thing what parses template files. You likely meant the /parseruin command. To parse in-world blocks as teBlocks, add block IDs to the teblocks list in the config file ruins.txt:
teblocks=mob_spawner
When changing config files for an existing world, make sure you edit the one(s) in the world's save folder, not the one in the config folder. You'll also need to restart to apply the new config settings.
I would like to suggest a per-ruin override for "anyRuinsMinDistance". It would be useful for situations where you want ruins to be more prevalent in a specific biome.
Such a setting is problematic, for reasons that may not be immediately obvious. For one thing, the parameter would only specify how close a template can spawn near its neighbors, not how close it will spawn. If all other templates in the vicinity insist on a distance from them of, say, 64 blocks, having a minimum distance setting of 16 has no effect whatsoever. You'd have to have a group of several templates with lower override values for the setting to be meaningful...which would lead to another problem.
The way Ruins distributes instances of templates, the allowed distance between spawns is a factor in how frequently a particular template spawns at all. If there's a set of templates with lower minimum distances, you'd wind up with vast areas containing only those templates; templates with higher minimum distances would be exceedingly rare. True, one could carefully confine the effect to particular biomes, but it'd be incredibly fragile.
If this is a desired feature, I don't think it can be accomplished with just an anyRuinsMinDistance template override, not without overhauling the current Ruins worldgen code. Maybe biome-specific parameters could be a workaround.
On another note, is there anything wrong with just putting all your ruins files in generic and using "biomeTypesToSpawnIn" and "biomesToNotSpawnIn" to control spawning as opposed to breaking files up into the biome folders?
Well...no, but it'll take a bit of finessing to get right. The settings of biomesToSpawnIn, biomeTypesToSpawnIn, and biomesToNotSpawnIn have no bearing on generic spawning; if you set these in a generic template, it'll be eligible for both generic and biome-specific spawning, which probably isn't what you want. However, if you set the specific_xxx configuration settings to 100 for all biomes, generic spawning is essentially turned off, and you'll achieve the desired result.
Along those lines, a better idea might be to use the void biome folder as your template dumping ground instead of generic, since the void biome won't appear anywhere in your world unless you explicitly put it there, and you won't have to muck with configuration settings.
Did you try a test world with all other templates removed? I did a bit of experimenting on my own, and everything seems to be working as intended. Since I'm not able to duplicate the issue, I'd have to see the template and configuration files you're using to troubleshoot any further.
One trend in the latest releases of Minecraft is toward stricter JSON compliance. Ruins was changed in 17.2 to support this, as its original JSON parser was a bit dated and would choke in certain situations, such as when a text string contains a right brace. As a result, though, template files may have to be updated to work with this latest version. Namely, if a template contains a rule like this...
...otherwise, you'll get a whole slew of "unbalanced nesting" errors and the template won't load. The rule is: quotes should only be escaped if they appear inside a quoted string, where Minecraft itself requires. The 17.2 version of /parseruin generates templates accordingly. Unfortunately, this can't be relaxed to provide backward template compatibility without losing current and future functionality, since there's no reliable way to distinguish between intentionally-escaped quotes and incorrectly-escaped quotes.
Incidentally, the latest version of /parseruin also knocks out the x, y, and z attributes of teBlock JSON specifications, possibly leading to more compact rulesets, as noted by Jordan_Peacock a while back. You don't have to fix that if you don't want to--it won't cause errors--but it could mean you have more rules than you need.
After restarting the game spam in the log disappears. Name of world - " world." This error occurs by accident, the month was not at all))
Do you only see these errors when you start a new world? When you do see them (and exit Minecraft), is there a RuinsPositionsFile.txt file in the world folder (saves/world, probably) and each of its DIMxxx subfolders (DIM1, DIM-1, and possibly others, depending on what other mods you're using)?
If the answers to both of these is да, then I think I know what's going on, and you can ignore these logged errors--they're annoying, but nothing bad is happening as a result. If one or more of the RuinsPositionsFile.txt files is missing, though, I'm more concerned; that's how Ruins remembers where it spawned things, and the problem is of higher priority. If you see the errors even when you play in an already existing world, I'm stumped.
Also, is there some trick to getting uniqueMinDistance to work? I've set it in a bunch of my own ruins and they still seem to spawn according to global settings.
Are you trying to set it to zero, perhaps? Ruins has always interpreted uniqueMinDistance=0 (the default) as meaning no unique minimum distance is specified, so it falls back to using the global templateInstancesMinDistance setting instead. Try setting uniqueMinDistance=1 and see if that works as expected. If you really want it to be zero--and I can't think of any compelling reason why zero can't be a valid setting, aside from historical convention--Ruins will have to be modified to support it. Shouldn't be difficult.
That's the only "trick" I know of. If you're not trying to set it to zero, or setting it to one doesn't have the expected result, you're onto a bigger issue.
EDIT: It's also possible, if uniqueMinDistance is non-zero but significantly less than anyRuinsMinDistance, everything is working fine; it just looks like the template setting is being ignored because other spawned structures are forcing instances further apart. There should still be cases where two instances occur close together, but depending on how many other templates you're using and how likely they spawn, such cases might be exceedingly rare. A relatively simple way to test that theory is to generate a world with your template as the only template, and see how far apart they spawn.
This is the same error you posted last month, except now it's in Russian (using code page ISO-8858-5: "Системе не удается найти указанный путь"). Unfortunately, I can't recreate the error myself, so I don't know how much help I can be. The problem is it doesn't seem to be able to find the path to your world folder (or one of the dimension folders--it's impossible to tell) when it's trying to create RuinsPositionFile.txt . Can you try running from the launcher to see if you still have the problem? Is anybody else out there getting this error?
I'm curious if there is any further explanation of the "Spawned ruins no longer float above the ground" bit? (Under what circumstances was that happening, per se?) I'd also be curious to learn what changes have been made to terrain leveling.
This was a reference to the first 17.2 change, made way back in May in response to a user-posted issue. It's hard to characterize exactly how and when the problem manifested itself, as a number of errors were involved. Most obvious was Ruins rounding up (to the next higher altitude) when determining average surface level rather than rounding off (to the nearest altitude), causing spawned structures to often be precariously perched on one or two blocks that happen to poke above the surrounding landscape instead of settling comfortably onto the ground. Have a look at the pull request comments and see if that helps explain things. It's kind of a grab bag of sundry bug fixes related to surface finding and terrain leveling.
Leveling looks...better, maybe? I think it's always going to be a tad flaky, though. Kind of like me. Maybe some experimentation is in order; I notice a lot of templates disable leveling (for perfectly understandable reasons), so it doesn't get exercised often enough--also, kind of like me--to be thoroughly vetted.
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.
Hitting blocks with a stick is just a way to find out what they are; it's not a required step in building a template. If you use /parseruin on a structure containing blocks from other mods, it'll work fine. If you already know the block names and manually edit them into the template file, that'll work, too. You don't have to do anything special.
Having said that...Ruins version 17.2 has an important bug fix affecting how teBlocks (i.e., blocks with TileEntities) are handled, and I don't believe it's been officially released yet. If the mod blocks you're interested in don't have TileEntities--that is, basic, non-functional things like dirt or stone or wood--you're probably good to go. If they're more complicated, however, such as machines or containers, you'll want to either wait for 17.2 or pull the latest code and build it yourself.
Also, keep in mind not all mods implement their new blocks correctly or completely. You may find some blocks aren't properly oriented when a template is rotated, in which case you should notify the offending mod's author: it likely means method Block.withRotation() (and possibly TileEntity.rotate()) needs to be overridden in the new block class(es). This is necessary even for vanilla Minecraft structure rotation to work, so there's incentive to comply.
No. However, what you can do is import an MCEdit schematic into a world and then use the /parseruin command to create a Ruins template from it.
After you import the schematic, build a 1-block thick, rectangular platform under the structure out of some "unusual" material--e.g., lime wool blocks. It should be something that doesn't appear in either the surrounding landscape or the base of the structure. Enter the following command:
/parseruin mybuilding
then break one of the blocks of the platform you built. If everything went well, you get a file config/ruins_config/templateparser/mybuilding.tml . Of course, you should change the name "mybuilding" to something more appropriate.
I'm not able to duplicate the problem you're having, so I'm guessing it's got something to do with the environment you're running in. The specific error you logged indicates Ruins is unable to create a file (namely, "RuinsPositionsFile.txt_writing") in either the saves/world1 directory or one of its DIMxxx subdirectories. Maybe a permissions problem preventing file creation? Or the disk is full?
Uh, oh. The command block chain method should work--and does in vanilla structures, which was all I was able to test at the time I originally posted--but apparently doesn't with Ruins templates. I'll have to look into that.
EDIT: I submitted a pull request to fix the problem; if and when that goes through, the method I described above will work. For example:
0
RUINSTRIGGER fires when a player gets within about 72 blocks; that's hardcoded. Check out post 4505 for an alternative to RUINSTRIGGER you may find more appropriate. It works in the latest version of Ruins.
0
Nope. Ruins should be able to handle even brobdingnagian NBT specs like that. You found a legitimate bug. To the extent a bug can be legitimate. Thanks!
EDIT: Fix submitted.
2
You have full control of any tile entity (i.e., specify NBT data) when using a teBlock block. Roll your own mob spawner with, for example:
rule1=0,100,teBlock;mob_spawner;{SpawnPotentials:[{Entity:{id:"cave_spider"},Weight:1},{Entity:{id:"spider"},Weight:2}],SpawnCount:3,SpawnRange:2,MinSpawnDelay:100,MaxSpawnDelay:200,Delay:-1}
EDIT: Oh, wait...that's probably not what you asked. When I hear "parser," I think the thing what parses template files. You likely meant the /parseruin command. To parse in-world blocks as teBlocks, add block IDs to the teblocks list in the config file ruins.txt:
teblocks=mob_spawner
When changing config files for an existing world, make sure you edit the one(s) in the world's save folder, not the one in the config folder. You'll also need to restart to apply the new config settings.
0
Such a setting is problematic, for reasons that may not be immediately obvious. For one thing, the parameter would only specify how close a template can spawn near its neighbors, not how close it will spawn. If all other templates in the vicinity insist on a distance from them of, say, 64 blocks, having a minimum distance setting of 16 has no effect whatsoever. You'd have to have a group of several templates with lower override values for the setting to be meaningful...which would lead to another problem.
The way Ruins distributes instances of templates, the allowed distance between spawns is a factor in how frequently a particular template spawns at all. If there's a set of templates with lower minimum distances, you'd wind up with vast areas containing only those templates; templates with higher minimum distances would be exceedingly rare. True, one could carefully confine the effect to particular biomes, but it'd be incredibly fragile.
If this is a desired feature, I don't think it can be accomplished with just an anyRuinsMinDistance template override, not without overhauling the current Ruins worldgen code. Maybe biome-specific parameters could be a workaround.
Well...no, but it'll take a bit of finessing to get right. The settings of biomesToSpawnIn, biomeTypesToSpawnIn, and biomesToNotSpawnIn have no bearing on generic spawning; if you set these in a generic template, it'll be eligible for both generic and biome-specific spawning, which probably isn't what you want. However, if you set the specific_xxx configuration settings to 100 for all biomes, generic spawning is essentially turned off, and you'll achieve the desired result.
Along those lines, a better idea might be to use the void biome folder as your template dumping ground instead of generic, since the void biome won't appear anywhere in your world unless you explicitly put it there, and you won't have to muck with configuration settings.
0
Did you try a test world with all other templates removed? I did a bit of experimenting on my own, and everything seems to be working as intended. Since I'm not able to duplicate the issue, I'd have to see the template and configuration files you're using to troubleshoot any further.
1
One trend in the latest releases of Minecraft is toward stricter JSON compliance. Ruins was changed in 17.2 to support this, as its original JSON parser was a bit dated and would choke in certain situations, such as when a text string contains a right brace. As a result, though, template files may have to be updated to work with this latest version. Namely, if a template contains a rule like this...
rule1=0,100,teBlock;minecraft:flower_pot;{Item:\"minecraft:sapling\",Data:1,id:\"minecraft:flower_pot\"}-0
...it'll have to be modified to unescape the quotes (i.e., remove the backslashes), as in...
rule1=0,100,teBlock;minecraft:flower_pot;{Item:"minecraft:sapling",Data:1,id:"minecraft:flower_pot"}-0
...otherwise, you'll get a whole slew of "unbalanced nesting" errors and the template won't load. The rule is: quotes should only be escaped if they appear inside a quoted string, where Minecraft itself requires. The 17.2 version of /parseruin generates templates accordingly. Unfortunately, this can't be relaxed to provide backward template compatibility without losing current and future functionality, since there's no reliable way to distinguish between intentionally-escaped quotes and incorrectly-escaped quotes.
Incidentally, the latest version of /parseruin also knocks out the x, y, and z attributes of teBlock JSON specifications, possibly leading to more compact rulesets, as noted by Jordan_Peacock a while back. You don't have to fix that if you don't want to--it won't cause errors--but it could mean you have more rules than you need.
0
Do you only see these errors when you start a new world? When you do see them (and exit Minecraft), is there a RuinsPositionsFile.txt file in the world folder (saves/world, probably) and each of its DIMxxx subfolders (DIM1, DIM-1, and possibly others, depending on what other mods you're using)?
If the answers to both of these is да, then I think I know what's going on, and you can ignore these logged errors--they're annoying, but nothing bad is happening as a result. If one or more of the RuinsPositionsFile.txt files is missing, though, I'm more concerned; that's how Ruins remembers where it spawned things, and the problem is of higher priority. If you see the errors even when you play in an already existing world, I'm stumped.
1
Are you trying to set it to zero, perhaps? Ruins has always interpreted uniqueMinDistance=0 (the default) as meaning no unique minimum distance is specified, so it falls back to using the global templateInstancesMinDistance setting instead. Try setting uniqueMinDistance=1 and see if that works as expected. If you really want it to be zero--and I can't think of any compelling reason why zero can't be a valid setting, aside from historical convention--Ruins will have to be modified to support it. Shouldn't be difficult.
That's the only "trick" I know of. If you're not trying to set it to zero, or setting it to one doesn't have the expected result, you're onto a bigger issue.
EDIT: It's also possible, if uniqueMinDistance is non-zero but significantly less than anyRuinsMinDistance, everything is working fine; it just looks like the template setting is being ignored because other spawned structures are forcing instances further apart. There should still be cases where two instances occur close together, but depending on how many other templates you're using and how likely they spawn, such cases might be exceedingly rare. A relatively simple way to test that theory is to generate a world with your template as the only template, and see how far apart they spawn.
1
This is the same error you posted last month, except now it's in Russian (using code page ISO-8858-5: "Системе не удается найти указанный путь"). Unfortunately, I can't recreate the error myself, so I don't know how much help I can be. The problem is it doesn't seem to be able to find the path to your world folder (or one of the dimension folders--it's impossible to tell) when it's trying to create RuinsPositionFile.txt . Can you try running from the launcher to see if you still have the problem? Is anybody else out there getting this error?
1
This was a reference to the first 17.2 change, made way back in May in response to a user-posted issue. It's hard to characterize exactly how and when the problem manifested itself, as a number of errors were involved. Most obvious was Ruins rounding up (to the next higher altitude) when determining average surface level rather than rounding off (to the nearest altitude), causing spawned structures to often be precariously perched on one or two blocks that happen to poke above the surrounding landscape instead of settling comfortably onto the ground. Have a look at the pull request comments and see if that helps explain things. It's kind of a grab bag of sundry bug fixes related to surface finding and terrain leveling.
Leveling looks...better, maybe? I think it's always going to be a tad flaky, though. Kind of like me. Maybe some experimentation is in order; I notice a lot of templates disable leveling (for perfectly understandable reasons), so it doesn't get exercised often enough--also, kind of like me--to be thoroughly vetted.
3
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.
0
Hitting blocks with a stick is just a way to find out what they are; it's not a required step in building a template. If you use /parseruin on a structure containing blocks from other mods, it'll work fine. If you already know the block names and manually edit them into the template file, that'll work, too. You don't have to do anything special.
Having said that...Ruins version 17.2 has an important bug fix affecting how teBlocks (i.e., blocks with TileEntities) are handled, and I don't believe it's been officially released yet. If the mod blocks you're interested in don't have TileEntities--that is, basic, non-functional things like dirt or stone or wood--you're probably good to go. If they're more complicated, however, such as machines or containers, you'll want to either wait for 17.2 or pull the latest code and build it yourself.
Also, keep in mind not all mods implement their new blocks correctly or completely. You may find some blocks aren't properly oriented when a template is rotated, in which case you should notify the offending mod's author: it likely means method Block.withRotation() (and possibly TileEntity.rotate()) needs to be overridden in the new block class(es). This is necessary even for vanilla Minecraft structure rotation to work, so there's incentive to comply.
1
No. However, what you can do is import an MCEdit schematic into a world and then use the /parseruin command to create a Ruins template from it.
After you import the schematic, build a 1-block thick, rectangular platform under the structure out of some "unusual" material--e.g., lime wool blocks. It should be something that doesn't appear in either the surrounding landscape or the base of the structure. Enter the following command:
then break one of the blocks of the platform you built. If everything went well, you get a file config/ruins_config/templateparser/mybuilding.tml . Of course, you should change the name "mybuilding" to something more appropriate.
1
@kellixon:
I'm not able to duplicate the problem you're having, so I'm guessing it's got something to do with the environment you're running in. The specific error you logged indicates Ruins is unable to create a file (namely, "RuinsPositionsFile.txt_writing") in either the saves/world1 directory or one of its DIMxxx subdirectories. Maybe a permissions problem preventing file creation? Or the disk is full?
0
Uh, oh. The command block chain method should work--and does in vanilla structures, which was all I was able to test at the time I originally posted--but apparently doesn't with Ruins templates. I'll have to look into that.
EDIT: I submitted a pull request to fix the problem; if and when that goes through, the method I described above will work. For example:
dimensions=2,1,1
rule1=0,100,teBlock;command_block;{auto:1b,Command:"say YOLO!"}-1
rule2=0,100,teBlock;chain_command_block;{auto:1b,Command:"fill ~ ~ ~ ~ ~-1 ~ air"}-1
layer
1
endlayer
layer
2
endlayer