Hm, maybe you have answered this question somewhere already, but why did you make 1.01 a separate mod?

I wrote up some instructions to send to someone who was interested in working on the UberFix. I'm going to post them here since they are useful. It isn't completely correct, but it is good enough for an initial start.

---

I code using notepad, you can get a LUA editor, but it doesn't offer us that much in turns of usefulness. The majority of the functions and code we will be writing will have to run within the demigods game itself.

Demigod's uses a hook method of activating mods. That means we will be putting files into a mod directory and the game will add those files when an actual game starts. There are some other ways of doing things, but this is the main way it works.

If you haven't already done so, download the Uberfix, install it, and then browse around the files in it.

The main data file we work with is dgdata.zip. It is downloaded to your root Demigods directory whenever there is an update. You'll want to extract out all the files into a subdirectory (not under root Demigods, you want to keep it somewhere else). The files and file structure of dgdata.zip are what we get to work with. Only files that are loaded when a game starts will we be able to change. If we want to change other things it either has to be outside of the files that the executable runs, or we will have to modify the executable.

Demigods is a Peer to Peer game, which means that to enforce anticheating, it checks all the files during play. It also verifies the hash of the dgdata.zip file on startup. To change the hash is actually trivial, you just have to do a search and replace, but that does prevent you from using the mods with others.

In the Uberfix post in the Mods forum is the buglist. I'm the only maintainer for it, but it is pretty complete. Those are the majority of the issues to be addressed.

To enable debugging, you'll need to open the Game.prefs file located (on Windows XP) at c:\Documents and Settings\<user name>\My Documents\My Games\Gas Powered Games\Demigod\Game.prefs and add the following to the end:

debug = {
    enable_debug_facilities = true
}

Save it afterwards.

The most important technique is debugging and testing code is to run demigods in window mode and to enable the cosole with ctrl+F9. This will show the logger and give you some idea of what's going on. You can also restart a game without having to quit it by pressing ctrl+f10. This will not load new files, only ones that you have changed.

Most of the time what we are going to be doing is tracing down functions that aren't working quite right. This will involve finding the function that is breaking and then searching for the functions that it calls or that call it, which may be functioning incorrectly. The best way to do this is via a direct text search of extract dgdata.zip files.

If you haven't setup your OS to do a decent search of text files, you'll need to do that. Google it on and it should provide isntructions.

There is a list of the hotkeys that the debugger allows you to use. I need to dig it up or you can just search the data file to find it. It is fairly self-explanatory, however most of them don't do anything useful.

Demigods uses the Moho Engine, which is the engine used in Supreme Commander. The version that demigods uses is slightly different, however most of the information is very similar. I use Supreme Commander wikis are a technical reference for somethings.

Many of the functions and properties of objects you'll have to learn about via experience. If you have questions, ask away.

I should also send you a copy of the code that someone else wrote that allows for Logging of tables better. Currently the logging options are rather bad, so you'll find it helps.

I think that is a lot of the stuff you'll need to worry about at this point. Sorry if it is a little disjointed. I was trying to get all the information out there quickly.

Definitely be a normal potion for team mates. Since you have a Lord Erebus ally, you shouldnt be afraid of him killing you that way. Team mate drinks poison blood = normal potion.

Option number 4.

Lord Erebus shouldnt be able to commit suicide, and escape getting killed by the enemy. Right now as it is, you even get gold/xp from killing yourself with your own potion. This shouldnt happen. Erebus drinks his own potion = normal potion heal.

p.s. But if Erebus drinks enemy Erebus's poison blood, it SHOULD do damage to him. This actually might be very difficult to mod, as the game might confuse the 2 potions (your own, or your enemy's).

Well, we have to becareful that we don't imply real world physics into a game. Just because something is called poison doesn't mean it acts just like real poison. Likewise, we could assume that the Erebus gives his teammates an antidote to his blood so it acts like a healing potion.

In the end this is about balance. Should an Erebus's teammates be penalized for his skill choice? Also recall how infrequently this will make a difference. As long as we remove the ability for the Erebus to farm his own death, it shouldn't make much of a difference.

