18-07-15, 17:11 | #11 | |
Member
Joined: Aug 2010
Posts: 1,810
|
Quote:
The problem is, we have several people in community with great knowledge of TR file formats, but all this knowledge is kept in the head. Like, I know that original TRosettaStone lacks some info here, and also I know that Popov's revision wrongfully described this or that parameter, but it's not mentioned anywhere (except some forum posts), so if a newbie wants to help with an engine, he has to come through all the same trials and errors as we once came. "It shouldn't happen like that." Also, I will integrate parts of VT loader code into "Entire TR* file format" sections, cause this info was drastically updated as well. Ooops... Sorry for double post, I wanted to edit my prev message, but pushed post button on autopilot! |
|
18-07-15, 17:14 | #12 | |
Moderator
Joined: Jul 2003
Posts: 33,359
|
Quote:
Chances are you already know this, but I thought I'd mention it anyway, in case you have never seen them in the editor. In the TRLE these currents are called sinks. They are little round sprite-looking thingies that you place and trigger. Strength is set in the OCB of the sink and when Lara is over the triggerzone, she is pulled towards the sink. |
|
18-07-15, 17:19 | #13 |
Member
Joined: Aug 2010
Posts: 1,810
|
Titak, actually it's valid, underwater current usually describes a trigger function which causes Lara to move to certain sink. So, underwater current is an operation, and sink is a trigger.
Cameras and sinks just share the same internal structure, but since on design-time they are specified differently in TRLE, it's no problem. Problem comes when you want to tell camera from sink in already compiled level, as difference between camera and sink is lost when level is exported. Edit: for another update, I have integrated information about TR5 room structure. Indeed, as mentioned by many developers, TR5 room format is one of a bastard, and I've especially mentioned this in the document! Last edited by Lwmte; 19-07-15 at 00:39. |
19-07-15, 12:04 | #14 |
Member
Joined: Sep 2007
Posts: 1,684
|
Tr4 light type 4= Fog bulb.
|
19-07-15, 12:53 | #15 |
Golden
Joined: Apr 2006
Posts: 16,751
|
I just pushed a few stylistic changes. In particular, different structures are now always described as such. Previously, half were described as different structures, half as the same with optional fields. I always found this overly confusing. There were also a few minor issues that I fixed.
I have no idea how to generate the HTML file, though, so someone else would have to do that. Why is that even in the repository? Generated files don't go in repositories except in very special circumstances. |
19-07-15, 13:50 | #16 | ||
Member
Joined: Aug 2010
Posts: 1,810
|
Thanks!
I also forgot which fields of light structure specifies fog bulb density and size. Can you tell it as well? Is it also applicable to TR5? I heard that TR5 changed a way to interpret fog bulb objects, i. e. they aren't defined by lights anymore but rather some kind of "dummy" objects. Quote:
I think it's for good to have separate structs for each change they made in engine. Whole doc is going to be revised one more time, after initial edit is done. Now feel free to add any information which you may think is important! Quote:
On Windows, I just downloaded Python and asciidoc from MSYS2 shell via pacman (package manager), then I needed to find and run some unusual Python script to install Pygmentize (code highlighter used by asciidoc). And then I used asciidoc command from MSYS2 shell to compile HTML. Last edited by Lwmte; 19-07-15 at 13:53. |
||
19-07-15, 14:48 | #17 |
Golden
Joined: Apr 2006
Posts: 16,751
|
One thing I'm not sure about: In object texture attributes, it says index 2 means "alpha is equal to intensity", with "intensity calculated as maximum of individual color values". I've always instead interpreted that as additive blend mode (no alpha at all). Implementing it like that looks correct and is a lot cheaper than anything else, so that's my guess as to what this really means.
I'm currently not sure what OpenTomb does in these circumstances, but I think it uses additive blend mode as well. |
19-07-15, 15:03 | #18 | |
Member
Joined: Aug 2010
Posts: 1,810
|
Quote:
I've added a BIG RED TITLE before FloorData section to indicate that no info is (yet) edited after the room geometry section. I hope I can fix up FloorData section today. Back on topic, in OpenTomb we have special blending mode selector, which is forward-compatible with FLEP blending modes patch - i. e., not only additive blending is possible, but also substraction, inversion and screen modes. You can read this thread, where these blending modes (as well as all original TR blending modes) were described. Last edited by Lwmte; 19-07-15 at 15:05. |
|
19-07-15, 17:37 | #19 |
Member
Joined: Jul 2015
Posts: 145
|
I have set up a public clone of the repository that automatically updates every 15 minutes and thus shows the latest version of TRosettaStone 3, so there's no need to clone the repo for yourself: http://opentomb.earvillage.net/OpenT...ettastone.html
//EDIT: The update mechanism only triggers if you visit http://opentomb.earvillage.net/ before |
19-07-15, 18:21 | #20 |
Member
Joined: Aug 2010
Posts: 1,810
|
Super handy, thank you!
After the first edit and on review, I will also enrich original document with pictures and some schematics. I already have some things in mind! |
Thread Tools | |
|
|