On Occ's auto-attack - this might have been covered previously, sorry if so, but -

Occ's auto-attack isn't target-dedicated if the primary target is out of range.  So if you select UB as the target, for example, but he is at range 25, then Occ will treat it as an attack-move, and attack every available enemy target while moving up to the UB.  

Occ's attack speed is pretty low, so if you are trying to kite somebody but shoot at that mino instead it gets kinda frustrating.

Thanks 

re: http://forums.demigodthegame.com/379675/page/4 and re:http://forums.demigodthegame.com/374315/get;2597455

The list Frogboy posted was actually formed predominately from the list I created. I've updated the OP so the cross references don't match up, but if you look at the list you can see references to #8 and so forth. These were the original bug numbers on my list. This isn't to say that there were some additional bugs added (there were, and I included after Frogboy posted them).

I've been avoiding posting in that post because I don't people to get upset over what is and is not being done. The commitments from SD have been some assurances that Frogboy is still supporting Demigod and that he will try to get the UberFix added into the base install. His language has been nebulous if this would be as an official patch or as an addon mod. I've also been in contact with Sorian and he has promised to look in on us every now and then and has answered some questions about Demigod code. He was relatively recently hired and is only familiar with the DA & Oculus updates. However, he has been kind enough to question some of the original team for me. I haven't bothered him with many questions because I don't want to overwhelm him with things.

Also, GPG just released Supreme Commander 2, which means they are focusing on it with all of their resources. I don't think there are any immediate plans to work on Demigod until they have fixed Supreme Commander 2. I've requested documentation for Demigod, however the question was never directly addressed. I'm taking this as meaning the documentation does not exist, it was not available to my source, or it is for in house use only. Given how the Supreme Commander 1's modding community is treated, I'm guessing either the first or the last. It is understandable that GPG wouldn't want to give away industry secrets though.

re: Thread Organization

I've tried to organize the thread, but there is only so much I can do with the manpower I have available to me. Including full documentation links in the OP sounds like a good idea, but it is going to be a lot of work. I'm not sure having a bug tracking system would be necessary at this point. At one point in time there was a Demigod modding site which I put some time and effort into updating. However it went down and disappeared. That annoyed me, but I understand. If someone wants to go ahead and recreate the buglist adding in the appropriate thread references, I'll be glad to update the OP.

re: SD & GPG Help

Several months ago Frogboy did a monthly question and answer post (he sadly stopped doing it without warning, but given the horrendous community backlash against completely fair answers it was also understandable). I'm tempted to try to get a list like that operational and send it to GPG to see if we can find some answers. There are a number of problems with this though.

• It would take a large amount of time to compile and organize the list.
• It would require grammar and syntax styling to make it useful and appropriately referenced.
• It would take a large amount of time for GPG to answer them.
• It would not be financial viable for GPG to do it, and would only be done with developers free time.
• GPG has no obligation to answer these questions and it is offensive to think that we deserve the answers.
• Including all of the issues would make the size of the list intimidating and would be unlikely to encourage responding.

One of the biggest problems is that people think that GPG and SD owe us something, they don't. They made Demigod. It is a playable game. It does have some issues, but for the most part it works. If we want to get something done, we need to do it ourselves and then ask GPG/SD for help after we have demonstrated how much we are willing to work. GPG/SD write code for their livelihood. It is unreasonable to demand they perform work that they will not be paid for. Anything they do is essentially for charity, and a business ran for charity doesn't feed your family.

re:Oculus Autoattack on Out of Range target converting to AttackMove

This isn't exactly true. I've tested before and I retested it just now to make sure. The behavior is not displayed. However, what I think you are seeing is the same attack order issue that hedgie has reported with the QoT. I still haven't been able to follow his directions to duplicate it, but I'm willing to believe it does exist. I'm not sure what exactly is causing it, nor the situation that causes it to occur.

I can try to get a Mantis server up on my secnodary computer if you would like. It's been forever since I've looked into setting one up so no promises. I use JiRA at work and love it but I don't think there is a free version of that. 

It would probably be extremely useful migrating to a bug-server rather than forcing Ptarth to keeping this up-to-date since he is the only one able to post things. 

But you guys will have to wait for Ubuntu 10.4 to come out in 3 days ~~~

I would do more coding if we had a Subversion server set up and we could commit at will. 

Though I won't promise that Sedna's heal I may be 6000 instead of 600. oops :3

I spent about a half hour trying to fix some formatting in the OP for the buglist, but I gave up in the end. If we do transfer over to Google or something else, this work would be redundant, so I'm skipping it for now.

1.03 Patch List (unreleased)

1. Knockback XP fix by Ptarth
   1. Units that die because of knockback should now reward experience and gold correctly.
2. QoT and TB Form fix by UhelligGudn
   1. QoT and TB should now come back to life in the same form they died in.
3. Selling Favor Item Fix by Ptarth
   1. Useable Favor items can no longer be sold.
4. Regulus Maim Fix by Ptarth
   1. Regulus will no longer maim allies.

