Power Attack

Where is the temple.zip you are talking about?

Is this it?
http://www.jadri.com/temple.zip


While this is great that we are fixing stuff, we NEED to figure out how these changes you are making are going to make it back into the troika "branch"...

It's easy to send them new txt files for
the config layer, but any DLL changes that are being made through assembly, will need to be re-made into the source...

If it's not too much to ask, could you document exactly what you've done, so we can pass it on to Steve, so he can re-make the changes? It probably doesn't need to be real detailed... (your explanation of the wrong argument being passed into the function for example..), IOW, it's not enough to just say whats fixed in gamespeak..

[EDIT] Just found and downloaded your temple.zip... You have some assembly "Patch" instructions... I don't know enough assembly to understand if this is enough for someone to make the change to the source... Is it?

On that note, Do you think there's any chance we could get a hold of the temple.dll SOURCE, so that we don't have to ask them to re-do what we are already doing?

The way I understand it, the Temple.dll is just a library of methods/functions for the main exe to use... It's not "runnable" by itself, so there's no real piracy concern here IMO...


What do you think?

 

Of course it would have been best if Steve and/or and original Troika programmer responsible for that particular component (ie Huy for spells) had done the fixing. As mentioned, that would greatly reduce the chances of introducing any bugs and we have a dedicated (well sort of) team for beta testing builds.

However, having learnt that certain things do not materialize or may take very long to materialize (ie, our 2nd official patch) due to say Atari QA and other legal matters, I very very much prefer to capitalize on the chance now to provide fixes where possible.
Since the Atari is now aware of the SP2/DX9c thing and more or less expects another patch with QA, I am fairly sure we will be subjected to the entire process again.
I dunno. Maybe I'm paranoid. But I know that people can leave suddenly and without notice. It's a modding board after all and a hobby. People may get occupied with other pursuits in life or other duties. That goes the same for Steve as well. Who knows, he may be assigned to something heavy next after V:tM and won't have much time either.
I guess what I'm trying to say is to make best use of what we have now and try to put out some needed fixes when we can.

Not sure how tough it will be for Steve to merge Moebius's changes with any dll changes for the 3rd official patch. Quite a bit of reconciling may be needed, after all, Steve works on the source code in C and Moebius is working on the compiled result: dll. It is extremely unlikely that Troika will relinquish the source code. That's all they have at this point and I can't really blame them. I really, really hope to be wrong but at this moment I'm afraid I can't see it happening. Perhaps another person asking for it (ie yourself) would add more weight to the argument.

I guess that leaves us with getting Steve to fix things which are too complicated to be done by assembly. Then reapplying the dll fixes at a later date after the 3rd official patch. Hopefully while certain things might have changed, most things would still bear a resemblance to the current code and would be a lot easier to implement (hopefully just an address shift?) as compared to trying to figure them out from scratch right now.

Good documentation of all dll fixes is a must of course for checking and for anyone who would want replicate them in the future. I believe the changes are well documented already in the readme and various text files. Probably might be worthwhile to number them and sort them a little, citing which bug in the main numbered buglist this is fixing, but by and large the documentation is there.

Regarding legality and permission, Steve has seen this thread(s) on dll fixing and I have pointed out the thread to him on the beta testing list. Since he apparently has no gross objection to it, I don't see why we shouldn't continue. Exitium has also agreed to host the dlls. I've asked for careful consideration and consultation with Taluntain on this matter. I've also asked for duggelz's permission as noted before. Since it appears to be alright from everyone so far that I can think of, I feel we've gotten through the 'legal' aspect of it (as you've mentioned, it's not runnable by itself anyway and still needs both exe and data amongst other assorted files like tio to be able function) and can proceed with things.

 

re:

As zhuge noted, there's no real way that Troika will release the DLLs. The DLL is pretty much it for ToEE's code. I think temple.exe does copy protection and... I'm not sure what else. I haven't cracked it open and taken a look. But temple.dll exports one main function, and that seems to handle everything - gameplay engine, input handlers, graphics, etc.

I can try to document my changes a bit better (actually, between the assembly fixes and my notes on the disassembled version of temple.dll, I should be able to reconstruct what the fix does and why).

