bikerdude on 30/11/2008 at 15:09

---

If you look at the original thread, there was discussion about patching/h***ing the t2.exe

maybe as an Idea, people can send in their different version of the T2.exe, he can then modify them, add a version number and add them to the archive..??

biker

bikerdude on 30/11/2008 at 15:31

---

that would be a false positive, just add it to the list of exempt programs etc.

Im running kaspersky 2009 and it had no problem with the zip file - what AV proggy you using..?

b.

Dainem on 30/11/2008 at 17:16

---

Some more Screens with three players:

It wasn´t me:
(http://img527.imageshack.us/img527/848/itwasntmeru1.jpg)

Partytime:
(http://s10b.directupload.net/file/d/1629/eenajs6z_jpg.htm)

Partytime Posers:
(http://s10.directupload.net/file/d/1629/khhd8z4d_jpg.htm)

Jump:
(http://s11b.directupload.net/file/d/1629/kwbpw4vi_jpg.htm)

Where is the target?
(http://s11b.directupload.net/file/d/1629/2rqjiu2k_jpg.htm)


More to come. We also made a nice little video which will be uploaded soon.


Dainem

CMD on 30/11/2008 at 17:55

---

Name: CMD
Skype : cmdfighter
Email: [email]XCMDX@web.de[/email]
Modem: ---------
Location: Germany
server: ?????

*be happy :) :D *
maybe we could make a list about our skypes ,commections and else?

Tos on 30/11/2008 at 21:25

---

Beleg, is the "total loot" text being displayed as white for you in game as well? Both it and the chat text should actually be red.

Also, I just noticed that "total loot" was being displayed even if you're the host of the game, despite what I said in the readme -- whoops. That will be fixed in the next update.



I'm really not sure why the widescreen patch is only working for some people. I just tested again with the latest version of the widescreen patch (I think I had an older one before), and was again able to apply it without any problems at all onto the multiplayer .exe. Are you both using the latest version?



I haven't had much luck in fixing that problem so far. Arrows can't be picked up because T2 MP sets their networking category (a property you can view in DromEd) to local only, which means that they only exist on your end and no information about them is sent to other players. When other players fire a projectile, they send a packet to you that creates a local copy of the arrow on your end, which is how you're able to see other players firing them. Obviously, if one player were to pick up a local object it would still appear to exist in the world for other players, so the game does not allow them to be picked up (I could override that behavior, but it's not a good idea).

If arrows aren't local only, all sorts of strange problems begin happening. They will occasionally disappear after being fired, launch in a completely different direction than they should have, or just never even appear on your bow. They can be picked up, though. System Shock 2 (which uses largely identical network code) has local only projectiles as well, but since they can't be picked up or stuck into wood it's not an issue there.

There's some possibility that it could be fixed for broadheads and rope arrows if the CollisionStick script could be modified, but I don't know whether that's feasible or not. The other types of arrows would require a different approach, though.



Unfortunately, I don't think this will be possible. T2 MP makes use of over 400 pointers to functions and variables with offsets hardcoded for this .exe only. In order to do what you're suggesting, I'd need to add offsets for each different .exe, then compile and distribute a different version of the .dll for each one. I'd then need to automatically detect which .exe the player is using at startup and load the appropriate .dll.

This would take an enormous amount of time to do for what I have already -- just going back and adding the new offsets would be tedious enough -- but I'd also need to do some work to find where each one is in the new .exes. If I made a mistake and put in the wrong address for something, I could end up with a bug that only affected a specific .exe, which could quickly turn into a debugging nightmare. It'd also add greatly to the amount of work I'd have to do to add new pointers.

It's just far too much work for too little return, especially if the other patches can be applied on top of this. If you really want to make the changes to the .exe manually (it must be the same size as the one in the zip, or the game will crash), the following should do it:

At 0x120, change 50 E8 1E to DE DA 1F. (this changes the entry point)

At 0x1FDADE, change the entire block all the way up to 0x1FDAEF to B8 F8 F5 67 00 50 FF 15 B8 00 60 00 E9 61 0D FF FF 90. (this is the new code at the modified entry point -- it calls LoadLibrary to load ThiefMP.dll, then jumps back to the original EP)

At 0x27F5F8, write in ThiefMP.dll as an ASCII string (this is passed to the LoadLibrary call).

I haven't tried doing it that way on a clean .exe myself, but that should work. If it doesn't for anyone, let me know.



Yes, it's a false positive. I suspect it's being detected as a virus because the PE header of the .exe was changed to redirect the entry point outside of the code section (which probably explains the "PE_Patch" in that report). This was done so that I could add the new code listed above to load the .dll at startup, but for obvious reasons that may be typical behavior of some viruses.



That would be a good idea.