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.
re:name change
Back with Total Annihilation we called the community fixes either the UberHack or Switeck's BugFix (depending on which set of fixes you used). I really appreciated the work that BraveSirRobin and the rest of the TAEC crew put into the UberHack, so I named my small collection of patches after it as a tribute. More importantly, if this gets implimented into the mainline code, the name won't matter.
re:UB getting XP for Post Mortem
I believe I understand what you are saying, Exxcentric, however I believe you are missing my argument.
This is the Post Mortem Buff blueprint. In this case, unit is the target of the buff, self is the buff (I think), and instigator is the Unclean Beast. Here the unit table is given new fields to show the instigator of the buff, i.e, that Post Mortem was caused by the Unclean Beast. It also Adds the PMExplode function to the list of functions that run when the OnKilled Callback is made.
Here is the PMExplode function. The important part is where the Instigator is assigned to the PostMortem.Caster, which was previously assigned as the Unclean Beast. This is also the instigator that is given into the DamageArea function. Hence the UB should be cited as the cause of the damage. However, something is going wrong at some point.
I've been trying to trace Callbacks.OnKilled back to its roots. I think I see what is going on, and I am suspicious that it only calls the first function on its list of Callbacks. This is a lot of conjecture, but it is my best guess at what is going on.
nt/ double post
Had more of a look into callbacks and had a look at my test scripts again. (from Buff.lua)
# Call callbacks on the unit based on if this is a removal or addition of affects if not afterRemove then unit.Callbacks.OnBuffActivate:Call(buffName, instigator, instigatorArmy) elseif afterRemove then unit.Callbacks.OnBuffDeactivate:Call(buffName, instigator, instigatorArmy) end
From what i can infer from this is that this callback adds a single affect but on remove, removes all affects from the table. So i would say that the callback is removing plague and is not actually for the counter. This is replicated sometimes ingame when you post mortem a group of units with plague (with my changes) on they sometimes continue to tick.
2 more options are to add the removecallback from post mortem, and remove it from plague. Or we could add it to post mortem and use
UnitOnKilledCallback = function( self, unit )
if not Buff.HasBuff(unit, 'HEPA01PostMortemEnemy01') then
unit.Callbacks.OnKilled:Remove(self.UnitOnKilledCallback) #self:DecrementPlagueCounter(unit)
else
unit.Callbacks.OnKilled:Add(PMExplode, self)
end
end,
found a more complex yet elegant solution.
Ok so Post mortem uses a funtion for the damage and the callback removal only removes that function:
In contrast, plague uses the buff script to do the damage and so when it does a callback:remove it has to clear the whole table (as it was not a seperate function that could be removed).
So change the buff so it acts more like post mortem (ie add a seperate function that does what the buff does now and just call it with the apply buff. You can then remove plague using callback removal that only removes that function:
Also i agree with your reasoning for the gold problem. Although i cant see an obvious flaw which would cause it not to work .
The code block is a forum feature. It doesn't have LUA, and C++ is the best match I found (although I didn't do an exhaustive search. To use it either hit the Insert Code Block button, just to the left of the emoticon button ( ), or you can add the code into your post by hand.
The code for inserting code is:
[]code="c++"[]
insert code here
[/code]
Ignore the invisible letters, that's the only way I could get it to display.
re: plague/post mortem OnKilled.Remove
Can you try to write up the code to use the buff fix? If you are correct, and I think that you are, (although I still haven't quite parsed it, too many functions and tables with too similar names), that would help out a lot. I know it isn't that hard, but I'm trying to delegate tasks so I can work on more things. I want to try to get to the bottom of the post mortem not giving credit problem.
re:Exxcentric
Also, I tried to PM you last night using ReadytoPlay but it thought you were playing demigods and wouldn't send a message through.
re:Frogboy
Can we have a preview button for posts please.
yere i got your message and was on r2p but it would allow me to send you an invite
yere i can do that. np . shouldnt take me 2 long
Next question, where did you get your auto download counter code from?
more thoughts... not sure what the issue is, but I keep having problems with people having the wrong version or something. Typically getting invalid gamestates... wonder how we can cut down on those happening...
kk fixed.
This works with no errors i can find. Try it. . Removed the callback on killed and replaced it with a forkthread function on buff remove that did all that the onkilledcallback used to. I still dont think the callbackonkilled did anything but turn off post mortem, and when farming with this i can see why, it is way OP. I maintain that it looks like the devs did this on purpose because of this reason. (any info from them would be great tho!)
mostly happens when people extract the mod into mods/uberfix/uberfix/ and not mods/uberfix/.
So I'm looking over your code Exxcentric, why did you go with:
31. ForkThread(PlagueI, self, unit )
instead of just:
unit.Callbacks.OnKilled:Add(PlagueI, self)
?
I don't really understand how ForkThreads works, so that might be the problem too. I mean, I understand the part where they create a second simultaneous microthread that runs independently on the process that called it, I just don't have a feel of how and when they are appropriate at an intuitive level.
re: Post Mortem & Plague are overpowered
I'm not sure that it is a code change and not just how useful Post Mortem/Plague actually is. If someone wants to test it out, I can send you a work-in-progress version or you can add the code in yourself.
Hai everybody - Ptarth made a help-me post on the SupCom/FA modding community boards, so I thought I'd drop by and see what I could do to help. I've been modding the moho engine in Lua since November 2006. I'm a student now so oodles of time to help you guys out.
Forkthread does not cause a simultaneous function to be run. It adds it to a list to be run at the next tick. The costs of actually forking a hardware thread are excessive, if you allow it to be called so trivially. Lua does not support and GPG does not use hardware multithreading within the sim. The reason to use this method is so that you can pause them, then resume them an arbitrary time later. This can't be done in a normal function because you'd pause the whole damn sim.
In this instance, you can say that ForkThread causes a function's execution to be delayed slightly until the list is next iterated and executed, and you can wait in it. Else, it has no effect compared to just calling the function in question.
Lua doesn't require formal training- it's a really, really, simple language. Just read the manual, there's no complex concepts in there, Lua manages virtually everything behind the scenes for you. GPG used their own co-routine interface, but that's all. Else, you can find the mechanisms behind them fully explained at lua.org
If you really need something answered, just email me at wolfeinstein@gmail.com. I'm downloading Demigod now (stopped playing before mod support patch, actually) and am going to see what I can crack out with regards to the list in the OP.
perhaps then you can tell me how the communication between the clients is handled? is it possible to send information to the other clients? this could be useful to mod the random select demigod function.
Ah. That's likely it. Thanks for the clarification. Derog.
Ptarth - are there any other bug fixes ready to go live at this point? Would it be possible to get an executable created of uberfix so we can reduce user errors on the install?
It seems like alot of people that are trying to use this are new to using mods.
I've been keeping the original post updated with progress as it occurs.
It would be possible to get the .exe working. Other mods have done it and I recall a setup someone made to do an install. I've always been rather unfriendly towards strange executables running on my machine, especially when provided by a random guy on the internet.
The problem we ran into on Sunday wasn't that it was installed incorrectly. It was that someone with modding knowledge adding a tweak to their own version and didn't remove it.
That being said, why not? I'll look into it.
Update: Thanks for bmann's contribution I was able to do it (rather easily), and it didn't take as long as I thought.
Here is a link to the test executable. I'd like 3 people to test it and confirm it works correctly for them (and not just me). It also should be tested in multiplayer and that it works with other Uberfix users (including the .zip version), before I officially recognize it.
There is no readme in the zip file. Or at least there wasn't when I downloaded it.
There should be an instruction file that instructs everyone to do it manually (make the folder, copy the files). Extracting directly always makes a mess of things, but exact instructions for doing it manually will clear up any confusion as to where it should be.
The readme.txt was nested within the UberFix folder. I suppose an additional readme.txt in the base folder providing installation instructions would be useful.
How is this:
Installation Instructions for Demigods Mods in Archive Format----------------------------------------------------------------------------------------Demigods must be updated to version 1.19 or higher.The exact filenames will differ based upon the version you are using. For these instructions I will be referring to UberFix v1.00. For later versions replace 1.00 with your version number.Extract all of the files from the archive to the ..\bindata\mods\ directory in Demigods. For most users this will be: C:\Program Files\Stardock Games\Demigod\bindata\modsThe files should be nested within a folder, such as ..\bindata\mods\UberFix or ..\bindata\mods\UberFixv1.00 Please ensure that the files are not double nested, such as ..\bindata\mods\UberFix\Uberfix.If the files are double nested, simply move the contents of ..\bindata\mods\UberFix\Uberfix into ..\bindata\mods.If your directory setup contains ..\bindata\mods\UberFix\hook your setup is correct.To enable the mod, run Demigods, select the Mod Manager, and select UberFix, and click enable. If the mod is properly enabled it will show up in the right pane of the Mod Manger screen.To delete a mod, simply delete the Mods directory under ..\bindata\mods\.Do not delete ..\bindata\mods unless you wish to remove all mods.If you have problems, please consult the Official Demigod Forums at: http://forums.demigodthegame.com/Enjoy,Ptarth
I just uninstalled my original version (deleted) and used your executable. Works fine and installed to the proper location. Windows 7 64 bit. Trouser did the same (vista 64) and joined a game I hosted. Game worked without any issues.
Had Kalel join as well (vista 64) and test. No issues. So, 3 users tested and confirmed. Front page plz so I can direct folks to that instead of reply #90.
tested with zip version and exe version as well. no problems.
Added Link to initial post. Thanks pacov.
No prob. Thanks for adding it to the 1st post. Much appreciated.
So... I set out tonight to be very patient and play only uberfix mod games. I managed to get > 10 like minded individuals. We took the time, had everyone 1 by 1 uninstall any existing uberfix mod they had, download the current executable, run the current executable, and then launch the game again. So, it was reasonably precise. No instant invalid gamestates. But, each one of these games invalid gamestated at some point in the game. We played maybe 5-6 games - all ended with invalid gamestates at some random duration during the game. Then, I finally gave up and disabled the mod - no more invalid gamestates the rest of the night with pretty much the same people.
This makes me wonder if mods increase the potential for an invalid gamestate to occur. Granted, it could have simply been a number of factors that added up to the invalid gamestates, but I'm quite confident no one was pulling an exploit. I have the unique luxury of being able to reasonably consistently get 5v5 games going now, so that will be my choice for game types. I'm not really sure. I want to use this mod 100% of the time.
Anyway - to summarize: 5v5 games with uber fix mod resulted in invalid gamestates in >5 minutes in 100% of those games. All with people who installed the mod correctly. When the mod was disabled, no more invalid gamestates occurred.
Possible causes of the problem: user error (i doubt, but still possible), issues with individuals internet connections (possibe - teseer had a few crashes with uberfix DISABLED and kalel and I crashed once), coding of this mod (i really have no idea), the way mods are handled in 5v5 games (possible), and whatever else I'm not thinking of.
The .exe version contains nothing new, it is the same version as the 1.00 zip version. Pacov confirmed this himself in his previous tests. Additionally, prior to today I haven't heard of any issues (that the mod was responsible for). I don't disbelieve pacov's report, but I'm pretty sure it isn't the UberFix. As he states, it may simply be that mods add another layer of complexity. Sometimes Demigods crashes (Total Flag control crash for example), anything additional may increase that chance.
Did you check your log file to see if anything shows up in it?
Nothing struck me as off... just typically desync/eject messages. I'll give this another go today or tomorrow and will save the log files.
Hmmm I think we all forgot about this one...
A controversial bug to be sure...
Oak's soul power
Soul Power 1's spirit damage bonus should be capped at 3 spirits? Sould Power II's spirit damage bonus should be capped ar 6 spirits?
Heart of Fire and Soul of Ice descriptions reversed.
There is an icon for each of these modes to let you know you are in it.
The fire one says "Soul of Ice" and the ice one says "Heart of Fire".
Cosmetic, but a bug none the less.
There are many great features available to you once you register, including:
Sign in or Create Account
