All users will need to merge their Minecraft Forum account with a new or existing Twitch account starting October 23rd. You can merge your accounts by clicking here. Have questions? Learn more here.
Dismiss
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Mixcraft HD - JRoush Update 4
    for Minecraft 1.8 and prereleases

    Download from Mediafire

    Another update, with some tweaks and fixes and new HD textures.

    Changes & screenshots:

    • Support for random rotations
    • In particular, the grass and netherrack textures have been heavily tweaked:



    • Ocean Monuments


    • Rabbits


    • HD Menus
    • For the Brewing Stand, Enchanting Table, Anvil, and Horse Inventory


    • Alternate Packs
    • I mentioned the changes to the Layered Sandstone in my last post. I've also changed the Iron Floor Plate. On reflection I agree with BerenSaelor that the rural theme is appropriate, I just don't like extreme specular contrast of the current texture.



    Quote from Cat121

    I was minding if someone already thought about making an extension of mixcraft for extrabiomesXL ?

    At the moment I don't have any plans to make textures for mod-added blocks and items. That may change once Forge stabilizes on 1.8 and I start using mods again. Until then, you might be able to find some HD (32x32) textures in other texture packs - I know that vattic's Faithful pack supports some popular mods. Good luck!
    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Just checking in again - I am currently working on another update. It should include the block textures added in the latest snapshot (Ocean monuments) as well as a few other odds and ends. For example, here is the new Anvil GUI:


    I'm considering starting a new forum thread for the next release. With Koolwitak gone we can't update the title or OP and I don't like making people hunt to find the latest version.

    @BerenSaelor and master_noj: thanks for the feedback - I really appreciate the time and thought you both put into the proposed changes. It sounds like the response is mixed and that is exactly the reason I asked.

    The Obsidian, Iron block, Redstone Lamp, and Ore proposals are all tailored to my particular use case (i.e. I build lots of redstone machines and use ore mods :P). I'm not in any rush to incorporate these proposals; they may stay as alternates indefinitely. I'll try playing around with them some more - particularly the iron block.

    The proposed Portal texture is actually an old Mixcraft alternate (credit where due). I'll wait on this one too, as there are some further tweaks I'm hoping will be possible once all of the dust settles from the 1.8 update.

    Given the positive response, I'll incorporate the softer cobblestone as the default cobble texture unless someone objects.

    The last proposal is the sandstone. I am really happy with the way it turned out - to the point that I actually took a break just to build things with it in my test world, something I never do. I like the warmer feel which of course is mostly due the the high color saturation. It does clash with the sand though, and I've been considering how to handle that. For now I've tried increasing the saturation of the sand itself:
    Mixcraft:

    Latest Proposal:

    Side-by-side:
    I've never had any problem with the current sand texture, but then again Mixcraft is supposed to be about vibrant colors. Any thoughts?
    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Mixcraft HD - JRoush Update 3
    for Minecraft 1.8.x and prereleases

    Download from Mediafire

    Thanks once again to BerenSaelor for his help.

    In addition to some new textures, this update includes a number of Alternates. These are self-contained resource packs that just replace one or two textures. They can be found in the alternates folder of the archive. To use the alternates, extract them into your resourcepack folder alongside all of your other texture packs, and then select them in the in-game menu.

    Changes & screenshots:

    • Textures for granite, diorite, and andesite


    • Iron Golem by BerenSaelor


    • Alternate Super-HD Horse Textures by BerenSaelor
    • These can be found in the alternates folder inside the archive.


    There are a number of textures in Mixcraft that I would like to replace. Unlike all the changes I have made so far, however, these would be purely aesthetic changes. Before I commit to them I'd like to gather some feedback. Anyone who is interested should take a look at the proposed changes below. They are also included as alternates so you can try them out in-game. Let me know what you think.

    Proposed Changes:

    • Softer Cobblestone (from Inspiration by TobiwanK3nobi)
    • I really prefer lower contrast for blocks that get used over large areas.


    • Layered Sandstone


    • Black Obsidian


    • Smooth Paper Lamp


    • Distinct Ores
    • This gives each ore it's own shape as well as color. Iron is dark brown to distinguish from mod-added ores like tin and silver.


    • Floor-plate Iron Block


    • Quiet Nether Portals
    • In addition to the smoother texture, this makes the ambient portal noises much quieter.


    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    OK, I'm back playing minecraft again after working on other things for a few weeks. I have textures ready for all of the new blocks in the 1.8 snapshots. I should have another update out in the next few days.

    Quote from BerenSaelor

    and now i also got the horse textures and armor-textures done. you can find them here https://www.dropbox.com/sh/adu6dyw33zffj1k/IoYvFEOLBp

    Update:
    now also with horse skeleton (the only high def skeleton-horse texture i know :D )
    Thanks! I've added the golem, and the horse textures will appear as alternates. It's a shame most people won't be able to see the skeleton horse anytime soon :(.

    Quote from Lejonell

    The only things that bugs me in this texturepack is the chiseled sandstone/brickstone and smooth sandstone. They dont match the Mixcraft original. I wish I had the editing skills to change that.
    I agree; the sandstone textures in general are kind of a mess. I have new sandstone textures lined up, in fact I have replacements for a bunch of textures that I've never been happy with. They should appear in the next update.
    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Mixcraft HD - JRoush Update 2
    for Minecraft 1.8.x and prereleases

    Download from Mediafire

    Another update, this time targeting the 1.8 prereleases. Many thanks to BerenSaelor for his help with the zombie villager and witch textures!

    One thing to note: because of the addition of clothing layers to the player skin, the new Steve skin in this pack is not compatible with MC 1.7 or prior. You can still use the pack with 1.7, but the player character will look weird.

    Changes & screenshots:

    • Fixed numerous glitches in existing textures, including the spacing of the HD font.


    • Tweaked biome color maps to make plains/forests greener and deserts browner.


    • HD Mob skins (horses, witches, bats, zombie villagers)



    • HD GUI textures (creative menu, crafting menu, main menu panorama)



    Quote from BerenSaelor

    if you are able to provide your horse textures as png i would do my very best to make them 512x512

    Obviously you can find them in the update :) . I'm pretty happy with them, but they are quite similar to vanilla textures so if you want to rework them to something unique (and higher def.) then go right ahead! Beyond that, I believe we still need HD textures for the Iron Golem and Magma Cube (the golem is technically HD, but is basically identical to the vanilla texture). I'm planning to do the new stone blocks and the rest of the missing container GUIs next.
    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Quote from tachohentai

    thank you :)

    You're welcome! Don't be shy about adding new textures yourself either - I'll take all the help I can get.

    Quote from BerenSaelor

    added under the same link all horse armor. let me know what you also need. i have the time and the tools to do some more!

    That is very beautiful armor! Unfortunately, it might be *too* beautiful. Minecraft requires all horse skins, markings, and armor to be the same size and my horse textures are all 256x256. I also just finished my own set of horse armor last night. If you think you can create a good 256x256 version of your armor (or alternatively, 512x512 versions of the other horse textures) then we could include both! You can find my working file for horse textures here if that helps.
    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Quote from BerenSaelor

    i made the witch and the zombie-villager so far but want to add the rest that is missing in the next days :D
    you can find my works here https://www.dropbox.com/sh/adu6dyw33zffj1k/IoYvFEOLBp plz incorporate them in your update 2 then...

    Thanks! I've added the witch and zombie villager for the next update. Let me know if you plan to work on anything else so that I don't duplicate your efforts :).

    Also coming up ...


    I'll be releasing another update will be within the next week. It will add horses and a number of other things.
    Posted in: Resource Packs
  • 0

    posted a message on MultiMC 5 [Windows / Linux / Mac]
    Just wanted to pop in and says thanks to the devs for maintaining this tool. It's been extremely useful for me.
    Posted in: Minecraft Tools
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    Mixcraft HD - JRoush Update 1
    for Minecraft 1.7.4

    Download from Mediafire

    This is an update to the latest released version of Minecraft. I have made a lot of changes, adding new HD textures for nearly everything that was missing one. The highlight is probably the new HD textures for all of the flowers and trees added in the biome update and an overhaul of the biome color maps. The complete change log is included with the pack.

    There are still some gaps that need to be filled. The biggest are the missing HD textures for newer mobs: witches, zombie villagers, horses, and horse armor. A lot of the newer menus (enchanting, trading, etc.) also do not have HD textures yet. I am planning to add all of these, as well as the textures from the latest snapshot, at a later date. If anyone else has made or wants to make HD versions of these textures, please do post them.

    Many thanks to Koolwitak for his original work and to Tachohentai for keeping the pack alive for the past year. Hopefully I can do as well.

    Screenshots



    Posted in: Resource Packs
  • 0

    posted a message on [32x,16x][1.3.1] Mixcraft - SemiRealistic (v47) Emeralds and Trip Wires!
    FYI for those who check on this thread from time to time: I am in the process of updating this pack myself. I should have it up to date (for MC 1.7.4) some time in the next week.

    For now, here is a preview of my colored glass and hardened clay textures:
    Posted in: Resource Packs
  • 0

    posted a message on [1.4.6]v2 Custom Ore Generation (updated Jan. 5th)
    Quote from CafeAvec

    Welcome back JRoush.
    I have been missing your mod, as it makes my undergrounds so much more realistic. I appreciate that alot.
    Thanks :)

    Quote from Keybounce

    I'd like to know how to modify the large caves to get a second, "almost identical" cave with a very, very tiny level of noise.

    Specifically, I'd like to run the stock supplemental caves, followed by one that occasionally adds one extra block on the outside. This would be used to change "stone" to "water", or "stone" to "lava".
    You should be able to use the same technique I used for gem "pipes". Give the cave veins an explicit seed and then create a second vein distribution with the same seed and setting values. Increase the segmentRadius for the second vein by 1, set it to replace stone with lava/water, and play with its oreDensity until you get the right effect.

    Quote from Veovis Muad

    What's the best option for removing biome restrictions on clouds and veins without destroying balance? I'm helping set up a server running Biomes O Plenty and I don't believe the default configs support it, and the iron and gold clouds being limited to specific biomes will be an issue I think.
    If you want to remove biome restrictions you will probably need to make the ores less common to preserve balance. After you have removed the <Biome> tags, I would reduce most of the cloud frequencies by 80%. Emerald should probably be reduced more, say by 90%, and diamond should not be changed at all because it has no biome affinity. This is about as low as you can set the frequencies before individual clouds get too hard to find and players start to hate you. You should playtest at this point and try to gauge the balance for yourself. For ores that are still be too common you can reduce the size of their clouds (suggest reducing by 10% at a time).

    The alternative is to add the Biomes O Plenty biomes to the existing constraints. This is annoying, but if you can get your hands on the list of internal biome names then it shouldn't be much more work. Having clouds limited to specific biomes gives players some control in how they search for a specific ore. It still mostly boils down to luck, but a little control goes a long way to alleviating frustration and boredom. If you can elaborate on iron and gold being an issue I might be able to offer more helpful advice.

    Quote from spiderking1008

    Does this work with netherrocks and simpleores?
    COG will work fine with those mods, but it won't touch the ores from them unless you configure it to do so.

    Quote from malice3672

    I use COG 1.4.6v2 and Mystcraft 0.10.1.00 and just want to confirm that the dense ore symbol isn't working with COG and that COG isn't adding symbols for ores. I have a "hack" to work around this issue, I use the options file for my world and change the oreFreq to 2, 3, 4 ect when I have dense ores in the world I will be in.
    You can create separate option files for each Mystcraft age - put them in the dimension folder and they will set the option values just for that dimension. Beyond that I am afraid that there is no elegant solution. Once I have Mystcraft support back up and running you will be able to use the COG ore symbols, but the author of Mystcraft specifically asked me not to make COG aware of the regular "Dense Ores" symbol so support for that simply isn't possible.


    I just made a new config file for thermal expansion that has my combined distribution options. My question is now that I have added this new file, new worlds I'm sure will work correctly, but my old world's option file does not have my new thermal expansion related option in it. Can I just manually add them to this file? will this work at all?
    You can manually add options to the options file. Make sure to spell the option name correctly :)
    Posted in: Minecraft Mods
  • 0

    posted a message on [1.4.6]v2 Custom Ore Generation (updated Jan. 5th)
    Quote from Sheldor01

    With this mod installed are quarries still effective?
    Quarries (both the manual kind and automatic ones from Buildcraft/Redpower/etc) tend to mine out large rectangular sections of the world. This works fine with for ores in a Cluster distribution. It works really well for ores in a Cloud distribution, assuming you find a cloud to put the quarry in. It doesn't work well at all for ores in Veins, because veins tend to curve around and any quarry large enough to mine one would be very inefficent. So yes, quarries can still be effective but you might need to be more strategic about where and when you use them.

    Quote from Keybounce

    When you talk about the intended curvature, and your design of a given height limit for the different ores, what was the design intention, what was the plan, etc? Since I'm altering branch length, and running into those "vertical distance from motherlode" limits without realizing it, how were they intended to work?
    The curvature of a vein branch is, roughly, how much it bends over its entire length. Branches can only bend between segments, so the curvature increases as you add more segments because the branch bends more often. If you want to scale the branch up in every dimension while keeping the same basic shape then you need to keep the segment count the same by increasing segment length too. Alternatively, you could lower the segment angle for a similar effect.

    The oreSize option was supposed to do this, but as I said it started to run afoul of the height limitations. Branch height limits were added early on to the Vein algorithm. I felt it was important to keep ores segregated by height underground so that players could prioritize where they wanted to dig by what ore they needed. Biome-specific distributions hadn't been added yet, so this was the only way to add some strategy to mining. Vanilla MC does this too, and many people unconciously expect it. I've since changed the standard distributions to use vertical veins for some ores, (variety is important too), but of course those are limited by ground height. Either way, the height limits don't scale well.

    If you want to make horizontal veins longer - and have them actually be longer - you need to either increase their alloted height limit or make them more horizontal. You can flatten out the angle at which branches leave the motherlode (reduce BranchInclination) and/or reduce the overall curvature (increase SegmentLength or decrease SegmentAngle by more than you increased BranchLength).
    Posted in: Minecraft Mods
  • 1

    posted a message on [1.4.6]v2 Custom Ore Generation (updated Jan. 5th)
    Update: I have resolved my computer troubles for the time being, so everything is more or less back to normal.

    It's been about 2 months since I did any serious work on the mod. I haven't been idle in the meantime, and I'd like to wrap up what I'm doing now before jumping back into COG. I was also in the middle of a config parser overhaul when everything went down, so I'm afraid it will take me some time to tie up the loose ends and get out a useable update for MC 1.5.

    I appreciate everyones patience, and my thanks to Keybounce for answering a lot of questions over the last few weeks.

    I'll be trying to catch up to unanswered questions below. There are a lot of them, so I've wrapped it in a spoiler:


    Quote from Keybounce

    May I please request official support for an ore length factor?

    Right now there's frequency, and size.
    "Length" would permit more common, smaller veins.
    "Size", which supposed to be cubic in it's effect, only really has that effect on large segment radius veins.

    EDIT: I just re-read the presets. Make that Linear for clusters, squared for veins, and cubic for clouds and vein motherlodes. Odd mix.
    The oreSize option affects clouds, clusters, and vein motherlodes in a cube fashion.
    It was intended to affect vein branches in the same way, but I eventually settled for making it scale the branch radius only, leaving the length unchanged.

    The reason is that branches have a very complex shape. The limiting factor on branch length is very often not its BranchLength setting, but rather how far it can go before it hits ground level, the bottom of the map, or the upper/ lower BranchHeightLimit. In order to actually make branches longer you would need to scale the height limits, but of course you are still constrained by the ground level. Also, in order to preserve the intended curvature of the branch you would need to adjust the SegmentLength or the SegmentAngle settings. At the time I was writing the presets I simply didn't want to go down that rabbit hole.

    Keep in mind that the shape of the distributions affects how easily they are discovered in subtle and hard-to-quantitfy ways. Even if I had arranged for an exact cubic relationship between oreSize and ore quantity (not sure I can, unfortunately), changing oreSize would still have unpredictable effects on balance.

    Quote from Keybounce

    I had thought that a normal vein, with the standard config, would be a solid vein; the wireframes certainly look solid.

    What I found, was a surprise:

    ...

    I was digging out a gold vein today, trying to understand what I was not seeing. I knocked the oreSize up to 2, which was enough to force the gold to be constant without interruption. I then dug out around the vein, and started shrinking the oreSize ("cogPopulate", gotta love it). Even at 1.25 I was seeing skips. And, I realized: if it is curving slightly, rather than curving strongly, then the chance of a curve managing to miss potentially several blocks is actually 100%.

    I looked at some of the wireframes where it was curving, where spots were being skipped. Since the diameter must be below one, if the curve is "mostly lined up" with one of the 4 block directions, it will slide between the centers, and go a long ways without being seen.

    Turns out, I've missed quite a lot of ores.
    It is possible (and fairly common) for narrow veins to "miss" the center of several consecutive blocks, resulting in breaks in the vein. Checking for intersection with the block center is the simplest possible form of rasterizing a continuous shape. I chose it because it is fast and relatively simple to implement. The are plenty of more complex rasterization methods that might avoid this issue, but they are more complicated. Someday, maybe, I can implement one of them, but it's pretty low on the list at the moment. For now, broken veins are just a "feature" that adds some challenge.

    Quote from Keybounce

    Requests:

    1. The ability to add a new option to the config, and have that option get saved out to the dimension's option file. Right now, if a new option is defined, then new worlds get that option's new default value saved, but old worlds do not. This means that if a config file is going to maintain compatibility, it has to determine "Did this world even have this value or not, in which case I have to assume the default is an unstated value based on how old that option file is", versus "Did this default come from this config file, and is now saved in that option file"?

    Of course, so far I can only figure out how to do this if I can get a version number out of the option file. Which brings up #2:

    2. The ability to force ages (or other dimensions) to get an option file, even if they do not have a dimension specific config file. In other words, when a dimension is loaded, (and this is documented behavior but it is strange behavior), an option file for that dimension is only generated if that dimension has a dimension specific config file, not if it uses the normal default config file. The result of this is that all mystcraft ages (tested 2 so far) have no config file, and so no option file, by default, and any age-specific random choices are not saved anywhere. This means that issue #1 above has to be determined for EVERY option for every age.


    Right now, I have one version of config file, so I can recreate everything, if I'm careful with my world.nextRandoms. That's kinda hard. It's like the fragile base class problem -- if one of my config files wants to use a new random number at some point, what happens to the next config file in the OptionalImport sequence?
    These are both possible under the new config parser I wrote back in March. I can't guarantee it will appear in the next version, but once I get everything back on track they will definitely change for the better.

    Quote from Keybounce

    So a question on "cogPopulate".

    Over at Dynamic Maps, Mike Primm had the problem that it was chewing up massive amounts of memory and CPU, more than should be expected. What he found was that the chunks being loaded into memory were activated and made live, and then unloaded; this triggered all sorts of increased CPU, increased memory, and increased activity of mods. He found a way to load the chunks into memory without activating them, eliminating all the secondary effects of them being loaded, taming the memory consumption and eliminating any attempt by other mods to play with the chunks.

    I'm curious if you can do the same with cogPopulate. You have to generate/load the chunks, fine. You have to alter the blocks in them. And then save the chunks out. But is it possible to do this without activating all the chunks as well?
    Quote from Keybounce

    JRoush, while I don't expect to see this for 146/147, a nice feature would be an explicit "cogReleaseChunks" command to release chunks loaded by cogPopulate.
    One of the reasons I avoid extending/polishing/advertising the /cogPopulate command is that I have very little control over how Minecraft handles chunks. I'm not sure what you mean by loading chunks without activating them, but it's highly unlike to help in this case because, as you said, I have to modify the chunks. This marks them as "dirty", which is part of the reason MC is so reluctant to release them once loaded (saving chunks to disk is very slow and so MC will save a few at a time). At the moment I don't even know how to force MC to unload chunks, or if it is even possible without editing base classes. I totally agree that the command is a bear to use and would be really convenient if I could make it more reliable, but I just don't have the time for it at the moment. To be honest, forced chunk (re)generation should probably be it's own mod.

    Quote from Keybounce

    Now, the big question: As I said, worlds 4 and 5 are identical. Duplicated the agedata files to create. Same seed, same everything. The distributions used have the same seed. Yet running distributions that are completely unchanged between them -- redstone and lapis -- yield numbers that are not even close. What am I missing? What is going on that I'm not aware of?
    The dimension ID is an input to the RNG (along with world seed and the distribution seed) which determines where distributions are placed. So different dimensions will always generate differently. If the same distributions are used in both dimensions - and the dimensions do not differ in other ways like ground height, available biomes, etc. - then the amount of ore placed should be similar on average. How large of a sample you need to get a good average depends on the variance of the ground height, biomes, etc. My tests in the overworld suggest that you need at least 10-20 thousand chunks to get a moderately good sample of biomes and thus of overall ore density.

    Quote from Keybounce

    *** There is a design flaw with world.nextRandom! As long as the sequence is constant based on usage counts, then any given file that wants to use this must never change the total number of calls made.

    In other words, if you want to rely on a given sequence, then not only do you have to make sure that the total number of times you call it is constant, but also that the total number of times that EVERY other config file calls it is constant.

    No config file/module that does not currently use a random number can start to use them in an update, otherwise any other module that does will be thrown off.

    This is the fragile base class problem to an extreme; it effectively makes world.nextRandom unreliable. In particular, there is no way to save the choice being made during this config file's use of world.nextRandom, and if you have anything that does use world.nextRandom, then be aware that this config will alter your random sequence.
    Not just the same number of calls; they have to be used in the same order too. This is a problem with all pseudo-random number generators, and it's the reason why every little change to world generation causes "chunk errors" where old and new chunks don't match up properly. I don't like world.nextRandom, and I have plans to add something different that will allow stable pseudorandum number generation in the future.

    Quote from Keybounce

    Bug report: StandardOreSubstitute uses 'oreRedstone' instead of the number.
    Additionally, it probably should include silverfish eggs if you have emerald veins.
    The use of 'oreRedstone' is intentional. I can't use it in the distributions because it matches both lit and unlit redstone ore, but here that is fine. Lit redstone ore isn't a natural spawn, but if it is present then we do want to remove it.

    We can't remove silverfish eggs because they spawn naturally in strongholds and we don't want to mess with that. Remember that StandardOreSubstitute is intended to run only once, when chunks are first generated, to clear out vanilla ore clusters. Using it to create a blank slate with /cogPopulate is convenient, but not what it is designed for.

    Quote from Epidemia78

    I used this mod to remove all of the xycraft crystals from the world entirely and relocate the ugly and mostly useless xychordium ores to the nether where they should always have been from day 1. Thanks!
    You're welcome :). This sort of use is exactly what I wanted for the mod.

    Quote from Gotthard

    All right, that has helped some, but now I can't get it to place any other ore blocks. I have traincraft installed, and I want sand oil close to the surface in a cloud, and petroleum deeper in another elliptical spheroid. I have tried to give it the name on the mod config file, the block name that NEI outputs, and the block number (there is no metadata) but nothing has worked.
    The blockID (246 in this case) is the "foolproof" way, so stick with that for now. Your config looks fine (excepty for RP2Substitute at line 121, you should change <Replaces block='rpores'/> to <Replaces block='246'/>). You said that you can see the polygon (I assume you mean the wireframe model) in the right place, but no ore is present. Is this a new world, or an older one? If its an older world, make you are you trying this out in freshly generated chunks. If that is not the problem, post a reply and I will do my best to help.

    Quote from Veovis Muad

    Alright, I've been playing around with things, kind of annoying that there's not a -v flag with cog options. I'm used to any command-line work that takes longer than two seconds having a verbose option so I can actually see progress and note if the process freezes.
    The /cogPopulate command is pretty rough around the edges - see my reply to Keybound above. Since it's so unreliable, I really don't recommend using it for more than a few thousand chunks (range ~ 25) at a time. That should run pretty fast - it's the memory useage you really have to be worried about :P.

    Quote from DLBerge

    GOD I've created a monster.... Now that I'm using BC, IC2 & all the addons I have so many ores to keep track of and mine for its left me with a hollowed out world. Dreaming of the day we hit 1.6 so I can pull my hair out creating config files for all this. Or steal them from Keybounce. LOL Well back to cheating for now (a little bit at least).
    I know what you mean. Even with just Redpower and Thaumcraft my world starts to look a little like swiss cheese after mining.

    Quote from ViaknarRakenshid

    Yes you are and sorry I could have been a bit more clear. Let me try again to explain.

    Okay so I first used this on the FTB pack Direwolf which had redpower so when it was the only one that was not disabled by defalut(I'm thinking that COG has an automatic disableing feature if it finds 2 or more of the same ore.) and while I was playing that i was fine. Then I swiched to Divinerpg pack and then added some more mods and this was one of them for the better ore gen. I soon relized that all of the copper and tin for Thermal Ex., IC2(which i removed ic2 now), and forestry was disabled by defalut whenever I played. So i just turned veins on in the world options. When I decided to get some friends playing I made the server and tried to fix this and since then I have not found out why they are disabled. I tried some trial and error of changing and removing etc etc. I have still not found out what is causing these mods to be disabled by defalut other then it may be in there on the configs in order to make it so that only 1 coopper and 1 tin would go. Now why it only lets redpower work is beyond me. I looked and everything seems exaclty the same. I was thinking about searching for tutorials to help me understand how the configs work in full and then maybe I can figure out what is going on.

    I will await a reply to see if you can help me with this confusing problem.
    COG does not forcibly disable RP2/IC2/Forestry ores. It does check if the ores are registered, though. Since you downloaded these mods together in a mod pack, it is likely that the pack author configured the mods individually so that only RP2 ores were registered. You need to open the IC2 & Forestry config files and enable their ores. Then, when you create a new world, COG will see that all the ores from all three mods are registered and you will be able to choose how they generate (veins/clusters/etc).
    Posted in: Minecraft Mods
  • 0

    posted a message on [1.5.2/2.0] XCommands - Public Release (Last updated: 16th July)
    I'm completely lost on how to actually use this mod. It sounds like you implemented a custom console subwindow, separate from the chat/vanilla command bar, but if that is the case then I do not understand how to open it ('~' does nothing). I've also tried entering some of your extra commands into the chat bar, prefixing with '/c ', '/!', '/.', '//', and '\', but to no avail. The same for WorldEdit commands. In short, the mod installs fine and displays log messages indicating it is running, but does nothing.

    Here is a pastebin of the log file. Note the NullPointerException at line 219; I have no idea if that is significant or not.

    I suspect there is something "obvious" I'm missing here, but frankly you need to clean up your documentation. Even alpha/beta projects shouldn't have self-contradictory instructions.
    Posted in: Minecraft Mods
  • 0

    posted a message on [1.4.6]v2 Custom Ore Generation (updated Jan. 5th)
    Update: I have been having significant computer + internet issues for the last 3 weeks. Hopefully they get cleared up soon. Thank you all for your patience.

    Quote from Keybounce

    So ... Looking at Mystcraft compatibility, and things like dense ores, the new add-ons that give wormy/maze instabilities that seed material blocks (including ores), ore tendrils, etc., as well as twilight forest hollow hills/naga lair, and I had a realization:

    What about the older, NON-substitute based system that just stopped vanilla generation?

    If I were to go back to the non-substitute based layout, where vanilla doesn't put down anything, and COG does all the dirt and gravel underground, as well as all the ores without first wiping anything -- which should permit twilight forest's ground treasure ores, the mystcraft ore tendrils/mazes/worms/etc, then:
    1. How well would that work in the current 147 / 095 case? (The one that is supposed to / does work compatibly)
    2. How well will that work in the current 147 / 0.10.1 case? (Where ages generate like the overworld, with no access to myst symbols)

    And
    3. How well would that be expected to work in the upcoming 151/0.10.2 case?

    What are the problems/pitfalls? Does the dirt/gravel generated exactly match vanilla, or is it just an equivalent but different distribution? You abandoned that method for a reason, and I don't know the reason.
    You can disable vanilla ore generation (as COG used to do in earlier versions) with the "vanillaGeneration" config option (I think, I actually cannot check at the moment). It does not affect the generation of dirt or gravel (I removed that permanently). It also does not affect the generation of emeralds, as they are hard-coded into the extreme hills biome. I do not know what affect it will have on Mystcraft or Twilight Forest - that depends on how much of the vanilla terrain decorator they reuse. Note that disabling vanilla generation does not stop COG from stripping out vanilla ores. You will also need to remove the "vanillaSubstitute" distribution from the COG config to prevent that.

    The above applies for all recent versions of COG/Mystcraft/TF. The most recent version of Mystcraft prevents you from treating Ages differently from the Overworld, but vanilla ore removal is pretty much the same either way.

    Quote from Epidemia78

    So does that mean that this mod interferes with twilight forest in some not good sort of way? Ive been using this for a while now but havent traveled there yet. *travels there*

    The standard COG configuration does not affect the Twilight Forest. At all. It will not remove the ores under the forest or in the hollow hills, and it will not place new ones. I assume Keybounce is working with a modified configuration that does affect the Twilight Forest.
    Posted in: Minecraft Mods
  • To post a comment, please or register a new account.