I've Been Learning C!

[Zink]

Originally Posted by MrQuetch

About data blocks, are those located after the number of parts, the offsets, or something else? I'm not sure about where this would be located - probably sounds like it'd be in the header with everything else.

By 'data blocks' I mean the actual information for vertices, polygons, etc. The data the offsets point to.
Nice to hear you are figuring it out.

Originally Posted by MrQuetch

Glad to hear I've been using the Package Editor in a way that it's meant to be used. Interesting you mention the hexing HQR part, I actually created a thread for Alone in the Dark hexing, and managed to find many entries for the existing models in the game - but since it was all compressed data, when I would hex, it would generally be a group of elements that shifted in some way. Most of the time it would just crash. I posted a couple screenshots there actually.

I might have seen that thread, but I'm not really interested in AITD, so I didn't pay attention .

Originally Posted by MrQuetch

The fact that you managed to make the files re-compress back into the HQR program that you made is rather amazing. Once again, thank you for the Package Editor.

It doesn't 'recompress' to be honest. I didn't have a compression procedure at the time of writing Package Editor. It simply puts the uncompressed data, sets the compression flag to zero, puts the remaining contents after that and updates offsets in the header. Nothing complicated

[MrQuetch]

Originally Posted by Zink

By 'data blocks' I mean the actual information for vertices, polygons, etc. The data the offsets point to.
Nice to hear you are figuring it out.


I might have seen that thread, but I'm not really interested in AITD, so I didn't pay attention .


It doesn't 'recompress' to be honest. I didn't have a compression procedure at the time of writing Package Editor. It simply puts the uncompressed data, sets the compression flag to zero, puts the remaining contents after that and updates offsets in the header. Nothing complicated

So, I understand the numbers, and the data offsets, but there is a number after that for every part. Some bytes have it while others do not - glad I'm understanding more, but some of it still seems foreign - even with the time and effort I've put it.

Did you see the image with Twinsen? That byte came after the number of normals, and their data offset. I'm still wondering what this number is exactly. It just looks like another container for data.

Ahh... Well, that's probably what I would've done then as far as the Package Editor is concerned. Computer science is weird sometimes - I thought getting some things to work on my programs would be far more difficult than anticipated / expected, sometimes it takes a single array or global variable to get something to work properly. I've come to like 'for' loops a lot, and they've helped immensely!

I'd like to continue to decipher more of the LBA2 models, but I'm wondering if I've reached the 'limit' until more information from Fred gets out about the models... I hope that's not the case.

[Zink]

Originally Posted by MrQuetch

So, I understand the numbers, and the data offsets, but there is a number after that for every part. Some bytes have it while others do not - glad I'm understanding more, but some of it still seems foreign - even with the time and effort I've put it.

Did you see the image with Twinsen? That byte came after the number of normals, and their data offset. I'm still wondering what this number is exactly. It just looks like another container for data.

I don't remember where I've seen it exactly, but I can clearly reckon that the models had something called "shade information", and that its format was unknown. And looking at the Twinsen's pictures you've posted that was first that came into my mind.
I think the number you're changing is a number of data blocks (because with variable data size the game must know how much of data there is). Usually the first value describes the number of bytes or blocks. So lowering the first value you're telling the game there is less data, so the model becomes less "shaded". And clearly the game interprets the data differently, because the still visible shades change look with each value. The byte you're changing could be the upper byte of a WORD or DWORD value, because the number is too small for the number of total bytes or blocks (unless the information is really simple).
Maybe this shade data has got its own offset block too?

What program are you using for the model display? Can you look at its source and see what it does with the data?

[MrQuetch]

Originally Posted by Zink

I don't remember where I've seen it exactly, but I can clearly reckon that the models had something called "shade information", and that its format was unknown. And looking at the Twinsen's pictures you've posted that was first that came into my mind.
I think the number you're changing is a number of data blocks (because with variable data size the game must know how much of data there is). Usually the first value describes the number of bytes or blocks. So lowering the first value you're telling the game there is less data, so the model becomes less "shaded". And clearly the game interprets the data differently, because the still visible shades change look with each value. The byte you're changing could be the upper byte of a WORD or DWORD value, because the number is too small for the number of total bytes or blocks (unless the information is really simple).
Maybe this shade data has got its own offset block too?

What program are you using for the model display? Can you look at its source and see what it does with the data?

I'm on a phone right now, so I won't talk much - it's hard. I am using the LBA Model Viewer for 1 and 2 models. I can see the files in hex, and can see their changes in the program. That's were the Twinsen images came from.

