Do we really need to retranslate it all? How I understand it, you just need to remove the variable in strings_db?

And is this "hookable" or not? 

---

On a side note, PS3 takes foreverrrrr to install to. I installed it once but got locked out of root for some reason. Will be spending most of tonight optimizing performance and setting up Jira and also setting up permission/user levels and port forwarding. There won't be any personal information on this so don't try  

Luckily, I'm not too worried opening my ports to the world since Sony has several DRM restrictions in place to minimize using Linux to hack Sony. They still don't know how to read the Sony filesystem and it's also unmountable. There's also a lot of other stuff in the way. Even if they do get sudo access, I'm not too worried: it's only a PS3 and I can reformat it if I need to. 

I'm thinking of hosting SVN on here as well, or whatever else. We have 10 GB to play with and all dedicated to uberfix so... I can host common files, executables, new versions, etc. Does anyone going to need SSH access? I can open up and create an ssh account for people I trust... 

re: Russian Forces of Light control the Map Fix

So, only two strings in the file were altered (to fix the problem). Both were mistranslated. Only one of these strings effected game stability, but I fixed both. These strings are flag_0000 and flag_0001. The translations I used were based on google's translation, but matched the Cyrllic letter patterns in the other strings.

I don't know how many of the other strings are incorrect. My Russian is nonexistent.

I've uploaded the file, I'd appreciate it if it could be tested to confirm it works.

I've updated my previous post to point to the download.

According to Irek, the Russian version does not actually contain very many Russian language sound files. Additionally, anything that was added post-release seems to be only English. That includes all of the Demon Assassin and Oculus text.

So, to fix it there are a couple of ways.

• The first is to edit the strings_db.lua and just remove the function. However, the string was still completely wrong. Instead of saying "The Forces of Light Control the Map" it says "Cooldown times reduced by [GetCooldownBonus]% for the controlling team. Grants controlling team members access to the Celerity Battle Standard." (at least in Russian).
• The second was to just replace the strings_db.lua file with an English one. It works for a quick fix, but obviously isn't a great solution, hence why I presented it along with my initial findings and then started working on fixing the other part.
• The third is to edit the lua that calls the on screen presentation of the message avoiding the call to the faulty string.
• There are more, but I'm sure you get the idea.

I'm not sure if I could hook it or not. I don't think I can hook a file that is not within the /bindatadirectly. However I think I can change where the game looks for the localization file.

However, it isn't an elegant or an appropriate fix. I could hook everything, but it is unnecessary. The files should be replaced because they are incorrect. If the updated file is correct then it can be used without any incompatibilities with anything. Furthermore it is actually more stable that the current version. That being the case, I believe the file should be completely different from the UberFix.

I'd like to thank Irek for being instrumental in facilitating the documentation of the Forces of Light bug. His continued belief and active posting in the forums was one of the leading causes to why I believed the bug did exist. This was in spite of the stance by active forumers and Stardock. It was only with his help and testing efforts that the bug was able to be tracked down and solved. I really appreciate his assistance in this matter. His help in this matter is doubly appreciated because he stayed up all night and was still willing to put up with my efforts and attempts to solve this issue.

Thanks Irek. Sorry your credit was lost in my previous revisions. I got caught up in describing the behavior and didn't realize it.

So we are getting the hosting setup.

• Awuffleablehedgie is setting his PS3 up for UberFix hosting.
• I have also started a project on Google Code.
  • If you'd like higher levels of access to the Google Code site, please contact me with the gmail account you want me to grant access.

Reminders:

• Add Fix Map Control Logic to Buglist
• Add nonranked game mod to Todo list
• Add SkillInfoMod remake to Todo list
• Add Fix Oculus Ball Lighting Tooltip to Todo list
• Add Fix Oculus Blast Off Tooltip to Todo list

Ptarth, while you are working on Occ, the targeting issue I mentioned at reply # 351 is worse than I thought.

1.  Oculus will sometimes auto-attack any available target in range, even if you are explicitly selecting a target in range.  So I target Erebus, Oculus attacks the monk next to him.  This is repeatable when multiple targets exist and completely negates any range/kiting advantage cow is supposed to have.  They should have taken the attack pathing code for Regulus and copied it, rather than whatever they did to reinvent a square wheel on this one...

2.  Manually switching targets for auto-attack appears to reset the attack cd.  Select target, attack procs, select new target halfway through cd and cd resets, meaning next attack takes 150% as long to proc.  I haven't tested this one, so it might be in my head only, but see if you see what I'm saying...

