I'm not really sure what you're referring to? Supcom had absolutely no AE damage variance, it was always 100%. There's absolutely nothing in the code that would or could vary AE damage, and the engine's DamageArea function does NOT reduce damage based on radius from the center. It damages all affected targets equally. Also, DamageRadius has absolutely nothing to do with DamageSplash mult, other than that some of the former is needed for the latter to have any effect.
miriyaka
No, they're not backwards, as the amount increases with each upgrade (10%, 30%, 40%, 50% from -90%, -70%, -60% and -50%). I tried it at -50% base via blueprint change, but I don't think it was working. Not sure why. And no, nobody else can see the floattext for mana and health, and damage is only displayed to the two parties involved.
Not every demigod has to be 'tier 1'. TB can do massive, massive amounts of damage in a multi-demigod fight, especially mid-game. That doesn't mean he can always stand up to a tank DG like UB in a 1 on 1 fight without using circumstances (creeps, frost abilities, etc) to his advantage. The same is true for Reg. He needs a boost, no doubt, but making him able to stand and tank against UB, Oak, Erebus, etc should not be the goal. Speaking of Reg,
Actually I've got the AI buying building strength in response to Priests, and I had totally forgotten about the whole splash damage thing and hadn't fixed it. Looking at CitadelUpgrades.lua, it's doing -90/70/60/50% splash with BS 1/2/3/4? I guess that means it's doing full splash with 0? And then you lose 90% of that at 1. Haha, great job GPG. What's the consensus on fixing this? Remove tower splash entirely at 0 (easily doable), or remo
[quote who="awuffleablehedgie" reply="24" id="2719294"]Yetis... 400 DPS might be enough. I'd have to experiment with it to make a judgement call. But, still. They cost sooo much mana even though 1710 is enough to keep them alive, I guess. Maybe it is just stuck in my head. Wild Swings always existing would make them worth it just for creeping, even if Siege Idols would normally still be better. [/quote] I've been using them in AI skirmishes at 240dps (300 with wild swings and magnific
hedgie's argument was pretty solid, that all demigods that have stuns/interrupts have to make tradeoffs to get them. If TB gets interrupts on three of his primary skills, you would have to try really really hard to not have at least one interrupt. Then there's the obvious paradigm of Frost TB = fight control & mass debuff, where Fire TB = damage damage damage. It's hardly balanced to let one side or the other have the best of both worlds. Why even pick Fros
[quote who="awuffleablehedgie" reply="18" id="2719054"]stuff[/quote] I actually read all that. I'm not a fantastic player, but I've got a pretty good feel for game balance in general, and I agree with: - TB does not need another interrupt - Reg and DA need 6.3 speed (already done this in a screwaround single player mod, works well) - Yetis need a large boost to everything (already played around with this too, having a hard time finding a sweet spot)
Set it to 0.0 or 0.05. Anything non-negative is fine.
It's possible to make Elusiveness give MoveSlowCap based on the lowest common denominator of its level and Demon's Speed's level, creating even more symbiosis between them. It'd be a bit trickier to implement, and harder to explain in the description, but it's doable. e.g. if you have Elusiveness 1 and Demon's Speed 3, you would get a MoveSlowCap bonus equal to Speed 1. With Speed 2 and Elusiveness 3, a bonus equal to Speed 2. With Speed 3 and no Elusiveness, no bonu
[quote who="LORD-ORION" reply="7" id="2718538"]Didn't know that. What if we set it to a negative number and describe the hard number you cannot be slowed against? eg: Cannot be slowed more then speed 6, speed 6.6, speed 7.2. Does this mean unrelenting wrath only works to speed 6.3? Saam-El's cloak will probably need an adjustment too[/quote] Yes, Unrelenting caps it at base speed (6.3), while Saam-El's caps it at 0.85 (1.0 + -0.15) of base speed (5.35). Somethi
MoveSlowCap is totally useless, because it's based off of base speed. In other words, 'cannot be slowed more than 10%' means -10% of base, or 5.4 for a 6.0 demigod, which is still quite slow. If you have +20% speed, this means it doesn't even come into account until you've been slowed 30% from your 'normal' speed. The only snares that would even have a chance of running into this limit on DA are Penitence IV, Hammer Slam IV + Dizzying, and Mark of the Betrayer III. I
It should work fine on any ability that uses DealDamage and whose damagetable has CanCrit = true and CanCritFrom = {AbilityName = true}.
Should have looked right at the top of the same file: [code="c++"] if Validate.HasAbility(unit, 'HDemonDeadlyWarp') then Abil.AddAbility(unit, 'HDemonDeadlyWarpBuff', true) end[/code] It adds that ability at the beginning of a warp strike. The ability adds a crit chance that would apply to everything, but it is removed as warp strike finishes, preventing it from ever applying to normal a
I'm not sure that priority alone is what is causing shopping frequency. Unless everything in the AI's shopping priorities (both upgrades and items) returns 0, or it doesn't have enough money for those that return > 0, it'll still go and shop for that one item/upgrade when it decides to shop. What I haven't figured out by looking through the AI, is when / how frequently it decides to check priorities, and if that can be controlled (modified by, say, how much gold it's accrued or
Yeah, this is all getting fixed in the Uberfix. At least with the Desperate Boots, the bonus kind of sucks (20% evasion) and the cost is high, and you have to get yourself below 30% health, survive, and still sell/drop it while you're below that threshold.
Updated the Uberfix issue on this. In addition to Ironwalkers and Desperate boots, there may be other items that exhibit this problem. I say this a lot, but if I get the time I'll peruse the item files and look for other infinite-duration buffs that are added by non-standard means (e.g. a manual AddBuff call in an aura pulse or other conditional block, instead of just being included in the Ability's buffs table). If anyone else wants to do this, or test other si
Yes, actually. The buff has no specified duration, and so it will stay on unless explicitly removed. Since the ability's OnRemoveAbility does not do this, it never gets removed. This should correct that: [code="c++"]local oldORA = Ability.Item_Boot_070.OnRemoveAbility Ability.Item_Boot_070.OnRemoveAbility = function(self, unit) if oldORA then oldORA(self, unit) end
Here's a quick rundown of how to log errors in a mod file: http://forums.demigodthegame.com/385404/get;2662374 I'm not aware of any way that a non-OnClick item with passive bonuses could ever be disabled. Are you sure you weren't running another mod that might have done something with abilities?
Nice work. It sounds like you've solved most of the major problems with .22. A few weeks ago I worked on revamping the AI's citadel upgrade purchase priorities using the PriorityFunction extension that the AI mod added, and it just needs some final testing and tweaking. They're currently buying Experience and Currency I at appropriate times, and occasionally Currency II on high gold if they can afford it early enough in the game. I've also got them upgrade-matching r
Item purchase prioritization is actually one of the easiest AI-related things to do. Each item can have a PriorityFunction associated with it that is called whenever the AI goes to purchase anything, and this function can access any piece of information related to that Demigod (as well as sim-global variables and functions), letting you scale priority based on say, level, game time elapsed, other equipment present, etc. Look at the mod's AIGlobals.lua, line 253. There's al
Optional percent-based fix that triggers below 90% of base speed (4.9, 5.4 and 5.7 depending on the demigod): [code="c++"]Items.Item_Boot_070.GetTriggerAmount = function(self) return math.floor(Ability['Item_Boot_070'].TriggerPercent * 100) end Items.Item_Boot_070.Tooltip.ChanceOnHit = 'Whenever Movement Speed is reduced below [GetTriggerAmount]% of base, Armor is increased by [GetArmorBonus].' Ability.Item_Boot_070.TriggerPercent = 0.9 Ability.Item_Boot_070.OnAuraPulse
If you just want a quick fix for this, paste this into a non-overridden Boot_Items.lua hook: [code="c++"]Items.Item_Boot_070.GetTriggerAmount = function(self) return string.format('%.1f', Ability['Item_Boot_070'].TriggerAmount) end Ability.Item_Boot_070.TriggerAmount = 5.4 Ability.Item_Boot_070.OnAuraPulse = function(self, unit, params) if unit.Sync.MovementSpeed >= self.TriggerAmount then if Bu
Yes. I've got a fix for this that sets the speed requirement to The UI says 5, because it's using math.floor instead of string.format('%.1f') or whatever the 1 decimal floating point display string is. This is fixed as well in the code I've got.
I think this thing is ok as-is, but it doesn't bring some kind of magical balance to the favor item lineup. BotF is just too powerful. If you really want to balance favor items, you've gotta do all of them at once, which includes nerfing BotF a bit. And then you have to lower maxhealth amounts on all other items as well, or you still end up with so much health that you can't properly balance offensive items (because making them effective vs stacked health makes them too po
Honestly, there is no working code in the game that's even remotely similar to the 'correct' way to modify already existing item, ability, and buff blueprints. None in mods either, other than the in-progress Uberfix 1.03. I should probably make a standalone how-to thread for modding these things, because unless you know everything about how the game stores its blueprints, modding them non-destructively is completely unintuitive. I did make a post detailing most of this in on