One of the biggest problems with the Demigods modding community is that there is
no central depository of information. This results in much of the work being
very redundant. The Stardock forum, the GPG forum, the Supreme Commander Wikis,
and the currently available mods are only methods of transfering this knowledge
from one modder to the next, and they don't tend to be very good about it. In
following I'm going to record how I went about tracking down the Poisoned Blood
problem with Lord Erebus.

The first part in making a mod, or in this case fixing a bug, is to specify the
current behavior, the desired behaviors, and how the two are different. In this
case the problem is:

Lord Erebus possesses an ability that allows him to drop poisoned health potions
when he dies. When a demigod consumes this potion, he loses 750 or 1500 health
instead of healing. If Lord Erebus kills a demigod with this damage, he receives
credit and gold for the kill. However, there is an additional complication. When
a Lord Erebus consumes his own potion, he also gets credit for killing himself.
Likewise, when he kills a teammate, his gets credit.

The problem with this is that this is abuseable and not fair.
It is abuseable because a Lord Erebus can use the potions to farm himself. He
gains 1500 gold every time he commit suicide. By repeatedly committing suicide,
he could gain a huge gold advantage. It is not fair
because a Lord Erebus can kill himself voluntarily by drinking his own potion,
cheating his enemies out of the rewards for killing him. It also penalizes his
own teammates for having him die, in contrast to other demigods which drop a
useful item for their teammates upon death.

The desired behavior would be for the poisoned potions to kill enemies. However,
what effect should the potion have on allies? This is a tougher question that
moves from bugfixing to balancing. The effect of Poisoned Blood drinking is
trivial, the amount of times this will effect games is very small. However, it
does have an effect. The effect from the original Demigods is definitely
incorrect. At this point, I'm going to tentatively say that our goal is to
have the potions be normal potions of healing for the allies of the Lord Erebus
and be normal poisoned blood potions for his enemies. This allows for the
intended effect of hurting his enemies while not poisoning his teammates.

Since I have now defined the effect I'm trying to achieve, I can now try to
impliment the effect. In this case I need to be able to have the Poisoned Blood
Potion have different effects based upon the team that consumes the potion.

To do this, I need to find the code that relates to the Poisoned Blood Ability.

A search of the contents of dgdata.zip reveals the following files contain
"PoisonedBlood":

• EffectTemplates.lua
• LootDefinitions.lua
• PowerUpDefinitions.lua
• HVAMPIRE_AchievementData.lua
• HOculus_AIBlueprint.lua
• HVampire_AIBlueprint.lua
• HVampire_Abilities.lua
• HVampire_SkillLayout.lua
• HVampire_unit.bp

EffectTemplates.lua
This file contains the emmiters or graphics specifications. There are two
effects that are used by Poisoned Blood. The first is when a potion is consumed.
This is the effect:  PoisonedBlood01. The second is the effect that occurs
around a potion while it is on the game playing field: Health02. Effects contain
entries for Small, Medium, Large, and Huge targets to allow different graphics
for each target of the effect. Each entry is further divided between low,
medium, and high. These refer to the level of graphics that are currently being
displayed. This file is of no interest for changing how potions work.

LootDefinitions.lua
This file contains the Blueprints for the Potions. The Poisoned Blood potions
correspond to HVampirePoisonedBlood01 and HVampirePoisonedBlood02. The blueprint
specifies which PowerUp is associated with the item and also contains a weight.
The weight determines how likely a particular type of potion is to be created.
For Poisoned Blood Potions there is only one choice, therefore weight's value is
meaningless. However, it is present because it is referenced by the code that
creates loot drops.

PowerUpDefinitions.lua
This file contains the Blueprints for the Poisoned Blood Potion ability. The
entry resembles that of an item or ability. This entry specifies the
characteristics of the Poisoned Blood Potion. Two versions of the Potion exist,
one each level of the Poisoned Blood Potion. I will now go over the entry for
Poisoned Blood Potion 1 line by line. Poisoned Blood Potion 2 is very similar,
the differences are trivial.

HVAMPIRE_AchievementData.lua
This file contains the achievements for each of the demigods and how they are
awarded. Lord Erebus has an achievement for having 50 Poisoned Blood potions
consumed. This file is of no interest for changing how potions work.

HOculus_AIBlueprint.lua
This file contains the AI's ability builds for Oculus. The Oculus builds were built using
the template provided by Lord Erebus. It still contains commented strings that
refer to the template. This file is of no interest for changing how potions work.

HVampire_AIBlueprint.lua
This file contains the AI's ability builds for Lord Erebus. Some builds select
the ability. This file is of no interest for changing how potions work.

HVampire_Abilities.lua
This file contains the abilities for Lord Erebus. The Poisoned Blood ability has
two parts. The first is a passive buff to the regeneration value of Lord Erebus.
The second is a change to the loot drop table of Lord Erebus. When a demigod is
killed an item is selected from this drop table to appear. In this case, the
entire drop table is replaced by Poisoned Blood potions. This means that once a
Lord Erebus takes this ability, all of his death drops will be poisoned potions.
Loot drops are somewhat complicated. The drop table is defined in game.lua. When
a demigod death occurs, LootBlueprints.lua determines what item drops based upon
the weights in lootDefintions.lua.

HVampire_SkillLayout.lua
This file creates the skill layout. It specifies the visual display created when
a demigods skill tree is viewed. This file is of no interest for changing how
potions work.

HVampire_unit.bp
Defines when and how abilities are gained.  This file is of no interest for
changing how potions work.

In the log when a Poisoned Blood Potion kills a demigod the following entry
appears: "info: Time : Kill V0". Doing a search for various parts of this does
not return anything.  (Editor's Note: The origin of this is probably interesting,
 but I never traced it down.)

How a loot drop occurs.

1. DeathThread (HeroUnit.lua) calls SpawnLoot (HeroUnit.lua).
2. SpawnLoot performs GetLootTable (HeroUnit.lua) to get the drop table.
3. GetLootTable returns the LootTable from the Demigod
4. SpawnLoot gets the Demigod's level.
5. SpawnLoot calls CreateLoot (LootBlueprints.lua) with a list of loots from
6. the loot table indexed by the Demigod's level.
7. CreateLoot selects a loot item from the Items it was given.
8. CreateLoot calls CreateDroppedItem on the loot item.