Edit: I'm back at my desktop. Ok, so the files have the number for that part, then the offset, and then the data part. Hopefully that makes more sense. The third number that I've changed for the normals (the data part?) does just that - I didn't touch the 'unknown' section which you believe is the 'shade information'. I'm still wondering what that is exactly. If it is the shade information, then it's just a matter of deciphering that data. Looks like I'll have to play around with it some more. I'm assuming what I'm changing is just a WORD (16 / 2) because just like the bones and vertices, there are in fact 8 bytes for each. I could be wrong, it might be a DWORD.

I sent a PM to Xesf, and he sent me this link: https://github.com/klusark/twin/blob...twin/model.cpp
It's been very helpful, and I've been looking at it off and on. He reminded me that there are parts that are rather difficult to follow. But, I've been trying to learn as much as I can.
I think in all honesty, just that bit of data that I'm having trouble with is that 'shade information' and perhaps another part of the header.
Once that's been solved, it should be possible to make custom models for the game.

Actually, I just looked at the code from that link above, and everything for the models looks like unsigned integers of 32 bits - does that mean that it's a DWORD (32 / 4)? It shows this in the 'void Model::loadLBA2(Common::SeekableReadStream *stream)' section. Also, if you look farther down the code, you notice that for the 'unknown' section that it is streaming those 2 uint32 integers as bit-wise operations. Hmm...

Something that occurred to me, and it's probably wrong - but what if that 'unknown' section was just the reference to where the polygon's index vertices are? Believe it or not, the polygons for every model in the game share the same offset that the 'unknown' section uses. That definitely sounds like something.

[MrQuetch]

I may have discovered what the 'unknown' data actually is! I still can't be certain, and it needs lots of testing. But, I can say a couple of things:

1.) Colors to use (from LBA2 main pallete) depending on normals' directions.
2.) Affects every normal to point in the same direction, regardless of normal-defined positions / directions.

I'll try to get some images up soon! One from the model viewer, and one showing it's results in game.

[MrQuetch]

I was having a bit of trouble getting the rotations for buildings to work earlier, but now they work without a problem! Also, besides creating a new 'building' scene, modifying it, and saving it, I can actually load any 'building' scene I want from the entire game - I just need to make sure I have the exact number of buildings already created for the 'building' scene that I want to load, otherwise I get errors. So, to figure out the size of a 'building' scene, you just need to look at the hex code of the 'object' information to see how many buildings you need to create, converting the value from hex to deci. I'm currently looking at the lighthouse on Citadel island, and everything is looking accurate - it tells me the sizes of objects, their collision sizes, it even lists the correct model index for the object, so I can tell what the object actually is! The floats on the collisions still can't be saved or loaded, but mostly everything works now! That being said, the lighthouse looks funky, but that's because it's being seen from a top view, so there are multiple collisions overlapping.

Again, I'll try to get screenies up soon!

[MrQuetch]

I'm also implementing a 3D view for my height program. Unfortunately, world to screen coordinates and vice versa is difficult in Game Maker, so when you view in 3D, you cannot edit the terrain that way. But, it's possible to switch back and forth to see the current progress.

But, once I learn binary formatters for Unity, I should be able to edit the heights in real time.

[MrQuetch]

I said I'd post some screenshots. So, here's one showing my building program which has loaded the lighthouse buildings from Citadel Island.



The next image shows a 3D view (from my height program) of the Citadel's 'Wood-bridge Cliffs' - the height's are not completely accurate in elevation, but I have yet to implement that. Also, the quads have 4 different vertex colors to ensure that the terrain is doing it's job - which it is...



Chances are in the future that I might just make a big program in which you can see all files put together for a particular scene where you can see elevation, light, textures, floor types, buildings and collisions, etc.

Hope I'm making some people out there happy.

[Polaris]

Does that mean you can place buildings elsewhere now ?

[MrQuetch]

Originally Posted by Polaris

Does that mean you can place buildings elsewhere now ?

Yes! Which is really awesome! Since I figured out the algorithm, not only can I make my own settings, I can also take an existing scene from the game, change it up a little, and save it back in!

[MevX]

Originally Posted by MrQuetch

Yes! Which is really awesome! Since I figured out the algorithm, not only can I make my own settings, I can also take an existing scene from the game, change it up a little, and save it back in!

That's super cool

[MrQuetch]

I can partially load model data now, and I can see vertices from a loaded model in a square-like formation for some reason - it's probably the float values for each axis because it looks like the integers are working fine. I can see the models from the top view, and things are starting to turn out.

[Polaris]

Originally Posted by MrQuetch

Yes! Which is really awesome! Since I figured out the algorithm, not only can I make my own settings, I can also take an existing scene from the game, change it up a little, and save it back in!

... Pic of a lighthouse in the middle of Citadel island ?

[MrQuetch]