Heh I like my description in the post Amen on the updating lists, who knows what goes on with this weird forum I have posts disappearing, my number of Karma bounces up and down all the time, and editing threads sometimes just does absolutely nothing.

Edit:

I'm thinking of tackling the health bar zoom problem next, has anyone looked into this already? I'm hoping this is something that should be LUA only so it should hopefully be fixable without running into a dead end.

Yeah it happens to me in game all the time because I'm zoomed out so far and it's really annoying, so I figured I'd fix the bugs that annoy me most first

Edit:

After much hopeful searching it appears that there is no way to adjust the life bars that float over each units head. There is a way to modify how far away from the player the health bar floats, but that is about it. You can modify the players HUD health bars, but it appears that the unit health bars are not only rendered in game, but there isn't even a call in the LUA to the render health bars function, it is however toggled on or off with ConExecute('UI_RenderUnitBars true') then the game does the rest of sorting out what bar to show and how to render them. Fairly disappointing really, someone may wish to spend a little while looking over this error just to make sure I am not mistake but it seems yet another bug headed for the "undo-able" pile.

If anyone is interested in a head-start on checking this issue, as far as I can tell they are referenced as "lifebars" in terms of the function that is called when the tilde key is pressed, then that calls the renderunitbars function which essentially just leads to a wall. I also looked for any functions that may have set the values and then render just rendered based on those values (since it would make sense that render didn't do calculations) but I cannot find any such location of calculations or values, only values to position the health bar.

I figured since I failed at fixing up the Health Bars issue I may tackle either or both of these, any information on specifics would be helpful or any failed or otherwise attempts at such bugs.

1. Rollover Data Error on flag tooltip while being captured behind fog of war.
   
   
2. When a demigod switches primary weapon the window information doesn't update properly (mainly a QoT issue)
   1. This is a visual glitch, the weapon does change, but the window does not update correctly

info: 00:18:29: Setting audio parameter 'WARSCORE' to value '2.000000'
debug: 00:18:53: Loading module '\000/lua/usermusic.lua\000'
warning: 00:19:04: Error running lua script: ...games\demigod\dgdata.zip\lua\system\localization.lua(131): invalid option to `format'
         stack traceback:
             [C]: in function `format'
             ...games\demigod\dgdata.zip\lua\system\localization.lua(131): in function `LOCF'
             ...ardock games\demigod\dgdata.zip\lua\sim\flagunit.lua(72): in function `ArmyLosingFlag'
             ...ardock games\demigod\dgdata.zip\lua\sim\flagunit.lua(324): in function `CaptureFlag'
             ...dgdata.zip\units\un\b\unbflag01\unbflag01_script.lua(12): in function `CaptureFlag'
             ...ardock games\demigod\dgdata.zip\lua\sim\flagunit.lua(266): in function <...ardock games\demigod\dgdata.zip\lua\sim\flagunit.lua:112>
warning: 00:19:07: Checksum for beat 1650 mismatched: 0a254d73fbf10e82829d8c3649e6ef5e (sim) != 0940ce107389c3ee3b311a3effd92a28 (pacov).
debug: 00:19:07: Loading module '\000/lua/ui/dialogs/desync.lua\000'
warning: 00:19:13: Checksum for beat 1700 mismatched: 6e3b631901d9c7871a3f3bc4d2867bf3 (sim) != 4e3fc9c5aca336a4d1c793b58e97e088 (pacov).
info: 00:19:16: Closing connection to Pc:54386:54386 because of end of input
info: 00:19:16: Eject of pacov[28414] requested by NeVeR-FuCKWiT-aOaK[70326]
info: 00:19:16: Sending conn info

Log from test me and pacov did

Exactly how it happends:

One side caps all the flags, then if enemy caps one flag the audio file "forces of ... control the map" plays and desync occur.

Funny thing that I have noticed is forces of light will always get this error at first time when playbacking "forces of ... control the map" while it takes 3 or 4 times for the forcess of darkness for this to occur.

another thing.

"info: 00:19:54: LOBBY: Processing LOBMSG_PublicScriptData message
info: 00:19:54: GI = \000{
info: 00:19:54:   GameMods={ },
info: 00:19:54:   GameOptions={
info: 00:19:54:     GameType="conquest",
info: 00:19:54:     conquest={
info: 00:19:54:       AiGoldXPValue="Low",
info: 00:19:54:       AiHitpoints="VeryHigh",
info: 00:19:54:       DeathPenalty="Normal",
info: 00:19:54:       ExperienceRate="Normal",
info: 00:19:54:       FlagCaptureTime="Moderate",
info: 00:19:54:       FogOfWar="explored",
info: 00:19:54:       GameSpeed="normal",
info: 00:19:54:       GoldIncome="High",
info: 00:19:54:       GruntStrength="Low",
info: 00:19:54:       ScenarioFile="/maps/map05/map05_scenario.lua",
info: 00:19:54:       SpawnRate="Normal",
info: 00:19:54:       StartingGold="Rich",
info: 00:19:54:       StartingLevel="Twenty",
info: 00:19:54:       StartingWarRank="1",
info: 00:19:54:       Timeouts="0",
info: 00:19:54:       TowerStrength="Normal",
info: 00:19:54:       Victory="conquest",
info: 00:19:54:       WarScoreIncome="Normal",
info: 00:19:54:       achievements="true"
info: 00:19:54:     },"

This is from log when I hosted the game. My question is: can we thru mod disable achivment rekording by swithing info: 00:19:54:       achievements="true" to false?

I know is not really a bug fix but - currently stats are broken and by habing mod that allows you to play unranked games will somehow be a solution. Sorry i have never created mod so i cant really help much with this.

So the conditions sufficient to reproduce the Critical Game state.

•      Friday
•      1v1
•      4 AM in Australia vs 12:00 PM in California
•      NAT vs no-NAT
•      Russian Version vs English Version
•      Modified Version of Cataract
•      Light player captures all of the flags and then a flag returns to neutral (Dark player captures one)
•      WindowsXP vs Windows 7
•      Irek vs Ptarth

I'm looking at the logs to try to make sense of what is going on. The best clue I currently have is that after the Forces of Light have complete flag control and they lose one of their flags, a localization error occurs. A critical game state then occurs 1-6 seconds after this event. This was replicated 5 times, so I'm pretty sure it is real.

I found the problem

The string definitions used in Demigod are case sensitive. This can lead to problems, one of which is when two strings exist that only differ by in case only. In the following I show examples of this, as well as what is most likely causing the problem. The following are excerpts from strings_da.lua from the English, French, and Russian string_db.lua files.

English

•     * FLAG_0000="Cooldown times reduced by [GetCooldownBonus]% for the controlling team. Grants controlling team members access to the Celerity Battle Standard."
•     * FLAG_0001="Cooldowns decreased."

French

•     * FLAG_0000="Temps de refroidissement réduits de [GetCooldownBonus]% pour l'équipe qui le contrôle. Fait profiter les membres de cette équipe de l'Etendard de Refroidissement."
•     * FLAG_0001="Refroidissement accéléré."

Russian

•     * FLAG_0000="У команды, овладевшей флагом, перезарядка на [GetCooldownBonus]% быстрее. Все члены команды получают доступ к боевому флагу перезарядки."
•     * FLAG_0001="Перезарядка проходит быстрее."

So, the first two entries, FLAG_0000 and FLAG_0001 are the tooltips for the Celerity Flag (I'm not sure they are used in game). Comparing across languages it is apparent that they are similar. Also, notice that all contain [GetCooldownBonus]. This is the syntax that is interpreting to allow the strings to referenced defined values in the blueprints. In this case, GetCooldownBonus is defined in the blueprint of whatever calls FLAG_0000.

Now, let's look at another set of strings.

English

•     * flag_0000="The Forces of Light control the map!"
•     * flag_0001="The Forces of Darkness control the map!"

French

•     * flag_0000="Les Forces de la Lumière contrôlent la carte !"
•     * flag_0001="Les Forces des Ténèbres contrôlent la carte !"

Russian

•     * flag_0000="У команды, овладевшей флагом, перезарядка на [GetCooldownBonus]% быстрее. Все члены команды получают доступ к боевому флагу перезарядки."
•     * flag_0001="Перезарядка проходит быстрее."

Notice that the French and English strings match. Now, check out the Russian version (at least I assume it is Russian). Notice that flag_0000 contains [GetCooldownBonus] only in the Russian version. Also notice that FLAG_0000 and flag_0000 for the Russian versions are identical. I believe that happened is that flag_0000 was replaced by FLAG_0000 somehow. When flag_0000 is called it then wants to call have [GetCooldownBonus] defined. However, since GetCooldownBonus is not defined, it errors out and causes a desync.

The solution is to fix the strings_db.lua for the Russian version by removing the [GetCooldownBonus] from flag_0000. Ideally you'd want to replace the faulty string with the correct one, but either way the problem would be resolved.

FIX RELEASED Beta (but I'm pretty sure it works)

If you use the Russian localized version of Demigod, the following will fix your problem:

1. Find the following files:
   1.  ..\Demigod\loc\RU\strings_db.lua
   2.  ..\Demigod\loc\strings_db.lua
2. Make backups of those files.
3. Download the fixed version of the Russian strings_db.lua
4. You'll need to make 2 file replacements
   1. Replace ..\Demigod\loc\RU\strings_db.lua with the fixed version.
   2. Replace ..\Demigod\loc\strings_db.lua with the fixed version.

I will be working on getting a server with JiRA up today since Ubuntu came out. 

The "free" version of Jira actually requires making a $10 donation to charity :-/ I'm going to work on finding a torrent unless someone decides to support me ^^;

There is a trial version so I'll be doing that at first. 

Do you need to replace the entire RU version with the US version? Surely you could just fix the problematic lines or such, wouldn't that be faster than re-translating it all? Or am I just confused?

Correct me if I'm wrong, anyone - if you just replace the RU version with the US version - that would work... but Russian speaking players would then hear and see US localizations (eg no more russian translations are spoken).  If you tell me the fix if for me to hear and read everything in german, I'd be pissy