TTLG|Jukebox|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 25 of 25

Thread: IBT file format.

  1. #1
    Member
    Registered: Nov 2002
    Location: Germany

    IBT file format.

    A starting point for IBT file info can be found here:
    http://www.ttlg.com/forums/showthrea...t=86819&page=2

    Hopefully this thread persists.

  2. #2
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Briareos H
    A priori, the link "or here" that I mentioned in a previous post is enough to make a browser/extractor. But personally, I'm not good enough at programming to do such a thing.

    I also have a program that shows the contents of an ibt file but doesn't extract them. Maybe I could ask its developer for help...
    If it can display the information correctly, it shouldn't be to hard to extract it. To display the info you already have to "extract" it in some form.

    And for the thread suppression... well it's impressive... On the whole net, I couldn't find a single working link for what I was searching for !
    All the threads had been deleted, or even the forum sites or program mirrors were down...
    Yeah. It's strange, because these were older thread but once you brought this in the open, they were gone shortly afterwards. Quite a coincidence. Do I see a conspiracy here?

  3. #3
    Member
    Registered: Jun 2002
    Location: melon labneh
    lol...
    Anyway... the Unreal forum... it's a good idea to move in.
    At least a good temporary idea, because I wouldn't like to have an endless list of threads like in General Discussion.

    So.

    Well I posted here, on these boards to see if anyone had the file in question. But I'm also going to ask someone for info on the IBT files. Stay tuned.

  4. #4
    Cool.

    Well the only reason I'm posting in this thread is to get my name on it so I'll remember to keep up to date with it.

    The way I like to keep up to date with threads I'm involved in is to do a search for my user name.

  5. #5
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Briareos H
    lol...
    Anyway... the Unreal forum... it's a good idea to move in.
    At least a good temporary idea, because I wouldn't like to have an endless list of threads like in General Discussion.
    I asked the mods about it, and they said we shuold use this forum. Maybe the forum could be renamed to something more suitable.

  6. #6
    Member
    Registered: Nov 2002
    Location: New Zealand
    Why? I reckon "Unreal Creation and Design" is a pretty accurate description of this forum is used for and intended to be used for.

  7. #7
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by mopgoblin
    Why? I reckon "Unreal Creation and Design" is a pretty accurate description of this forum is used for and intended to be used for.
    I don't really mind as long as the people, working on T3, find this forum and start posting here.

  8. #8
    Member
    Registered: Feb 2001
    Hmm, interesting, but be careful what you post. I'd have to take a dim view of any linking to disassembled T3 code etc.

    Carry on

  9. #9
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Ulukai
    Hmm, interesting, but be careful what you post. I'd have to take a dim view of any linking to disassembled T3 code etc.

    Carry on
    I don't intend to disassmeble T3. Not yet. Nah, really. Why would I do this? For now the most important thing is to hack the file format, and this can be done by simply looking at it, and modifying values and see how the game reacts. This is not even forbidden by any law that I know of.
    And if I really would have need to disassemble code to understand what's going on, then there is still no need to post it here. There are better forums for such things.

  10. #10
    Member
    Registered: Jun 2002
    Location: melon labneh
    Plus, I don't see how disassembling it would help us to better understand the IO details of a c programmed engine...

  11. #11
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Briareos H
    Plus, I don't see how disassembling it would help us to better understand the IO details of a c programmed engine...
    Why not? Sure it CAN help, but it is a lot of work. If you disassemble it and understand the code, you can learn all kind of details. It can be helpfull if you have some stuff in the files where you can't determine what they are there for. In this case you can look at the code and find out how this is interpreted.

  12. #12
    Member
    Registered: Jun 2002
    Location: melon labneh
    I do not know much about disassembling and so on, but I think a more appropriate term for what you want would be "decompiling". And I would tend to think that efficient and working decompilers are nearly impossible to do as the compilation and linking process is too intricated with the nature of the compiler, the station you are working on, the versions of the files you are using and so on...
    You will never get the code as it was coded initially.
    Moreover, in a code, the most useful data (and for some dreadfully complex functions the ONLY useful data) are the comments left by the programmer. Without that, I highly doubt someone will ever understand TDS engine...

  13. #13
    Sparhawk's right - no need to disassemble the code. Just work out how the level files were put together, then replicate that via a converter for an existing level editor.

    I'm half certain that this process of "reverse engineering" would be illegal some how, on a really technical level, but on a practical level, I doubt anyone would care, or be bothered to do anything about it.

    We just want to make our own levels for free.

  14. #14
    Previously Important
    Registered: Nov 1999
    Location: Caer Weasel, Uelekevu
    Reverse Engineering software is a very delicate area of copyright law right now. There is a loophole (if you can call it that) in the DMCA -- like it or not, the DMCA is definitely the way things are when you deal with American stuff -- in that reverse engineering is permissible when you're attempting to address compatibility issues. But that's it, and I'm not even sure that "permissible" is an accurate way to say it.

    Reverse engineers must reconstitute code from hints provided by reading data in files and by watching the behavior of the playback applications. These activities must take place in a "clean room" to provide a record of the reconstruction of the code in the event of a legal challenge. In effect, reverse engineers must be able to show that they re-created the target software without knowledge of the underlying source code.

    Decompiling, by contrast, is explicity prohibited under copyright... and it probably says so in very plain language in Thief 3's EULA.

    The idiocy of RealMedia vs Apple going on right now may well serve as a strong precedent, but it looks very possible that RealMedia will take one in the face over it.

  15. #15
    Member
    Registered: Jun 2002
    Location: melon labneh
    Sorry for the slow response... So. Well I didn't manage to get further explanation on the file format, think some of us will have to study it on their own.
    Anyways, regarding Reverse Engineering, I agree with Gingerbread Man. The longer we do without deXXing the code, the better.

  16. #16
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Gingerbread Man
    Reverse Engineering software is a very delicate area of copyright law right now. There is a loophole (if you can call it that) in the DMCA -- like it or not, the DMCA is definitely the way things are when you deal with American stuff -- in that reverse engineering is permissible when you're attempting to address compatibility issues. But that's it, and I'm not even sure that "permissible" is an accurate way to say it.
    There are certain cases where you are allowed to do it. I don't think that it applies here, but that's no problem as we don't need to reverse engineer the CODE. reverse engineering the data structures for the map files is no problem and it is not forbidden as long as we don't verbatim copy data from the files. If it were forbidden to also reverse engineer ata files then a lot of projects like WINE or Open Office would also be in big trouble. Or do you really think that Microsoft would allow OpenOffice developers to write compatible code if they could do something about it? Word is their most powerfull horse where the money is.

    Reverse engineers must reconstitute code from hints provided by reading data in files and by watching the behavior of the playback applications. These activities must take place in a "clean room" to provide a record of the reconstruction of the code in the event of a legal challenge. In effect, reverse engineers must be able to show that they re-created the target software without knowledge of the underlying source code.
    This would be true if we would rewrite a Thief Engine, which we don't. Reverse engineering is allowed in certain circumstances, and in these circumstances you could reverse engineer the code without a clean room. The clean room is needed if you write an application which is so similar that the legal owner could claim you would have stolen the code.

    Decompiling, by contrast, is explicity prohibited under copyright... and it probably says so in very plain language in Thief 3's EULA.
    The EULA has no legal binding for me. There are already rulings on that here. But again. We don't need to reverse engineer and we certainly don't decompile. And to Briareos H: I didn't mean decompile because I exactly know the difference. And quite on the contrary if you have no sourcecode you still could gain valuable information from the code alone. The comments would be helpfull of course, but they are not strictly needed. In the 80is I reverse engineered the entire AMIGA DOS library because the documentation in all the books was wrong and we needed the correct workings to code some stuff. So the source is not needed but it is nice if you have it.

  17. #17
    Member
    Registered: Jan 2004
    Location: Back Home
    I don't suppose you'd like to try and code a lightgem in Doom 3 when the SDK arrives?

    Seriously, I feel bad saying this, but the chances are, if enough people pull together and we get it working, a Doom 3 Thief mod will look better and probably play better due to more customisation and moddability than Deadly Shadows. Also the potential for multiplayer.....

    It wouldn't require any nasty messing around, nor any legal issues.

  18. #18
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Fingernail
    I don't suppose you'd like to try and code a lightgem in Doom 3 when the SDK arrives?
    Why not? I don't have much experience with modding, it would be worth a try.

    Seriously, I feel bad saying this, but the chances are, if enough people pull together and we get it working, a Doom 3 Thief mod will look better and probably play better due to more customisation and moddability than Deadly Shadows. Also the potential for multiplayer.....

    It wouldn't require any nasty messing around, nor any legal issues.
    It would require a great deal of messing. After all we would have not only to implement the light gem, but also the AI which is much more work. And I dont know about sound propagation in D3, though I expect it to be good. And of course there are all these little details like creating an entire thief world form scratch. We couldn't use the original stuff and I doubt that eidos would like it if we did.

  19. #19
    Member
    Registered: Jan 2004
    Location: Back Home
    Yes, AI will be trickier, but doable. Doom3s AI already has two states of alertness, we need an extra one, maybe two, and then some different behaviour.

    Register & read up at doomthief.conforums3.com and then decide if you want to help.

  20. #20
    Member
    Registered: Nov 2002
    Location: Germany
    Quote Originally Posted by Fingernail
    Yes, AI will be trickier, but doable. Doom3s AI already has two states of alertness, we need an extra one, maybe two, and then some different behaviour.

    Register & read up at doomthief.conforums3.com and then decide if you want to help.
    I already registered and answered one post in the General Board, but I can't post in the devs board.

  21. #21
    Member
    Registered: Jun 2002
    Location: melon labneh
    Plus, as soon as this D3 mod will become something potentially good (see the example of the system shock mod [System Shock Rebooted] for D3 in the SS forums), Eidos will demand you to stop or at least not to use any copyrighted material ("The City" name, maybe "Garrett", any "Thief" reference). It will end up being something like Nightblade...
    And Nightblade is already under heavy development.

    Finally, I don't know much about D3 "moddability", but wouldn't it be better to wait for the HL2 SDK ? I think that Source is a more versatile and more "helping" engine to modders. And at least it will have decent AI shipped with the game .

    Just my two euro cents, eh...

    EDIT : Ok I hadn't read your post in the Thief global discussion forum... so it will be legal. Sorry !

  22. #22
    Member
    Registered: Jan 2004
    Location: Back Home
    No. We are already stripping out the copyright content. You can't copy a reference to 'the city' anyway - a city is a city, and whichever one it is, I could call London, 'the city' and not get sued.

    Anyway, on your other point, AI aside, Half-Life 2 is not the right engine for this. Reason: lighting. Only Doom 3 has similar style of lighting to Thief 3. Half Life 2 is closer to Thief 2's lighting.

    On your other point, Doom 3 is exponentially moddable, due to huge support from ID and many tools soon to be released along with an SDK. Think of their past games and how many mods/other games have been spawned using QII/3.

    ID don't want to lose out to Half Life too much.

    Also, maybe I didn't stress this enough at first, let me reiterate the point of this:

    Problem:
    People want to make fan missions for Thief 3. Sadly there may never be an editor released.

    Solution:
    We create a suitable environment in Doom 3 that people can make fan missions, designed to be fairly close to the feel of Thief 3.

  23. #23
    Well, that would require re-writing the guard AI - making it possible for AI to see objects less depending on how dark they are, fleeing or getting help, searching, etc. none of which is in Doom 3 by default.

    We'd pretty much have to re-create everything that makes Thief, Thief.

    But hey, it might actually be easier than cracking open Thief 3, who knows? Working with something the way it was meant to be worked with, would have to be easier than beating something into shape.
    At least then we'd know exactly how much work would be involved.

    We should look into it.

  24. #24
    Member
    Registered: Aug 2004
    Where should we interested players keep watching to track the progress of a Doom 3 Thief mod?

  25. #25
    Member
    Registered: Jan 2004
    Location: Back Home
    You should go & register at doomthief.conforums3.com

    But soon it will be www.modetwo.net/darkmod

    And a website will be hosted at TUG.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •