You are currently viewing our site as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today!

If you have any problems with the registration process or your account login, please contact contact us.

GeneralThe general chatting goes on in here.
That means talk about the LBA games and it's world.

- draguluin: Unassigned slots adjacent to each other are treated as one single huge unassigned slot. So you can freely move around them.

It depends on what precisely you mean by "are treated as". Firstly, different unassigned slots are separated visually (the same way as standard scenes are, when level of detail in game options is set to minimum). Crossing this visual border when playing neccessitates bringing up your inventory, otherwise you'll drown. That means the game notices crossing the visual border and runs some update routines, i.e. the separation of different unassigned slots is at least a small bit beyond purely visual.

Quote:

Originally Posted by Battler

Nope, as there are no zones going to the diagonally adjacent scene. You'll see it does pass through the scene in between too, just so quickly that you don't even see that.

That occured to me, but at least empirically there is a counter-argument. Have you seen enough of the game code to prove it is fundamentally impossible? The counter-argument follows:
When you leave a scene, the screen (old scene) fades to black (this takes maybe 250 ms for me) and then the new scene is depicted immediately. During the fadeout, Twinsen's animation doesn't progress. That is, Twinsen's animation after the fadeout picks up from where it was before the fadeout. I suppose this is simply a "new scene loading" routine that takes some time and cannot be skipped. Thus, since I have not observed time lapse corresponding to two scenes loading in my diagonal jump, I am led to believe that only the diagonally adjacent scene was ever loaded. I should note that when jumping very close to diagonal, so that I do pass through two scenes, the two fadeouts and scene loadings are clearly visible, even if I spend the tiniest amount of time in the fully adjacent middle scene.

-draugluin: I know what I see in SCENE.HQR. And the game gets all the info you're talking about from there. And I see no change scene zones pointing to diagonally adjacent scenes.

If you're right, and I believe so, you can only effectively exit a scene adjacently. A zone is merely an object with a specific assignment, and in this case the determination of which scene to load.

You would imagine walking out of a scene would load the scene that is adjacent to whatever point you use as exit, but this is not the case. If one weird programmer would have placed an exit-zone incorrectly, you might as well be entering a scene from the other side of the island. The scene that you will end up in has nothing to do with being adjacent or not, it's just a reference of another scene pointed out by the zone you are in. Just like teleporting. Or maybe in fact teleporting.

Battler, could you elaborate more on what exactly a zone is/does, if you would? This is something engine related that I find interesting with a capital.