Now, one important question, is how does the game known who created the potion.
Looking back upon the code, there is no immediate obvious answer to this question.
However, whenever a Demigod dies to Poisoned Blood Potion, the Lord Erebus gets
the kill and the gold. This suggests that there is information being carried along
with the potion, that isn't obvious. When your investigating a charcter
can select its properties can be seen in game by opening the console and
pressing shift+F7 (I think). However, items are unselectable, so that doesn't work.
The best solution I have is to include LOG comments in functions that are used
by the object. (Editor's Note: Another curious find is that when Lord Erebus is
killed by his own Poisoned Blood potion, the game does not count it as suicide.
However, when a Demigod consumes a potion that gives them -100000 health, it is
counted as a suicide. This is interesting, but I haven't check out why it occurs)

In this case, we have another lead. This lead comes from the awarding of credit
for kills. This requires tracing what happens when demigods die. There are
(at least) three places that contain this information.
DeathThread (heroUtil.lua) is the function that deals with removing the demigod.
ForgeUnit.lua contains the damage and death functions
Conquest.lua contains the rewards for killing units and heros.

It seems that the Poisoned Blood potion may be bring along an instigator field.
This would explain how the Poisoned Blood potion credits the Lord Erebus.

Given this information, the route I chose to fix the problem was to used nested
buffs. The declaration for the effect of the Poisoned Blood potion is in the
PowerUpBlueprints. PowerUps do not have all of the inbuilt functions that Buffs
have. It would be more elegant to add features to PowerUps, however with the
UberFix I'm trying to avoid changing things too drastically. The feature that
I am looking for would be called OnApplyPowerUp. However, since it doesn't
exist, I'm going to use Buffs.

The nest Buff solution is to apply the initial buff and then have that buff
apply a new buff. The first buff will do nothing besides specify the second
buff. First I'm going to show you the completed code, then I'll discuss it in
more detail.

There are two features of note in this code. The first is the OnApplyBuff function. This function allows for other functions to occur when the buff is first applied to the target. There is another counterpart function, OnBuffAffect. I believe this occurs each time the buff pulses. (Editor's Note: Buffs can be set to pulse every X seconds. When this occurs a specific effect occurs. This is displayed in abilities like Lord Erebus's Vampire Creation Aura and the Queen of Thorn's Compost Aura).

The first buff, HVampirePoisonedBlood01, when applied checks to see if the
consumer of the potion (unit) is a teammate of the Erebus who dropped the
potion (instigator). If it is an ally, the HVampirePoisonedBlood01Heal buff is
applied. If it is an enemy, the HVampirePoisonedBlood01Damage is applied.

The only other tricky part is:
            Affects = {
                Health = {Add = 0},
            },
Looking at the code, you should note that it doesn't do anything. In fact, the
Buff code terminates early because there the value is 0. However, this snippet
is important for the AI. To detect and use potions, the AI relies on the
PowerUpBlueprint having a buff that contains an affectType (Health, Energy, etc)
and an Add or Mult value. In moving to a nested buff solution I removed this
line from the Buff declared in the PowerUpBlueprint. I couldn't move the
secondary buffs into the PowerUpBlueprint because they would then all be
performed when the PowerUp was activated. (Editor's Note: Credit goes to Peppe
for helping me figure out this part). In this snippet is not present, the AI
will ignore the Poisoned Blood potions.

That should be about it. If you have questions or suggestions on how to make all
of this more clear, please post them. Hopefully we can start making more
tutorials and editorials on how the LUA in Demigods works.

Update: Torch Bearer Fireball Slow Down Bug

Teseer reported that the Torch Bearer occasionally has Fireballs that are very slow. I tried to replicate this a number of ways and I was only able to reproduce it in one way. However, I think this might explain his observations.

When a target teleports after a fireball is in flight, the target seeking features of the Fireball activate. In the Fireball's projectile file there was no acceleration. This means that as long as the fireball was headed in the generally correct direction, there wasn't a problem. However if the target teleports to a location that requires the fireball to drastically change its heading, the fireball slowed down because it couldn't accelerate in the correct direction (very quickly at least, it still does, but it is a small value). If Teseer was playing against players with very fast movement speeds or that teleported (Bat Swarm, Cloak of the Night, Demon Assassin or Teleport Scroll), this behavior should be reproduced.

To fix the problem I added Acceleration and MaxSpeed to the Fireball03_proj.bp (which is the fireball currently used in the game for the Torch Bearer's Fireball).

If Teseer or anyone wants to test this to confirm, here is a link to a test mod that contains the Fix. It changes Fireball 1 to have a longer range and shorter cooldown so you can test it more easily. It also contains a modified Scale Helm which adds viewing distance to make sniping it easier. (It also contains a few other bits and pieces which aren't really important, leftovers really).

Also, does anyone have any experience with how often the Torch Bearer's regular attack misses? I was toying around with him today and occasionally his projectile would display the same problems as his Fireball ability. I wasn't sure if this is an issue or not.

I really dug the in depth walk through.  Good read.  Thanks for posting.

The suicide code is generic to all demigods. It occurs whenever the instigator is the same as the unit that dies. I'm not sure why it doesn't fire when a poisoned blood potion takes effect.

Here is the snippet from conquest.lua that is relevant.

Update: Ooze

Well, I feel reather stupid today for two reasons.

1. When merging blueprints the statement is:

• Merge = true,

On the other hand if you use:

• merge = true,

Demigods will infinite loop with a message reporting it failed to find the correct mesh for the modified unit.

So remember kids, table keys are case sensitive.

2. When trying to figure out if an ability has an intended effect, check the code first.

Looking at the Ooze code, it actually possesses the correct code to kick the Unclean Beast out of Ooze when low on life. There are two problems with it though.

1. The Ooze exit check takes 1 tick to perform, that means you'll take an extra hit of damage. Combined with taking damage before the last tick, you can then experience the suicide effect.
   
2. Like Mist Form, the ability exit check has a hardcoded cutoffs. Also like Mist Form the cost of the ability was changed, but check was not updated to reflect this change.

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.

For those who are interested in the code, here is the original and below it is my fix for Ooze 4.

As you can see, I made a couple of changes. First, I move the Buff.ApplyBuff (which causes the damage) down and inside the if statement. If the Unclean Beast fails the health check, then and only then is the Buff.ApplyBuff ran. In contrast in the original version the check was made AFTER that Buff was applied. This is what caused the 1 extra tick effect to occur.

My guess would be that it is a coincidence.

Consider this, the person who wrote the death code is most likely not the person who wrote the Demigod Abilities code, especially the Unclean Beast's code. What I would expect is that whomever wrote the death code added it in as a possible outcome, without knowing if there was an ability that would trigger it. It would be the same for someone who was writing the healing effects. You wouldn't write one just to add health and stop. You would add one that can handle health, energy, etc.

I'm not sure I can back you up on that claim.

First, I'm not a professional programmer, so I'm probably not qualified to have an opinion on the subject. However, ignoring that, it doesn't seem to unreasonable for this sort of random occurence. The individual steps leading up to all of these are reasonable. It makes sense to code the contingency for a demigod killing itself and giving it a different message. It makes sense that the person who originally wrote the Ooze code to have written it the way they did. It also makes sense for the person who balanced the Ooze ability to not consider the possibility that the Ooze could lead to suicides in rare cases.

Looking at it from a bug perspective, it is a very minor flaw. The frequency of the event is tiny, it requires a UB near death to have Ooze on. Likewise, no one really was convinced it was a bug until I got around to looking at the code just recently. Given that it has escaped notice for this long, I willing to say that it wasn't something that we should criticize GPG's professional skills for.

So, back on page 5 TrouserSnake69 suggested that Oculus's Sacrifice skill didn't work. However, not one verified or agreed with him, nor did he sound confident he was correct. It turns out that not only is he correct, he also found a potentially huge bug.

The problem is how Demigods treats the NOT statement. Typically NOT is used to indicate the presence of a variable, here is an example:

In this case, IF data.Radius lacks a value then an error is reported.

However, in Sacrifice the following is used:

The intent of this code was to check to see if Entity V is an Ally of Unit and is also not the same as Unit. If both of these are true, then heal the unit (data is a negative number so it is a heal). Notice that NOT is supposed to apply to the outcome of (unit == v).

However, if we verify this using a True Table. We find something troublesome and interesting. By including a log statement in the previous code snippet I generated the following table.

 

Unit	Oculus Team	Unit Team	isAlly(Oculus,Unit)	not Oculus == unit	not(Oculus == unit)
1	1	6	TRUE	FALSE	TRUE
2	1	1	TRUE	FALSE	FALSE
3	1	6	TRUE	FALSE	TRUE
4	1	6	TRUE	FALSE	TRUE
5	1	6	TRUE	FALSE	TRUE
6	1	6	TRUE	FALSE	TRUE
7	1	7	FALSE	FALSE	TRUE
8	1	7	FALSE	FALSE	TRUE
9	1	7	FALSE	FALSE	TRUE
10	1	7	FALSE	FALSE	TRUE
11	1	7	FALSE	FALSE	TRUE

We find that NOT (X == Y) is not the same as NOT X ==Y. (This is seen in the last two columns).

NOT X == Y only confirms if X has a value. NOT (X == Y) does the check that we want.

This broke Sacrfice because NOT Unit == V was always FALSE, so the heal effect never occured. (Since Unit always exists, NOT Unit is always FALSE).

Why is this so troublesome? Well, NOT X==Y being the same as NOT (X == Y) is pretty standard in programming language. Its absence is unexpected. This means that there may be additional effects in the code where the writers intended NOT (X == Y), but wrote NOT X == Y. This should be verified, and that's a lot of work.

Also, I fixed Sacrifice.

 

ptarth - debating about the release of 1.02 instead of keeping with 1.01 for the tourney.  Is there anything you are working on atm that you were thinking of rolling into 1.02 or could you go live with 1.02 (as a beta initially) with what's listed in your changlog currently? 

Hmm... if its good to go in your opinion, please release 1.02 as a beta asap and link to it in the op.  I'll get people using it asap then.