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
A new version for 1.12(.1)!
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.
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 ---
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?
Well, that and some other things. I think the block breaking fx are missing, the master staff lightning .....
It's chunk boundaries because checking the list of active tile entities is a fairly expensive operation and doing so every block change (player position) would be excessive. I could have made it time based too but "eh it works".
uBlock Origin and uMatrix all the way, AdBlock plus doesn't deserve users as they literally accept cash to let ads through.
Longtime fans of mine may have noticed there's a github repo where my files are hosted. There's curse too. You don't have to go through the (i'll easily admit) treacherous adfly links. I'll get rid of them. Someday.
Accepting your PR was reading and clicking. Porting it across versions is a lot more effort which i have to find spare time and interest for, first.
@Wally it should work, the templates extracted fine for me - check your logfile?
@Jordan dang i did not test templates. I've pushed a hotfix for the missing character there
@waeloto not supporting 1.6.4 anymore