UberFix
The UberFix is a compilation of bugfixes for Demigods version 1.2. The patches incorporated into the modare listed below along with the creator of the patch.
Download:
v1.02
Installer format: www.box.net (Recommended Download)
filesize: 334,609 bytes
MD5 Checksum: 5322667e9be4dbd0fc9cb44823a6dc81
Source Code: www.box.net
Old Versions
v1.01
Installer format: www.box.net
filesize: 322,544 bytes (Downloaded 223 times)
v1.00
Downloaded 178 times
zip format: 16.5 KB v1.00 Mediafire v1.00 Box.net
exe format: 301.2KB v1.00 Box.net
Currently Included Patches
Uberfix 1.02
UberFix 1.01
UberFix 1.00
Current Buglist (Todo list: Verified and replicatable)
Bugs Requiring Research List (requires verification and a reliable replication method)
Current Unfixable Errors (Can't do list)
Current Nonbugs (Feature List)
Bugs Fixed by Previous Official Patches (SD & GPG fixed it list)(not complete, just ones that come up)
Current Potential Additions to the BugFix (Addition list) 1. SkillInfoMod 2. AIMod by Peppe
Current Semi-Active Project Members
Ptarth - guy who does stuff
awuffleablehedgie - guy who finds bugs
UhelligGudn - new guy with lots of energy
Plea to Community
If we want Stardock and Gas Powered Games to increase their support of Demigods, we need to demonstrate our commitment and our willingness to support it. If we want to accomplish anything worthwhile to demonstrate our commitment, we need to work together. If you have time, please consider helping out. Every little bit helps.
I went ahead and made a beta release.
I'm currently working on Command Queues, Occulus Auto Attack, Post Mortem XP, and health bar scaling. However, I don't see any brilliant solutions to any of them right now. The last fix I made was the Sacrifice Fix and it was more on a whim than a purposeful find.
Great work Ptarth!
Thanks for supporting the game by being such a dedicated modder
I figure as long as pacov puts up with me losing (nearly) every game I play with him, I should try to honor his patch release requests.
I imagine #6 would be an easy fix. You should include that in 1.02 ^^;
I've also tested Theugist's Cap's regen effect and it does in fact work. You can probably remove item 3 from the list (or at least put it into "a cannot reproduce" section for archival purposes.
I was goofing around with trouser in LoL tonight, but expect to be back in dg where I'll do my best to get some peeps trying out uberfix1.02. I hosted a perma lobby with GET uberfix1.02 in the title and all of 2 people wandered in there. Looks like the suport of lagwars will be required. I think this tourney will help get things rolling again on your mod. Thanks again for all your hard work!
Thanks for everyone taking the time to test things out as well.
re: "War Score" display at each teams' citadel is incorrect.
I went looking for where this occured once and it wasn't obvious at the time. I'll move it up on my priority list just for you.
re: Poisoned Blood
I'm pretty sure damaging LE was unintended. Before the fix LE could farm himself into artifacts really easily. After the fix he can't farm himself. Healing his teammates is a judgement call. Given that no LE should ever include part of his strategy as dying at location X, I don't feel the potion drop is uncalled for. Furthermore once LE gets the ability he loses the ability to drop mana potions or useful health potions. I picked this way because it reduces micro and allows for a more forgiving game. LE's teammates shouldn't have to worry about him making lethal potions for them either, especially since death effects are meant to give your team a boost. All in all it doesn't matter. The number of deaths that a LE should experience is already a trivial amount, especially if his team is winning.
re: Oak Shield
My understanding was that lag was causing people to think their teleport was still protected by Oak shield (when it wasn't) and then thinking it was buggy when it was interrupted. Your interpretation is that someone is interrupted the cast of Oak shield. I'm not sure which is correctly describing the reported problem.
re: Shield Effects
I looked into the code a while back when this was previously brought up. The code works as expected. If the damage fails to exceed the shield value, then the damage code exits before doing hit effects. This is definitely not a bug. It may be a balance issue, but I'm trying to avoid making balance calls.
re: Tool Tip Upgrades
I had been the one working on the updated SkillInfo Mod you describe. I stopped because it was getting problematic. One problem is that the mod requires a strings_db.lua, a user specific language file (i.e., English, German, French, etc), and mod files that change the actual skills.
strings_db.lua
Allows me to change the strings without disrupting the game for other language players Forces me to use the pre-existing string pointers mod files
I can add new strings I lose the ability to support other language players
As you can see, I can't have both new strings and support for other languages. As it stands now the UberFix is language independent and I'd like to keep it that way.
An example of this is how the Torch Bearer's Fix Aura is coded. It has one string to describe all the levels of the popup tooltip on your current buff display. I can't change it to reflect one specific level, because it is used for all three levels of the buff.
I'm not sure what a good solution is. The best idea I have so far is to go through the strings_db.lua and rewrite everything just for the English file, but it isn't a good solution.
Running a 3v3 with uberfix1.02 now... will let u know how it goes.
hmm... things were pretty stable w regards to uberfix 1.02 (though I appear to be having some comp issues lately unrelated). I'm trying to figure out if there is a problem from uberfix 1.00. hehe. I noticed that during game, I'd get tracker placed on me by a reg. The occ would cast brain storm on me, but it I'd still see the icon for tracker... then, maybe 5-10 seconds later, tracker would drop. The oc player indicated that tracker would drop off of him the second he cast it though. Not sure if I'm crazy or if its just something weird.
we played several games without any issue (and recruited some more folks for the upcoming tourney). Another strange thing... this time almost COMPLETELY unlikely. We played a 4v4 on brothers. I crashed about 20 minutes in. My ai apparently just sat at the freaking base. I haven't ever seen that behavior before in DG (and we are talking about the ai sitting at base > 10 minutes). I very much doubt uberfix has a damn thing to do with it, but, as its something I've never seen before and we are using uberfix 1.02, seems like I should mention it. Could be a random dg issue or an issue with brothers too.
I'm leaning towards using this patch in the tourney - I hope to get many more games in prior to that, though, using it. So far, I don't really think there are any stability issues with it. It has a pretty strong value add for Oculus. His abilities working as they are written add quite a few strategic options.
re: AI sitting in base.
That's very odd, very odd. What Demigod was it?
re: Regulus Tracking
That's also odd. I'd like to have this replicated if possible.
So, I've been thinking and exploring the various weapon attack problems. Here are my thoughts in case anyone else is interested in the problem.
Weapon Attack RangeMinRadius does create a minimum range for a weapon.MaxRadius does create a maximum range for a weapon.When a target enters minimum range, the attacker does not switch to a valid target.When a target leaves maximum range, the attacker does pursue (some issues with pursuit).When an attacker acquires a new target, it seems to be the closest valid target.There is no .lua code that uses the property MinRadius.MaxRadius is used by hero.lua to define unit.range. This may only be used to display the range in the stats window.AlwaysRecheckTarget does not seem to do anything. It may be set to true by default, which would produce these results.AlwaysRecheckTarget is set to false for Demon Assassin, Unclean Beast, Oak, Sedna, and Lord Erebus. These are the melee demigods (excluding Rook).AlwaysRecheckTarget is set to true for Siege Archers and reinforcement archers.There are range functions in AbilityTask.lua, but these are for abilities.ClosingRadius was needed to make Shamblers move into a valid range to attack. It is also not defined in the lua.So, I'm going to try to define the targeting logic.(I don't know where the targeting and retargeting logic is defined. I suspect it is defined in the engine.)
Current Weapon Issues
You can reproduce QoT switching target issues by having her pursue a moving target moving directly away from her then having new targets come within her attack radius in between her attack animations.
Queen is attacking Enemy and is hitting each time
| (creeps)
| |
| \/
-----(T)
<--- Enemy <----Queen
Creeps move into range, she will start hitting them, or perhaps alternate
|
Creeps are no longer "new" targets and stop being attacked. Tower becomes new target
-----(T) (creeps)
Enemy Queen
Queen resumes attacking main target
-------------(T)
Enemy Queen (creeps)
For fixing Occ's and TB's targeting issues, could you have a "Levitation Override". For the animation, use a certain levitate value, but when the ... attack engine processes attacks, have it use 0 or something like that. That should fix these issues that Occ and TB seem to have, maybe?
Also, AlwaysRecheckTarget is set to false for Demon Assassin, Unclean Beast, Oak, Sedna, and Lord Erebus. These are the melee demigods (excluding Rook).
This is probably the reason why Rook cannot attack a demigod that is moving away from him, no matter how slow they are (he is faster or same speed). Currently, he is stuck using his arrows.
To reproduce this, get Wyrmskin Gloves, Poison Dagger, Boots of Speed and attack a slow Demigod like Queen. Even if both snares proc and Rook is obviously faster than the target, he will not "bitch slap" them. Only use his arrows.
Also, maybe you could fix the ranged-character chase targeting. Currently, this is how a ranged target chases an enemy moving away from them:
- Stand still and wait until they are at max range
- Being to pursue and maintain max range
This is fine and dandy as long as both demigods are the same speeds, or the ranged character is faster. However, when the enemy is faster than the ranged character, this ends up sometimes letting them get away since the few seconds they aren't chasing instead of following lets them get out of range very easily. Basically, if the enemy is faster than the ranged character, the ranged character should approach the enemy to maintain auto-attack range as long as possible.
However, it is VERY IMPORTANT that this only works if they are moving away from the ranged demigod. You would not want a ranged demigod to walk towards a faster demigod that is immobile or moving towards the ranged character. They should hold their ground as they do now. To ensure this behavior exists, you'd probably want to do a distance check. If the target's speed is greater AND the distance they were previously was larger than it was the last attack (they are moving away), then approach. Otherwise, hold ground.
You'd want to make sure that you don't use a very very old "last autoattack" however.
If this is too complicated, or would cause other bugs/targeting issues to occur, I would ignore this. It's a much lower priority issue than other things.
Ptarth - you have my vote for taking uberfix 1.02 out of beta. If you agree, please do so and we'll use that for the tournament.
Why are you removing the suicide effect from UB? Is that not one of the benefits of using ooze?
The End.
brandon - start reading at about reply 164 - morph and ptarth talked this out. Here's a snippet:
On the bright side this clears up any debate about the issue, it is obviously a bug. If you want proof but don't want to look at the code yourself, try committing suicide with Ooze 1 (outside of combat). You can't do it. You'll get down to 100 health. The check will kick in and you will end up with around 64 hp.
so the bottom line is that the code to have it turn off on low health is in there, but it wasn't implemented correctly, so a bugfix was required. If the code to turn off ooze was absent, then it would be a matter of debate as to what the dev's intent was (was it just an oversight or did they mean to allow for ub suicides as an escape). But the code is there, it just doesn't work right without a fix.
Ok, there is even a message developed that states Suicide when that happens. Why would they have that message if that was not the plan? What other char. suicides? Or how else can you suicide. Just because there is something in there that you can change with those options does not mean it was meant to do that.
I'm not looking to personally rehash what they discussed 20 replies or so ago (mayhaps one of them will chime in), but just some thoughts that haven't really been discussed regarding the impact of this change and the ability to randomly commit suicides.
From a viable strategy point, using any character, if I go for a kill, say, in a group of enemy towers and pull it off, but then find myself killed by "forces of darkness/light," its not that bad a thing as I got the full money for a kill and the other team got squat as the "forces of darkness/light" got 0 gold for the kill. It's a reasonable strategy (in certain situations) to let a tower kill to avoid giving someone on the other team a kill. Anyway, this option is available to all dgs.
Onto the beast - as it stands, the UB can take it a step further by trying to use the method I described or simply by engaging in combat with anyone. A ub can run up and engage an opponent with ooze enabled. In order for the ub to suicide, all that needs to happen is for the person that is fighting him is to drop him to around <100 hp or so. There aren't many scenarios where a ub will get dropped right down to that threshold of <100 hp with the exception of intense combat. At which point, I'd argue that because the odds that you'll hit <100 hp on a ub and get the "commit suicide" screen are extremely low, its not a viable strategy at all to be willing to have the ub on your team pull that.
Also, let's talk about committing suicide in dg. The code in the game (not talking about uberfix) does turn off the ooze at <100 hp. In short, if you aren't in combat, its impossible to trigger a suicide. And suicide is the taking of one's own life, yes? So, as the game is coded its impossible to kill yourself without someone/something assisting. I'd argue that the mere fact that ooze turns off should make it clear that it is not designed to kill the UB. Otherwise there would be no point in having that code at all.
edit - and I'd add, its not that game breaking or even much of a nerf. The ub is hardly a weak dg and this simply gave players an extremely low % chance (2-5% I'd guess) of "committing suicide" when in reality, 1 additional auto-attack from any dg would have killed him (as his hp has be below 100). And again, the odds of someone pulling this off as a strategy are extremely low - meaning, its just dumb luck if a player "commits suicide" by taking damage in a fight.
I get what your saying. It's just obvious that that was not the intent and so its not a uber fix its a game change.
But one that does not really matter.
re:awuffable's posts
I'm looking into this still. I promise to have a nice wall of text once I finish trying things.
re:Unclean Beast Ooze Suicide
I had thought that I had finally put this argument to rest, as per the discussion around 164 as referenced by pacov.
re: UberFix is changing Game Balance
Because when he suicides it says unclean beast suicide. Is there a single other instant of suicide that is possible but that? If not they programmed the game to say that. What proof do you have that your not supposed to?I am not going to argue do what you want. But you should realize that your nerfing a char. and changing the game a little.
Also, how do you guys read all this crap?? LoL. Whatever happened to economics short sweet beautiful answers.
Just a joke.
The answer was literally right above your post, and the sentence below the question asked....
what evidence is there that Ooze was intended to allow the Unclean Beast to suicide?
that seems to be your only point left to stand on, so I won't readdress the other reasons again.
Eh. I'm not going to argue a stupid change.
I disagree and I am sure I can keep pointing things out and this can turn into something even more pointless... but there is no point. I concede to your greatness.
: )
re:QoT switching targets
I tried to replicate it using Hedgie's clear instructions, but was unable to do so. I tried about 4 times, I'll try another couple of times before demanding a better explanation.
re:TB & Oculus Height
I'm not sure on if it is possible change the height problem so easily. The demigod has a turreted weapon (staff) that fires the projectile. This staff is part of the model. To change the height wouldn't be enough, you'd also need to change the model. For the TB I think I fixed it and since he is shorter doesn't suffer from the other issues. For Oculus I'm not sure there is anything we can do about it, although I'll keep thinking about it.
re: Ranged Character Pursuit
I don't think the pursuit code is in the lua. I am pretty sure it is in the engine, so I can't do much about it.
re:Rook Move and Attack
I confirmed and replicated the lack of attack following a slower demigod (I just set his speed to 9 instead of buying items though). I tried a couple of things to see if I could change his behavior.
Nothing seemed to work. I'm going to keep looking into it. I also added it to the buglist.
One idea that occurs to me is that the rook could be initiating the attack but has to stop while doing so. In this period of time, the target moves out of range, which interrupts the attack. To test this out I set the Rook's Speed to 9 and his opponent's speed to 3. He displayed the same characteristics he did when the speeds were normal. Interestingly, one thing that may be helpful for a solution is his pursuit. When he pursued a target out of range, he changed speeds. When he was out of range he traveled at a normal speed. However, once he gets in range, his speed drops to a crawl. Hmm....
Incidentally, this is the same problem that the Fire Torch Bearer suffered from before Sorian fixed him. However, in the Rook's case, he has all of the animations and code present. (Also, he has a stomp animation still present which could be used for a new attack. It didn't make the cut into the final release apparently.)
There are many great features available to you once you register, including:
Sign in or Create Account