Jump to content


New Arrival
  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Fine

About Alby87

  • Rank
    Leaden Juggernaut

Previous Fields

  • Favorite pizza topping
    Mushrooms and fried eggplant
  • Why do you want to join DarkMatters?
    Talk about Lobby Server
  • Real Name
  • Country
  1. Was thinking... but injecting the IP in memory? I noticed you made a unofficial patch for Sacred, so maybe you know if I'm totally wrong. When in LAN mode, Sacred search in LAN via broadcast. If in the LAN lobby window we inject in memory an Internet IP, may it work? If so, it would be easy to write a side software that des the matchmaking, and then injects the IP on the game. Is this a good idea?
  2. Well, but I was thinking: we have at least the executable for the server, we could try to decompile it to understand the basic packet structure, but it's a too big task for just one person. Pvpgn is a project like we want for Sacred made for Blizzard games. They are lucky because their servers are still online. We could ask them for help? You asked documentation to a Tincat developer or an Ascaron developer? I think that if we could get the Tincat API interface, we still need to understand the protocol, that's inside Gameserver.exe and Sacred.exe. I was thinking if FX interactive (Italian and Spanish distributor) could help us.
  3. Thank you for the warm welcome, but I think I hit more than a roadblock. What would be really useful is someone having a development file that should be called tincat2.h (the header of the tincat library) or someone really good at reading ASM code... It's not that easy to reverse engineer
  4. Was reading about this, and toyed a little with the idea. I've a small TCP server to sniff the request from the gameserver... well, it's not garbage but there some binary data, and without a log of some real action between client and server, this is not the real way. Tried to disassemble Tincat2.dll and well, it's not easy. I'm not so good to understand assembly code on the fly, but seems really difficulty. Then I had an idea: why not remove completely Tincat? Writing a new Tincat2.dll file would be easy enough if there were some documentation of the APIs, but I understand that also having the interfaces and structs is out of question, isn't? Having that, and writing a new tincat client dll, would remove the legal problem of emulating a server: we are writing a new one from scratch
  • Create New...