Originally Posted by Polaris

... Pic of a lighthouse in the middle of Citadel island ?

Yeah. Sure, why not? I'll get a picture up soon and post it here when I've got the time, just for further proof and observation.

Actually, though, I'm going to go to work so you're not going to see that until several hours from now.

Quite impressed this has already got over 750 views - I don't think I've had another thread quite like this.

[MrQuetch]

Originally Posted by Polaris

... Pic of a lighthouse in the middle of Citadel island ?

Alright, dude, you said it. Here it is, literally in the middle of the island.

I still have yet to implement a button that 'seperates' buildings. Right now when I click on one building, it will grab all others in the same position. That should be easy to do, using a for-loop, I should be able to scroll through the index of which one I want selected when there are multiple in the same spot.

Anyways, more proof that it works. I hope your long awaited hours have made you happy, Polaris.

I would've edited the already existing area and added in extra buildings, but the way in which the program works is that you need to have the buildings already created and then loaded. I should be able to add more in the future. So, for now, I just made a new scene and dumped the buildings in. The lighthouse is composed of 7 different buildings all placed on top of each other - believe it or not.

[gravel22]

That's crazy MrQuetch! This is a good step to an outside level editor for lBA 2 :O

[MrQuetch]

Originally Posted by gravel22

That's crazy MrQuetch! This is a good step to an outside level editor for lBA 2 :O

Yup. I can now add in buildings manually rather than just inputting a number, which makes workflow a bit more flexible. I've recently added a button for selecting or deselecting all buildings / collisions. Right now I'm trying to make it so that if you delete a building who's index is in the middle of the amount of buildings, the index for every building decreases by 1 while still keeping the count of all buildings from index 0 to the max amount of buildings in the current scene.

You've got that right - that's the idea, Gravel. I hope one day to be able to make an entirely different game using the LBA2 engine - which includes custom LM2 models and ANM animations. Although, the core programming of LBA2 might stay, as I don't know how to edit 'core' game design. Perhaps some other people more experienced on the forums would know. Unfortunately, the models for LBA2 are very complex. Fortunately, I understand enough that I should be able to get some things made soon. But, as said before - there is still more of the LBA2 model structure to decipher. This is why it'd be so nice to hear more about the format from Frederick or Didier.

I can definitely say that a model editor (right now) is far more easy than a model creator - which I would like to have. But, chances are that there won't be a creator anytime soon. I've made a program where you can view the first two lines from hex to deci for an LM2, and see what the bytes mean. Xesf said once he had some time, he might look more on the header of the LM2's. It's minor parts of the header that need to be figured out in order to get custom models. Using the LBA Model Viewer, I've managed to add a single quad to 'cap' a 'box', and though the model showed fine in the viewer, it crashes in game because something is still wrong with the header. The bytes have to be 'on the spot' (as so the Esmer said who arrived on Twinsun - "We've decided to come and study your culture 'on the spot'."). Sometimes I feel like I'm wasting time trying to figure out the LM2's (it's going to be worth a million (to me) if I can get it to work), but it'd be so nice to make new models and bring another LBA feel back, literally.

[MrQuetch]

I now have a simple model creator for LBA 2. Unfortunately, it's very limited, and it's literally just editing a model that already exists from the game, but you've got to learn somehow. I took one of the many fence posts from Citadel Island, and the mesh is practically a box with 4 triangles capping the top with a vertex in the middle. I can now create any type of 'box' including moving vertices around, changing colors, and even render types. The normals still need a bit of work, but that shouldn't be too difficult. I'll try to get images soon.

[MrQuetch]

Alright, the normals now work how they should on models. I'm also working on placing textures for the terrain, and it works in my program - you can select any texture on the 256 x 256 texture map for the X, Y, length and width of it. But the program just needs saving and loading for that - which will be easy. That being said, you should be able to also view textures that are placed from various scenes in the game besides one's own.

[Polaris]

Awesome !!

[MevX]

Keep up the great work!

[MrQuetch]

Originally Posted by MevX

Keep up the great work!

Truth be told - it's quite a lot of work doing all of this. The point is that I'm learning, and that means that the programs will get better in the future - such to the point where they are released to the MBN. Sometimes I wonder what Fred would think if he saw LBA2 used for a 'different' game, like the same engine type of scenario.

[MrQuetch]

Currently making the program for texturing. In the meantime, this was done using for loops, and just shows a couple examples of textured terrain. The program will give more flexibility in how the textures can be placed, as well as sizes and mapping.

[Homeless]

Great stuff!

[Battler]

This is awesome! When this is done, I could use that to finally bring my project to bring back the Well of Sendell to LBA 2 whose island files the game has references to but not the actual files, to the next stage.