BuffAffects.lua, line 82 from the Health affect:[code="c++"] CanBeEvaded = true,[/code] Evasion is on by default. This, I would say, is the oversight, as -health buffs are universally used for ability damage. All other abilities specify CanBeEvaded = false, and the Spit buffs have no specification one way or another. If I fixed this, I wouldn't touch the Spit buffs themselves, and would just set CanBeEvaded = false, in the
Man, my head hurts just from an hour of looking through HeroGOAP/StrategicGOAP/HeroAIWorldStates. And I still don't know what anything does. I don't know who did the AI for Demigod, but I can definitely see why they had trouble refining its behavior. Yikes.
Whoops, I missed a use of that ActionTime value - HeroGOAP.lua, lines 1212 and 1247. Not that I really understand how it's being used, but you're right in assuming that it does time something . Edit: Actually, I don't think it's a timer, even there. It doesn't involve any waits. This appears to be a planning function only, and not something that loops constantly. If that change works, and doesn't have any unintended consequences, then I
[quote]Issue: Trebuchet shooting into the fog of war Intended? I don't know. Bug? I don't know. Does it happen that often? Not really. Is it a balance change? Maybe? Is it necessary to reduce lock on issues with the Rook? I'm not sure. I still haven't gotten around to understanding Miriyaka's code.[/quote] No, there is no blueprint/script setting that causes it to happen, and it only happens with these two units due to their attac
That's only used for one thing as far as I can tell. It sets a value called self.ActionTime, that is then not used by anything in the lua. So that's right out. That leaves the goal priority increase that it multiplies: look at lines 226 and 246 of HeroAIWorldState.lua. If I'm understanding correctly, that time value just acts as an exponent to the insistence of that particular action's goal (Assassinate for these actions, I guess?). So leavin
All you should need to implement the variable timer is to replace this line in each attack action:[code="c++"] while not unit:IsDead() and durationTimer while not unit:IsDead() and durationTim
Again, I'm far from an expert on the AI, and even after looking at the AI action code I still don't understand exactly how repeated attack actions would mesh together, but I don't see anywhere where another order is issued to the AI between actions, so as long as the AI has an attack/assassinate goal, it should seamlessly process consecutive attack actions. Therefore, I can only conclude that having the action's timer come due in the middle of an attack animation or just before an act
I'm going to go ahead and drop another release candidate, because I've added a pretty significant number of new stuff in the last two days. It's been running fine for a few games with no log errors, so it should be good enough to get feedback on. http://code.google.com/p/uberfix/downloads/detail?name=UberFix 1.04 RC2.zip New fixes from the last version: - Cooldown fix works
There's no real drawback to that, I guess. Do normal-sized ability icons work as buff icons? Also, I think I've fixed the ROLLOVER DATA ERROR thing. Flags now give an imperceptible 0.1s 1 radius viz to the enemy team upon being captured. You can't even see it, but it seems to be enough to make GetRolloverInfo() return the entityid for the correct unit. Of course, only time will tell if this is an absolute fix, but the reasoning is sound (fog of w
That could work, but would break localization of the tooltip (it would always be in english). Probably not a huge issue, so if enough people want it changed, I'll do that. Although, I have a feeling that anyone who would care enough to post here in support of this would already know the effect of the upgrade well enough to not care whether or not it displays in the tooltip.
Welp. Confirmed. Those waits are waiting 0.1 seconds, not 0.2. That's why you're having trouble with this. Every action timer that waits 0.2s will only be waiting half that long. This also means that every action loop is going 10 times a second instead of only 5, which is probably unnecessary and is incurring a performance hit in a multi-AI game. If you change all of the waits to 0.3s, that -should- fix it, but I'd test to make sure.
I did a little testing tonight, but I still need some more time to look over a few things. Like I said, I'm pretty confident in everything but the rook shoulder weapon fix, and the stuff I haven't been able to fix at all (like the rollover bugs). Definitely not going to tackle the Fire and Ice thing right now, because I don't particularly like any of the quick solutions (most of them would break mod compatibility or require overwriting UI and/or ability functions) and it's just
On second look, both of the hero attack actions seem to be weighted based on how many attacks the demigod can perform in the alotted time, so shortening the time and/or making an action duration single-shot would both have negative affects on weight calculation for that action. So it could be done, but CalculateWeights for those actions would also have to be updated to consider a different set of factors. If you want to try a per-shot attack action, I can show you how to use the
[quote]I guess ideally each attack action would only end after completing an attack. [/quote] Add an OnWeaponFire callback to the demigod at the beginning of the action that sets some var (either in the AI class or on the demigod) that the attack action waits for. Then remove the callback (or make the callback self-removing? I think that's possible) before switching actions.
Yep, that sounds about right. I don't know enough about AI targeting to know exactly how to fix that, but I can take a look. Without the 1.04 UberFix, this would probably result in an AI QoT having a ridiculous rate of fire, since QoT has no attack animation interrupt set up and her attacks all go through successfully even if they're stopped. Edit: Whoops, missed that next page. Welcome back Peppe. If this is happening with vanilla DG AI as wel
[quote]The part where I had to double nest the weapon attribute changes in brackets still doesn't make sense to me.[/quote] Ignore the non-plurality of the name: Weapon is a table containing subtables, each one being a separate weapon. Units can have multiple weapons - look at Rook's blueprint. Every unit with a Weapon table, including those with only one weapon, have each individual weapon in an unkeyed subtable. If you copy-paste e.g. TB's Weapon table with all o
Idea vs implementation is a false dichotomy. Both are interdependent. An un- or poorly-implemented idea is inferior to a well-implemented idea, and there is no implementation without an idea to implement. I'm not criticizing your ideas or the fact that you have ideas, nor am I championing implementation over idea. I'm trying to explain why you need to work at least a little bit on their implementation, whether you like it or not.
A UI mod can't possibly break a sim mod, although it could cause a lot of errors and slow the game down. Run a log when you observe this happening, then pastebin it. My guess is it'd be the lack of UberFix, but I wasn't really present for the whole TB-projectile-fix part, and I don't know that I've ever really played TB without the UberFix, so I'm ignorant of this particular problem.
Ain't gonna happen. As I've said before, no company will ever directly support a third-party launcher. I could take the time to make a long-ass bullet point list with all of the reasons why it won't happen, but if you think about it from a liability and support standpoint (as in you're legally liable for any potential damages incurred by said third-party program) you should be able to figure out most of them on your own. Nevermind that it WOULD take a lot of work, and WOUL
Pacov's mod package is just fine and shares absolutely nothing in common with a massive overwrite/combination mod, because it doesn't force anyone to use all of those mods if they want to use one, nor does it force them to stick with outdated versions should any of the authors update individually. Not that the latter is a particularly realistic scenario anyway, because he updates it very quickly. Of course, the only reason he can update it so quickly is that he isn't having to r
New issue, albeit extremely minor: When dead, the red disabled/cooldown overlays on the ability button bar momentarily flash and disrupt tooltip display whenever you hover over a button. This is present in stock Demigod, and isn't caused by the cooldown time fix. I'll need to research a bit more on what conditions cause the overlay to display, and why it's only happening on mouseover.
[quote]Re: TB Fire & Ice I know it is primitive, but why not just create another level of Fireball and Ice Blast with the updated damage. When someone picks the upgrade instead of getting a boost to the spells, they just get the new ranked versions of each.[/quote] This is actually the most complicated fix available, as you would have to do a lot of manual coding for adding and removing 'hidden' abilities, updating ability-bar buttons, and such. Fire and Ice is on
Because it completely breaks the UberFix and duplicates a bunch of my code for no reason? Because most people that will download this are equally likely to download FavorMod and the UberFix, and this will either disallow their use and the use of any other UI mods, or it will obliterate their changes. As long as you're clearly advertising it as a fully-exclusive mod and have the exclusive flag enabled, and make it clear that it isn't a full fix mod, then I have no qualms about it
[quote]It's fine to have an AI for normal demigod, but it's not fine to have an AI mod for a mod. eg: AI mod for favor mod for demigod.[/quote] You're absolutely right, because you don't need a separate AI mod for FavorMod. FavorMod can do its own simple, non-destructive modifications of AIBlueprints that will work for both the stock AI AND the AI mod, with a fraction of the effort that would be required to destructively merge the entire AI mod into it. There's also nothin
Demigod Forums