I thought there is maybe a default mechanism for passing between the scenes, that gets overriden by the zone settings in most normal places, or better, that is actually controlled by the zone mechanism (I'll explain this below).

The first thing that makes me think about it is that you can pass between the unsaveable areas. Surely no one declared any zones in these, so the possible passage is a result of a default existing mechanism. More precisely there is probably just one unsaveable scene being loaded over and over from different sides, but while moving in the unsaveable areas you can see Twinsen's position on the holomap changing correctly, so there must be some kind of global coordinates that are remembered. And these global coordinates would probably be used in the scene transitions. Any of them - not just between unsaveable scenes! When zones are present, it is checked whether a zone is passable and if it is, then it is allowed to pass based on the global coordinate mechanism. After all, when passing back and forth between scenes you see that in the new scene you appear at a place corresponding to where you left the old scene, so coordinates are used.

Of course this is just an idea, but Battler didn't really explain much...

I haven't been to the underwater worlds yet, if I could. But I really don't think the zones are default mechanics, or that they even operate there.

These places are outside of normal gameplay for starters, and you should not take the normal rules of the playable world for granted in these areas. As Battler explained already, they are probably just a collective area, not even working like normal scenes anyway.

You notice your location is monitored correctly by the worldmap, but you should not conclude this means the zones are in place in these areas: it means the separate coordinate system that determines where you are on a scene is still being updated, not necessarily changing scenes like you think.

I expect the game to operate on a combination of two coordinate systems together. One says on what scene you are, and another where exactly on that scene. These two are not related to one another, meaning one continues if the other stops working.

In the normal world, you move on a scene basis AND on a coordinate basis. So at any point, the game knows that you're on position X,Y,Z,S. The X and Z axis say where horizontally in the game world (the axis extend through the scenes), the Y determines your height, and the S is the ID of the particular Scene that this XYZ coordinate belongs to. If you're moving outside the normal scenes, at places where you can't save or even get to normally, only the XYZ change and the S is simply nonexistent. The worldmap recognizes the XYZ, who still operate, but the worldmap never looks at the S anyway.

So the game operates on scenes. If you move into another scene, the engine must move the object of the avatar out of the current scene and into the next scene. It can't just move it along, it must actually teleport it as the next scene is loaded separately as you enter it. So at any point in your movement, you are updating the XYZ like in real life longitude, lattitude and height, but also another factor. Not a dimension but more like a "section" of the world. As long as the game knows the XYZ, it can send you to the correct next scene. This is probably manually done by preset zones. So as soon as this "zone" is entered, the zone tells the game "move this object to that scene", rather than the game understanding the scenes are really "adjacent". The game doesn't understand what adjacent means on a scene basis, they are simply different objects with different IDs.

Disclaimer: this is my perception and interpretation.
Disclaimer2: I would have designed a better way of using scenes myself, like putting them in their own X,Y coordinate system, so the game would know which are adjacent. I don't know if LBA2 was too.

Firstly, why haven't you been underwater? Setting lowest level of detail, jumping through a scene border, bringing up inventory then closing it doesn't work for you?

As for what you think about the game mechanics... I'm not even sure you're talking to me, but who else is here. You're refuting something I didn't tell in my previous post, and then you reiterate much of what I did... But anyway let's forget this, it seems mostly pointless without someone actually having seen the game's code...

I think the testable hypotheses are clear here:

- make the seemingy diagonal jump

- there are programs to check and write things in memory that you can use e.g. to cheat in games, like you have 173 health, you look for where a value of 173 is stored, if there are more such locations, ingame loose some health to 160, then pickup the location where the value changed to 160...you have the place where health is stored in memory and you can write your own value there... at least back in time it worked like this. So maybe you could find a location where scene IDs are stored for LBA2, and when you get this you can check how scene IDs are changing while playing and you could look at whether the seemingly diagonal jump is real, or scene ID is at some point set to the ID of a fully adjacent scene for a while...

- try to make the diagonal jump from DoS to Citadel... probably pointless to try unless the possibility is confirmed by previous step. Since you can't stand near the corner, trying blindly to find the precise direction standing miles away from the corner would be extremely tedious...

Sorry for not mentioning why I haven't been there, I thought my post was getting long. I simply haven't been to the underwater world because I haven't. I would have tried it out when I start playing, but I'm doing other projects at the moment.

Regardless of criticism or sceptics, I really want you to be able to solve this, believe me. I would certainly appreciate it if you could tick off another entry in the challenge list

I'll definitely try this tracking of scene IDs and other variables in memory while playing, but I'll take my time too - other things to do & plus it's been ages snce I used the required programs, don't even recall their names now.

First off, which two diagonally adjacent scenes exactly have been passed and on which island?

Second off, a zone is simply a cubic area in a scene that does something such as drop an item (based on flags) when ACTION is pressed or take you to another scene, which basically IS a teleport: the parameters of the change scene zone are the ID of the target scene, the X-Y-Z positions you should be placed on in it, and whether the zone is enabled or not (as zones can be programmatically enabled/disabled by the life scripts of various actors (Twinsen included)). The target X-Y-Z positions and I think even the target scene ID can be programmatically modified too.

And yes, each outside scene also knows exactly where on the island it's located - after all that's how LBA 2 can find the right area in the ILE file to place it on. But where you can go, is decided by the zones.
To prove that, I once made copies of DESERT.* named as CITADEL.* and started a new game. Surely enough, I ended up on a false Desert Island upon exiting the house. And the only areas I could progress into, are those the zones pointed to. Where there was no zone, the game behaved as if there was a wall, regardless of whether the area bothered on another valid area from the ILE or an empty water area.

As for the observed diagonal crossing of scenes - the possibilities are two. Either the corner has a zone pointing to the diagonally adjacent scene, or the game, when following the change scene zone, verifies if you're ending up in another change scene zone and if yes, it simply follows that zone without loading the ILE data, voices, etc. of the scene in the middle.

Now, if draguluin tells me where exactly he was able to cross scenes diagonally, I'm going to verify that area with my LBA Scene Manager and see what's going on.

But the following facts are proven:
1. The game only lets you cross to areas the scene has changing scene zones pointing to.
2. Any aspect of a given change scene zone can be programatically manipulated at run-time by the life scripts of any actor (Twinsen included) (this is how LBA 2 changes where in the adjacent area you will spawn).
3. Each ouside scene knows exactly what ILE file (and TEXT.HQR bank and Holomap entry) belongs to it (inside scenes know that too, obviously) and where in the ILE is the area located.
4. However, the scene does not know what scene is each area in the ILE allocated to.*

* This might be false if the game loads all outside scenes, stores their ILE coordinates in memory then simply looks those up. But that is yet to verify.

Further proof for the change scene zones being required is the fact the LBA 2 scene format is directly descended from the LBA 1 scene format. In fact, the entire LBA 2 scene system is directly descended from the LBA 1 one, which is why the division of the game in scenes is there in the first place.
Actually, the entire LBA 2 engine is a direct evolution of the LBA 1 engine, to the point of the LBA 2 executable files still referencing old LBA 1 configuration fields such as Version_US, that no longer exist in LBA 2.

Edit: Another thing I forgot to say. In the LBA 2 saved games, there is actually a copy of the scene (or so it appears to me) the saved game points to, as it was at the time it was saved. That's why changing a scene with LBA Scene Manager then reloading the saved game will show no change in the scene until you exit the scene and go back in. That's how LBA 2 knows the exact state of everything in the scene when loading a saved game.

Thanks, seems I had most of it just right in my purely theoretical analysis.

Quote:

Originally Posted by Battler

...
Edit: Another thing I forgot to say. In the LBA 2 saved games, there is actually a copy of the scene (or so it appears to me) the saved game points to, as it was at the time it was saved. That's why changing a scene with LBA Scene Manager then reloading the saved game will show no change in the scene until you exit the scene and go back in. That's how LBA 2 knows the exact state of everything in the scene when loading a saved game.

This sounds like serializing the scene on save, as software cannot store objects on hard disk (only values)
It probably comes down to copying all substates (data values) of the scene's content and storing then in some file or database, so they can be used to rebuild the original object upon load. I guess an image of the scene is also included in this, as altering the scene of a savegame by editor doesn't modify the image that is shown in the load menu.