Re: Ke5trel on Oculus

1. Oculus randomizes target for autoattack

Do you have any specific way to replicate this? I've been watching his attack and I haven't seen it.

2. Oculus resets attack when switching targets

I believe this is the desired behavior. It is also Engine based, and I don't think I have access to anything to change it. As far as the engine goes, you start an attack, the target disappears, so it restarts the attack. Part of this I believe comes from how they designed the engine to work for Supreme Commander, which primarily deals with projectile weapons. If your target suddenly dies before your attack hits, you don't suddenly return to a state before you've fired your weapon. You have already committed, so you continue your attack. Additionally, you should be able to switch targets at the 50% mark an infinite number of times leading to an attack that is always about to happen, but never does.

Good question, I'll try to narrow it down a bit this week.  I've seen it most when two creep waves meet and fight, opp DG is in the mix, and Occ fires at every other baddie rather than targeted DG.  If you want something which is probably related that can be easily replicated -

1.  Occ targets opponent DG from outside Auto-attack range

2.  Occ moves to achieve range of target DG

3.  Occ will auto-attack enemy units encountered on way to range of target DG.  No other DG does this AFAIK

and

4.  Occ will sometimes achieve range of target DG and continue to attack random enemy units

Re: #2 -

Good answer, thank you.  Unfortunately that makes manually tagging creeps more trouble than it's worth, but w/e 

re: Ke5trel on Oculus autoattack Issue #1

• I still can't reproduce it. The only idea I have is that it is an online only issue? I'm not sure. Can you replicate it and send me a short replay? Thanks

re:Ke5trel on Oculus Autoattack Issue #2

Well, tagging creeps is worth it, just do it proactively. You just need to do 25% damage to each reinforcement prior to its death to get gold for killing it. So just hit each reinforcement once and switch targets. Once you hit them all let Oculus autoattack at his leisure. (I'm sure you know this, but I'm including it for the at home viewers)

LAWLZ

Ptarth deleted my posts! Oh Noes!

"Successful Troll is Successful"

I'll see if I can replicate and send you a replay.  I see it consistently in kiting, it's just hard to determine which part of the kite triggers it. 

Re: tagging - manually attacking each creep, given the engine limitations you've laid out, is most cost-effective if you can switch targets immediately after last attack procs.  If you switch targets any later in the cd then you force the cd to reset, which means your DPS drops and you aren't farming much more efficiently than you would be without attacking at all.  

Cheers

Ke5trel: does it happen after using an ability? Because this happens with every Demigod sometimes. When you execute an ability, your Demigod ignores any attack order you give him. You have to make a normal move order and then you can order him to attack again.

I spent probably over 10 hours this past weekend fighting Linux :sigh: Not having root priviledges, installation issues left and right, not being able to mount my drives... ugh. Anyway, I have JiRA built on my computer now but I have to figure out how to connect to my encrypted wifi through a command line interface  

I'll work on getting SSH and FTP setup to it and then migrating bugs over and setting up access-control before I expose the IP address and ports. 

You know if maybe we could get a small sub-forum for this? It would help with discussion about bugs without derailing the whole thread and we leave this stickied thread for release-announcements. 

Spooky - no I'm familiar with the ability freeze bug and the random target issue is something else.  It happens when no abilities are in play, and the easiest way to repro at least one part of it is to have Occ move through a group of enemies on the way to a selected out-of-range target.  Occ will attack the non-selected enemies on the way.  I can't think of another DG that does this, and my theory is that it has something to do with the bigger issue of attacking non-selected units rather than selected ones.  

TL;DR Occ can't kite. 

re:morpheas768

I do not have moderation privileges and did not remove your posts. However, I did find them bothersome as per my private request to you to remove them. I am saddened that you believe that all of the work done on the Uberfix is insufficient to encourage respect in posting. I shall not address this further.

re:hedgie on PS3

Sounds good.

re:hedgie on Forums

The google code site has a forum, a bug repository, and a wiki. I'm considering utilizing those resources which would allow us a lot more flexibility in arranging information. I'm sure everyone is aware of how highly I value proper documentation. I am not aware of any other subforums hosted on the Stardock Forums for mods such as this, so I am hesitant to ask them. If they would support us, that would be great. However, I'm not going to impose upon them and demand things from them. The community has already provided a tremendous amount of ill-will towards Stardock that was misplaced. I do not wish to further burden them with such abuse.