As for merging in my changes? If I were on the other, end I wouldn't really do it. To really get an idea of how to merge in the changes to the original C/C++ (I'm assuming there's C++, given that there's what appears to be COM usage, but I was never very familiar with COM) source code, you'd have to disassemble the original temple.dll, add in my changes, and figure out what they did. You'd also need to fully disassemble everything - i.e., match up chunks of assembly code with the original C functions. It'd probably be a bit easier if you were in possession of the C source, but... ...not that much. (I'm not sure, I've never tried disassembling any C code I've written.) All in all, not a fun task.

I can try to give semi-coherent descriptions of what the fixes do, but I doubt any of the terms I used (for example, I highly doubt they called the DWORD that stores the class you picked on levelup levelup_class) will map over to the original sources. So we're left with "during creation when you call into the routine that checks if a character can learn a feat, you pass in the class being leveled up as the initial class selected during creation and you've already set the character as level one in that class. This guarentees a minimum BAB of +1. Change it so that you pass in a 0 as the class being leveled up to feat checking routine" - which might help, depending on how familiar Steve is with that chunk of the code (i.e., is he familiar enough with the process to be able to figure out what the heck I'm talking about even though I'm not naming any of the functions, arguments, etc.) Honestly, it's not something I'd like to try to use for bug fixing purposes.

Yeah, I'm sort of dreading patch 3 these days - my hope was that it'd be over quick and that I can merge in my changes without too much pain, and restore my disassembly, and that'd be it - no more major bugs and no need for more patches, and any mods made to temple.dll can stick around permanently. The notes I've written should be enough to identify and fix what needs fixing, in theory... but I'm not looking forward to testing that.

 

Re: re:

Yeah.. me too.. I'm worried that patch 3 may only be the workaround for the DX9, XpSP2 thing... Anything else costs more $$$, and doesn't (in their minds) really help. (Iow, there only looking at Critical defects, and Looting/No Video is the only critical.)

Don't get me wrong, I appreciate any work steve or atari does, but let's be honest. This game has been pretty much abandoned.

Yep, if temple.dll has all that in it, then thats too bad.. Perhaps in another year or two Atari will finally admit this game is abandoned, and declare it abandonware....

Personally, I don't see how us trying to fix things is a problem... Can't the NDA's be extended, or something silly like that?

Any fixes additions we make only make the game better.. Better game = More Sales.


I have to go replace the Temple.dll, but the 3.0.4 BETA is pretty much ready.

 

Not trying to incite anything but frankly I didn't find the number of dll fixes for the 2nd official patch particularly spectacular. All in all we had about 11 dll related fixes for the 2nd official patch.
Sure there were quite a few dialogue and data fixes as well but many of those were suggested by Co8 anyway and had those not made the 2nd official patch it would have been in our mod pack.

Right now if you look at the bugzilla list, you'll see a lot of assigned valid bugs, status of which is still unclear. Given the amount of dll fixes done for the 2nd official patch, I don't think it is particularly likely that Steve will get them all fixed in reasonable time (before people get bored of waiting and move on to other things, which many already have at this point).
Our goals should be to have a bug free, 3.5e compliant game (which are also essentially Steve's main goals which he cited in the IRC chat) and perhaps later some optional mods, be it through Steve or a 3rd party like us. Therefore, it is logical that we support the best means to achieve these goals. At least that's what I feel.

I guess what I'm trying to say here is we're looking at a good number of dll fixes. The first time in a long year of waiting and the best thing that's happened so far since Co8 first introduced data file fixes. With approval (tacit or otherwise) from all concerned parties so far, let's just move ahead.

As for reconciling the differences on a 3rd official patch, we'll figure out something later with Steve. He's always wanted us to show a little more initiative (even if the dll might not actually be what he had in mind) and I really do believe from his words that he would've like to see something done by the community.
The point is, work's been done, progress's been made and hopefully that'll keep enough people interested to maintain a core group working on it. With dll progress, chances of attracting more people snowball (most people I've come across want to mod a bug free and stable game) and I'm keeping my fingers crossed on that.