My point is, THEY will have to implement this mapping. And i will make use of it.
- Curse Premium
Member for 6 years, 10 months, and 9 days
Last active Sat, Dec, 16 2017 02:39:43
- 45 Followers
- 4,284 Total Posts
- 1827 Thanks
Nov 24, 2017AtomicStryker posted a message on [1.12.2] Finder Compass - turns the vanilla item into a configurable search utilityPosted in: Minecraft Mods
Nov 5, 2017Posted in: Minecraft Mods
It probably wasn't any conscious decision, either the MC devs refactored their AABB or Forges automated mapping matcher "translated" wrong. The same problem occured in Infernal Mobs and broke the "looking at mob x" detection.
But now that you mention it, i probably have several of these spots in my repo ... yep several. Thanks for notifying me
Oct 4, 2017AtomicStryker posted a message on [1.12.2] Finder Compass - turns the vanilla item into a configurable search utilityPosted in: Minecraft Mods
I was poked with update requests to 1.12.2 somewhere. Except the 1.12.1 version runs just fine?
Sep 22, 2017AtomicStryker posted a message on [1.12] AtomicStryker's Infernal Mobs - Diablo Style ModifiersPosted in: Minecraft Mods
A new version for 1.12(.1)!
- reworked time based attack logic - nonhostile mobs (eg pigmen or creative mode) will no longer affect you unless actually in combat
- reworked hitscan for health bars, now works more reliably
Sep 17, 2017AtomicStryker posted a message on [1.12] AtomicStryker's Infernal Mobs - Diablo Style ModifiersPosted in: Minecraft Mods
bloodmc found the bug and fixed it using a github pull request. I've merged it and pushed new 1.12 mod files. The "hitbox" infernal mobs used to determine healthbar showing had been mistranslated during a version port.
Sep 8, 2017Posted in: Minecraft Mods
QuarterAnimal did an amazing pull request on github, and i finally got around to merging it. For now 1.12.1 only. Could you test it a little? I do not seem to have the time ... at all.
I shall quote his "proposal" / explanation (which is more of a complete implementation) in entirety here:
# --- begin proposal ---
# The rule syntax was modified a bit to add some new features (variants and variant groups, in particular). None of these changes
# should break or alter the behavior of existing template files.
# Block Weighting: Instead of repeating block IDs in a rule to manipulate their probabilities of occurrence, weighting factors may
# now be used. This can make rules shorter and, in certain circumstances, more efficient. Apply a weight to an block in a rule by
# preceding it with a prefix of the form "n*"; this is functionally equivalent to repeating the same block n times. Valid values
# for n are integers between 1 and 99999, inclusive. For example, the following rules are essentially identical, each producing
# blocks of cobble, mossy cobble, and gravel with the same likelihood:
# Weights are optional. If no weight is specified for a block in a rule, a weight of 1 is assumed.
# Rule Variants: Consider a platform composed of many instances of the following rule3:
# Each generated structure will have a different random assortment of stone, dirt, and cobblestone blocks. Suppose, though, what
# you really want is each platform to be a single, randomly chosen material--either all stone, or all dirt, or all cobblestone.
# You can't do that with a regular rule, since a different color choice is made per block. You could do it with three separate
# templates, of course, but now there's another way. For example:
# Note "ruleXXX=" is replaced by "^" to indicate a line is a variant of the preceding rule, not a separate rule itself. Each time
# a structure with such a rule is generated, one of these variants is randomly chosen to apply to that entire structure wherever
# the corresponding number appears in the layer specifications.
# Rule Variant Weighting: Weights can be applied to rule variants to adjust the probability with which they are selected. As with
# block weighting, a prefix of the form "n*" is placed at the beginning of the variant (i.e., just after the = or ^) to assign it
# a weight. For example, you can use this rule for the windows in your structure:
# Most of your generated structures will have blue windows (stained_glass-11, with a weight of 5), a little more than half as many
# will have red windows (stained_glass-14, with a weight of 3), and only a precious few will have yellow ones (stained_glass-4,
# with a weight of 1, the default when none is specified).
# Grouped Rule Variants: With variants, it may be desirable to coordinate several different rules to guarantee selections are
# only made in particular combinations. A named rule specification using ^ instead of = creates a new rule whose variant choice
# depends on that of the preceding rule. For example, make a small pillar with the following rule7 at the base and rule8 stacked
# above it:
# When a structure chooses variant #1 of rule7, it will always choose variant #1 of rule8 as well, so pillars with redstone at the
# base will have red glass (stained_glass-14) on top. Similarly, gold blocks (rule7, variant #2) will be matched with yellow glass
# (rule8, variant #2) and lapis (rule7, variant #3) with blue (rule8, variant #3).
# Rule Variant Group Duplication: Suppose you have a structure with three fancy pillars, as described in the previous example.
# You could make four stacks of rules7 and 8. Different structures would have different kinds of pillars, but all three pillars of
# any one structure would be of the same type. To get variation within the same structure, you're going to need a separate group
# of rules for each pillar--one using rule7 and 8, one using 9 and 10, and one using 11 and 12.
# Note these rule groups are identical except for their names, and there's an easier way. By putting a repeat count of the form
# "n*" in front of the first rule name in a variant group (the one with an =), that many identical groups are automatically
# created. This is a bit tricky, because it does create new rules, which affects the way rules are numbered. To continue the
# example, rule7 could be changed slightly to take advantage of this feature:
# This creates rule7 and 8 as before, but also creates rule9, 10, 11, and 12, exactly as though these lines were cut and pasted
# into the template file 3 times. Note the rule names are irrelevant--rules are assigned numbers based on their ordinal position
# in the template (the first rule is 1, the second 2, and so on, regardless of their names).
# Alternate Rule 0: By default, rule 0 is an air block. You can now change it to something else by putting an unnamed rule at the
# top of your rule list:
# It has to appear before any other rule. It cannot be a variant of a preceding rule (since there isn't one--it has to start with
# = instead of ^), but it can be followed by variants and/or grouped variant rules. It cannot have a repeat count.
# --- end proposal ---
Aug 27, 2017Posted in: Minecraft Mods
Ruins.1.12.jar contains everything the old zip used to contain. The difference is that it now comes as "self-installing" file compatible to any mod launcher, as upon launch it checks if config/ruins_config/ exists and if not, extracts the "default" stuff (that you used to have to install by hand from a zip) to there.
I don't see how this is complicated in any way. You run it, you get a working setup.
Unless, of course, you are a long time template meddler and maybe forget to delete the folder for a regen?
- To post a comment, please login or register a new account.
Mar 3, 2012There is MAJOR problems with your new forum software. Editing my posts regularly deletes all youtube links within them (i have lost a ton of links already), much formatting was lost, my subscriptions are not emailed to me, or do not show up at all.Posted in: News
- To post a comment, please login or register a new account.