Nothing that's more specific than the examples I just gave. I'm hooking a few things in ForgeUnit in my WIP version, but it's all for the Ooze fix, and all relatively simple. Next time you post a new version, I'll just grab that and see if I can make the change myself. [quote]So if i remove the buff table checks and replace them with new tables, this will be the majority of the performance difference between these 2 methods?[/quote] That, and a non-destructive
Yes, that's why the majority of the performance change is to move the ability checks to a unit variable/table. The reason I suggested doing the hook in DoTakeDamage is because that way you can hook non-destructively without having to duplicate all of the checks that DealDamage does, because you're essentially sliding your code inbetween all the stuff DealDamage does (tons of viability checks) and all the stuff DoTakeDamage does (float text, whether or not to kill, etc).
Instead of using dummy buffs, I'd have these items/abilities use OnAbilityAdded/OnRemoveAbility functions to set up a table on the affected unit. Then you can just query table entries directly-- which is much faster-- instead of having to go through the buff system. Example: [code="c++"]OnAbilityAdded = function(self, unit) if not unit.FavorModData then unit.FavorModData = {} end &
Where is this code? DealDamage? There are a few problems with that. 1) If the instigator unit is dead or dying, you can't check for those buffs. I hope you're making sure data.Instigator exists first, otherwise a dead/dying unit that damages something else post-mortem will actually cause DealDamage to error out and do no damage. 2) DealDamage runs hundreds of times per second in a big game, and 99.9% of the time, units are not going to have those buffs.
It would make me a lot less nervous about yet-undiscovered issues affecting everyone's playing experience, but doing that with a bugfix mod introduces a different problem: there's still no way for me, the mod-maker, to update the mod without going back to the situation that exists now where only a handful of people have the 'new' version, and it doesn't get used. Now presumably there won't be that many fixable bugs left in Demigod after the next Uberfix release, but if ther
Does the summon tower action only try to place near flags now? Might want to add an exception if there is an enemy within x distance, say 20, and Rook isn't pursuing. The whole point of the current build is to drop towers constantly, and if he isn't near flags often enough, then he'll be doing poorly with it. [quote](2) At a certain point, he ported to the hp lane tower... only to walk back to base. Had full hp/mana ATM.[/quote] Did he buy a citadel upgrade, e.g. c
I might actually be able to fix that. It sounds like the treb is keeping a target that doesn't have a visible recon blip - target loss conditions are outside the purview of the lua, but it's easy enough to periodically check a weapon's target for a recon blip, and do a ResetTarget() if it doesn't have one. I don't want this looping on all weapons unnecessarily, so I'll just try it on the treb towers first. If you can absolutely confirm the problem for other units/weapons (
Look at the code for crits/procs in either ForgeUnit.lua or Ability.lua/AbilityTask.lua. I can't remember which. If memory serves, Zex is right about the damage - crits stack additively, e.g. both the chance and the 'extra' damage for each crit is calculated separately, and then applied to the target. So if you have a 1.5x crit and a 2x crit and they both proc on the same hit (again, their chances are calculated separately, so this is fairly rare but does happen), the unit
I'm really not trying to come across as hostile when it comes to this issue, although I think I'm failing at that. Try to understand that I stand to lose the most in any of the community's preferred means of officiating these fixes-- lots of unpaid time spent creating docs for fixes in a game I rarely play; the expectation that my very amateur work based on little or no actual programming experience and less than 3 months spent working with the internals of the game will be expected t
If you honestly believe that 2K didn't do heavy internal QA on Civ V, then I want some of whatever you're smokin'. Tons of companies do open betas, and in every case those betas are already heavily-tested release-candidate material. An open beta is a secondary testing stage at best, to help identify smaller issues that aren't game-breaking but make it past internal testing. No publisher would ever consider doing zero internal QA on a patch release after the Tribes 2 patc
[quote who="OMG_pacov" reply="275" id="2842829"]I don't agree with the logic to have the ai only feed on enemy towers or enemy rook towers. It should do that as a primary, but it the ai has its own tower farm up and needs hp, it should steal hp from one of its own towers so it can stay in the lane longer. Otherwise, the ai rook will always be taking extra damage, pushing up to get a heal off another tower when a safe heal was available. [/quote] I think they are supposed t
Yes, if it can't find them. I see now that the level 1 TOL is just 'hrooktoweroflight'. Way to go GPG. So much for trying to automate things. I assume it's only dropping a warning for the first one, right? If so, try this: [code="c++"]--Add a filter category to Rook's towers local TOLCat = 'ROOKTOWER' local rookTowers = { 'hrooktoweroflight', 'hrooktoweroflight02', 'hrooktowerofli
Found a pretty decent fix for this, considering how horribly broken the whole absorption system is: [code="c++"] if buffAffects.Absorption.Add then if bAfterRemove then unit.Absorption = math.max(0, unit.Absorption - buffAffects.Absorption.Add) else unit.Absorption = m
Uh, whoops, I forgot something in that ModBlueprints hook. Let's try this again: [code="c++"]--Add a filter category to Rook's towers local TOLCat = 'ROOKTOWER' local MBP = ModBlueprints function ModBlueprints(all_bps) MBP(all_bps) for i=1, 4 do local bp = all_bps.Unit['hrooktoweroflight0'..i] if bp and bp.Categories t
While avoiding looking at UI tooltip code (ugh) I stumbled upon an issue with how absorption is calculated, namely that getting two absorption buffs on at once will 'refresh' values for the existing one as long as it still has at least 1 point of absorption left. This can only occur with one Bramble Shield and one Groffling Warplate buff; different levels of BS simply replace each other completely with no regard to which is superior; only the last one is used. Practically speaki
Oh jeez, they didn't put any special categories on Rook's towers. It's easy and harmless to add categories to units to make them more filterable - put this in a lua\system\Blueprints.lua: [code="c++"]--Add a filter category to Rook's towers local TOLCat = 'ROOKTOWER' local MBP = ModBlueprints function ModBlueprints(all_bps) for i=1, 4 do local bp = all_bps.Unit['hrooktoweroflight0'..i] <br
Chat: Do they currently have an action to teleport in for ganks / assisting an allied demigod at a flag or tower? Or is it just a general respond to flag/tower event? If the former, have them send a message when they begin to TP in. If the latter, it would probably get too spammy since they do this fairly often. Maybe just add an announcement for the normal TP-to-tower/flag actions when both enemies and (human) allies are present. Also, with any kind of g
Oh, and I'm testing a fix for ranged Demigod attack stutter when following/stuck, by having it only cancel its attacks for the first 0.2s, and skipping cancels for the next ~0.8s. This means that when a ranged demigod is force-attacking a target while stopped, and the target moves out of range, it gets its current in-progress (but not yet fired) attack canceled, gets any too-rapid retries canceled for the next fifth of a second (this is to preserve the value of Regulus' winged lock-on b
He's probably thinking of another mod, as the only AI changes here are already mirrored in Peppe's AI mod (Rook stutter fix, experience purchase fix, etc). Quick update - I haven't really done any work on the last remaining fixes this week. Need to get around to documenting them on the google code site too. If you guys find new issues, feel free to post them there, as I'm not always great at recording what I'm working on or needing to work on, and that'll he
Oh, good call. Enemy WR is what's important when prioritizing own portals, and own WR when prioritizing enemy portals. Own portals should always be higher, though, unless all else is equal and the demigod in question is basically already on top of the enemy portal.
Yeah, found it. My UI hook was only looking for mode changes, without checking for PrimaryWeaponDamage2 (and making sure it's >0). It broke the inventory/stat display, and dumped about 2mb of errors to the log in like 15 seconds. o_o It'll be fixed in the next version, although any mod that overwrites a weapon-related BuffAffect will still need to have the secondary weapon stat support or the UberFix will just display the primary stats as in normal Demigod.
Center push on Cataract might be a result of the valor flag change, unless that change only affects 'owned' valor flags. AI should definitely prioritize its own portals over enemy portals, unless it's much closer to the enemy portal, and even then, it should still try to retake its own portal immediately afterwards. Is the portal flag code treating 'owned' portals differently from 'enemy' portals, other than preferring portals closer to the citadel? What exactly
Just posted in the FavorMod thread about this-- there's no way to hook these non-destructively. The changes you made look fine, but if you have a log from a game where this was causing errors, I'd love to see it so I can fix my fix (welp) so it doesn't spew errors whenever it's missing a variable. I thought I had it checking for all of them, but apparently I missed something somewhere.
Took a look at your BuffAffects changes, and I don't think there's a whole lot that can be done about making them non-destructive - same with the ones in the UberFix. Those functions use a lot of local variables, and don't return anything, which makes them pretty much impossible to hook non-destructively. It's just a bad call on GPG's part - it was a neat idea to have each buff affect get its own function, but they should have structured it in such a way that it returned values an
Demigod Forums