Another thing that makes the Google Code site attractive is that it is independent of a particular user. When the dgmodding.com site went down, I lost a decent amount of work that I had contributed. If we use a site that is external to a person, if anyone, including me, decides to leave amidst project with no warning, work can continue with us. It is unfortunate that the site will not directly link to the Forums here, but it does offer other advantages.

re:Oculus Auto Attack

I believe this is identical to a previous bug described by hedgie in the thread regarding the QoT's attack move. His report of her behaviors were identical to yours of Oculus. However, I was unable to duplicate the issue even with his step by step instructions. I'm not sure what is going on.

re:UberFix on Google Code

I'm starting to transfer information over to the site. If anyone wants to help out by moving information, adding bugs, whatever, I'd appreciate it.

Link to Google Code: Uberfix

Wut?

But....but....but, someone deleted mah postz! Oh Noes! People dont like my presence here, why? What did I do?

Oh I know what happened: You liez Ptarth! You deleted mah postz!

Hmm....I think you're serious here. Fine. I will be serious too, but just for a few seconds. I dont disrespect all the work you have done on the Uberfix, however, I find this thread to be very professional and serious, so I'm here to change that a little.

After all, 1 post per day is not like evil-trolling right? I'm just an innocent troll

"Successful Troll is Successful"

Haven't really used google code before, is there anyway to color code bugs or such so we could easily distinguish which bugs have been looking into (such as life bars being likely impossible) from those no one has looked into at all?

Sorry I didn't see this before, but yep QoT and Occ, as the ranged generals, have exactly the same targeting issues.  I will be on tomorrow so I'll try to get a quick replay just to repro. 

Ptarth: You CAN delete people's posts in your own thread of course. Didnt you know? Just go to impulsedriven.net

So.....yeah I'm gonna post here, until Ptarth starts deleting my posts

Anyway, how are you guys? Any news?

"Successful Troll is Successful"

re:Google Code

I'm just making up stuff as I go along, but I think we can do something like this. I've added a Progress keyword to each bug report. If you add the label "Progress-[whatever]" it will show up like that in the Progress column. You can then sort by the Progress column.

re: Ranged Attackers switching targets

I made a break through on this. The problem isn't that ranged attackers can't lock onto a target. They do so just fine. The problem has to do with squads. More specifically, it has to do with Generals who have active minions. I was unable to reproduce this because I didn't summon minions. When you select and order around a squad, the behaviors of your units change.  I only did a quick test because I'm at work, but I'm guessing the gist of the problem is:

• My old leader hypothesis isn't correct.
• Whenever minions are selected with your general, they take priority
• When you give an attack order
  • Your Demigod is given a move attack order
  • Your minions are given attack orders
• I also found some odd behavior in squad movement which I haven't narrowed down yet.

Edit: Updated with more testing

Oh snap.  I think you got it! 

I'm always moving a monk with the DG, so if the monk is the 'leader' then it makes perfect sense that the DG is doing an Attack Move. 

Is there some way when selecting multiple units with cursor drag to have it default to the DG as primary?

Can anyone confirm which unit becomes the "leader" if you use the M hotkey or whatever it is to select both your DG and your minions?

So, my previous hypothesis wasn't quite right.

As far as I can tell, having any minion selected will always take presidence over your Demigod (regardless of the method of selection). This causes some interesting behavior which is entirely squad based as far as I can tell. The first is the move/attack order. When you give a selection of Demigod/Minion an attack order, the Demigod receives a move/attack order and the Minions receive an attack order. You can tell what your target is by looking for the red targeting ring. If your target has the ring, then your demigod should correctly attack. If not, the targeting ring should jump around based on your Demigod's current target as he moves around.

The second is that when your Demigod is part of a squad, he moves very awkwardly. You can reliably lockup Demigod movement while having Demigods and minions selected and trying to move around a corner in cataract. You will get stuck on the towers.

This might be causing the attacking problem:

Great find, nice to see that it might be fixable in LUA. Doesn't exactly explain the sluggish movement say with Oculus and his Balls, I will take a look tonight if you haven't already done so by then.

The previous code snippet was from platoon.lua. However, changing it and adding LOG statements didn't seem to do anything. I'm not sure if that means the code isn't being run (platoon.lua does load in the log after I change it) or if it is being run, but isn't what is controlling the movements.

I'm really glad you guys are doing all this work.  Thanks again!