Team Blog

I don’t have much to say about the release, since almost everything important has been already described in my previous posts. Since the last one I was mainly fixing bugs. Though I have made two changes that are worth mentioning.

First one is the buttons panel Layout, you can see it on the picture below.

Nothing special, just rearrangement of the buttons. They are now better logically and visually grouped. I did it mostly because I needed space for a new button, and it didn’t fit in the old layout :).

Ah, right, the new button. So that’s three changes :). The button is , it is called Aim Tool. It allows you to copy position in Scene coordinates that is pointed by the mouse cursor to the system Clipboard. The position the can be easily pasted in zone coordinates, targets, camera positions and so on.

The last important change is the advanced opening dialog.

I have removed the LBA1/2 choice from individual items and put it on top of the window instead (it wasn’t possible to change use different LBA versions for items anyway). Now each item has ‘Original’ option which means LBA1 or 2, whichever is selected at the top. This should make it more clear, and cause less bugs. Also the “LBA mode” of opened stage will be determined by the top LBA setting, not by chosen Grid file, as it was before (and that caused bug so if new Grid was chosen for creation, the stage version was unknown).

For those who don’t remember what previous posts were about, here is a quick list of most important changes since beta 6:

• New Grid handling style (Fragments opened together with the main Grid in Builder),
• Automatic Fragment creation in Designer, Fragments referenced by names in Builder,
• Designer main window layout altered and split into two lists: Grid list and Fragment list for easier manual Fragments creation,
• Automatic generation of HQD files in Designer base on user-defined map descriptions

Also while browsing through my previous posts i have stumbled upon my first Architect progress report, at the end of which I have stated: Planned Beta 7 release: about two months from now. That one was posted in August 2009, now it is July 2010, so almost a year have passed since then. What a great fail at foreseeing :D.

The beta 7 can be downloaded here: LBArchitect_1.0.0_beta7.zip
Mirror: LBArchitect_1.0.0_beta7.zip
Source is also available: LBArchitect_1.0.0_beta7_src.7z
The beta 7 version also has its own article on my website: moonbase.kazekr.net

So Architect beta 7 is released and I said we would continue development when that happens. But despite the fact that almost a year have passed away, we still don’t seem to have any decent model/animation editor (Link was working on one, but he didn’t have time and will not for the next few months). So for now we are able to design Maps (and I hope we will get to it soon), but we’re very limited about character model editing. I have an idea to make a converter from a popular 3D object format to the LBA format. This approach wasn’t tried before because the LBA format is not compatible with any other format. It contains some ’sub-objects’ and ’shades’ that don’t seem to have equivalents in common 3D editing tools. Now I have got some ideas on how to overcome this problem, and maybe something can be achieved. However, I can’t promise I will succeed.

I haven’t discussed anything with our team members yet, so you are most likely to hear from us about the progress and decisions we make.

This means that I have just fixed the last issue for Beta 7 :D.
It is still gonna take a few days till the release because I have to make some preparations, and write an article of course.

Intrigued by Lightwing, who asked me on MBN forums if the 256 Fragments limit discovery actually meant that we could have 256 Grids (he didn’t understand me), I got an idea that maybe we could move the Fragments up without actually touching the hard-coded Fragment index value by just using space reserved for Fragments and putting Fragments after. I have tested that, and guess what: it works! The actual number of Maps (Grids + Fragments) we can use without engine modification is 376 (with a small drawback that Grids and Fragments numbers separately cannot exceed 256 - this is because their indexes are stored in one byte). I don’t think any LBA modification project will need more Maps than this, so it’s a great news.

This however has implication that manually created Fragments will be harder to use (their indexes will have to be modified to reflect their actual positions), but I don’t think we will need them, since we have Auto-Fragments :).

After a quite long period of development without any message I finally have finished the most important features of Architect that were planned for beta 7 release. Here I will give you a short description of each one of them.

Maybe not the most important…
…but I have converted Builder and Designer to Borland Developer Studio 2006 (Turbo Delphi) environment (they were previously developed in Delphi 7). The good side of the conversion is that BDS2006 has much better debugger, editor, and (almost) everything than version 7, but on the other hand, it can’t install third-party components (freeware personal version), and I use some of these. Fortunately, the only limitation is that the components can’t be installed into the IDE, thus managed vsually, however they can be used by manually calling in the code. I had to put them into the code giving them previous positions and properties. In addition I have modified the SpinEdit component (wrote my own frame-based version actually), so that it is easier to use and have more features: built-in large change buttons and automatic colour change when the entered value is incorrect. And another good thing is that the code is now ‘integral’, i.e. it doesn’t require any external components to be installed into the IDE thus making the code more accessible by others and easier to manage for me.

Now for the features
As I wrote about in the previous post, I was working on a feature that helps creating Fragments or Disappearing Ceiling Grids, as they are also called. I don’t want to repeat what I wrote there, so I will give only a brief reminder: the whole thing is about making the program(s) to automatically manage necessary Fragments based on how they are used in particular Scenarios. Users can reference the Fragments by their names, so they don’t have to bother about numbers, indexes, and planning all these things right at the beginning of their projects. Let’s get down to business.

The above screenshot shows the Fragments usage in Builder - in the object editor for Zones of type 3 there is a field called ‘Auto-Fragment’, which contains one of the Fragments from the current Scenario (or nothing). If it contains an existing Fragment name, information about this will be inserted into the Scenario for further use. Below, in the Script Editor, there are also some Fragment names used as parameters to the SET_GRM command (this command ‘turns on’ the Fragment display). The command still needs a numerical parameter, because the real Fragment index is not known at the time of Script compilation, so something needs to be inserted at that place in the code. In this case the information about referenced Fragment is also included in the Scenario.
By the way, if you’re curios about the program’s window borders (not the ‘classic theme’) - I recently decided to try the new Windows 7 Aero interface, and I wanted to try how it interacts with the program. The result was very good (it didn’t crash :)), so it seems that Architect is compatible with Windows 7 (64-bit edition). The other screenshots have the regular window borders because they have been taken on another machine, where I have Windows XP.

After editing is finished we can use the Scenario in Designer.

Designer also have been slightly modified. The main change is separate list of files that will be used as Fragments. In LBA Fragments are kept in the same file as Grids (lba_gri.hqr), they just start at specific index (121), so if one wanted to make a single Grid that uses a Fragment (not using the Auto-Fragment feature) he had to put 119 blank entries between the Grids and the first Fragment to make it work. This wasn’t very convenient, so I decided to make the separate list and the program will manage that automatically. Another change is some column rearrangement - the file columns are small and description column has been added to the right. The files columns now have less space for displaying the paths, but if two or more adjacent columns contain the same path they will be connected to make more space and only one path will appear. This may be a little confusing (especially for Fragment list where map index will be displayed in the Bricks column), but I think it will become more more convenient than the old way, after some trials. If one needs to see the full path, manual editing is now available. The description column serves two purposes: it keeps information what room each row contains for easier orientation, and it is used for automatic HQD files creation (yes, I made that one too :)).
In order to automatically create necessary Fragments for the Grid, just add the Scenario in the Grid list and that’s it. If the Grid inside the Scenario has by-name references and the Scene path points to the same Scenario file (that’s important), all necessary Fragments for the Grid will be extracted and added at the correct indexes (after manually created Fragments), and these indexes will be put into the Scene file at correct places. Actually the Fragments list doesn’t have to be used at all. It can be hidden.

The next screenshot presents project options’ first page, that contains the Auto-Fragment setting with detailed explanation.

There is also an option to manually set the first Fragment index in the lba_gri.hqr file, though it’s probably hard-coded in the game engine. I have made it because maybe it will be possible to change that index by hex-editing the lba.exe file in the future. And of course it will be useful if our custom engine is finished one day. I have made tests and discovered a great thing. Until now we have thought that the maximum number of Lba Maps (Grids + Fragments) was 256 (because the Grid indexes are kept in one byte in the compiled scripts). I have found out that the actual number is number of Grids that fit in below Fragments plus 256 Fragments (because Fragments are actually called by offsets starting with 0, so we get another 256 possible values). I have tested it in the game, so it’s not only my guess. If we can change the first Fragment index one day, the number will rise to 256 (or 255) Grids + 256 Fragments.

The last screenshot shows the result in the game. It’s not anything spectacular, actually I could have made that without using any of the features, I described here :), so it can’t be a proof. The screenshot simply shows Twinsen passing through one of the Zones that are set up to show a Fragment on such event, and the flower piece is the Fragment, so apparently it works :).

When I started writing this post I thought about sharing my test files and projects with you, so you could test that for yourselves, but then I realized that the Architect was not released yet, so you wouldn’t even be able to open the files. Thus, you will have to wait till the beta 7 is finally released, which will be soon, I hope.

The planned issues that I plan to address before the release are listed on the roadmap page in the bugtracker: http://sacredcarrot.xesf.net/mantis/roadmap_page.php (you have to select Little Big Architect from the combo box on the right, I can’t link to specific project pages).

By the way, I wonder if the Architect components couldn’t have better names. Factory seems good enough, but Designer may be somewhat misleading, as it is meant for design HQR files, not scenes or areas. Maybe the Builder and Designer names should be flipped over, or completely renamed. What do you think?

There’s been some time since the last news from me, so I decided to tell you what I am doing right now, and why it takes so long, so you won’t lose hope :).

I’m now working on a feature that will help the overall development of the LBA world areas. It is an automatic Fragment management in Designer (if you don’t know, it is a program that allows ‘compilation’ of separate Grid, Scene and Scenario files into HQR files that can be read by the game engine). This is how the game works: the lba_gri.hqr file contains Grids (which define terrain look and shape) and Framgents. Fragments are small parts of Grids (they have exactly the same format in LBA 1) that can be merged with a base Grid to change (replace) a specific area of it. For example the basement ceiling that disappears when Twinsen enters the north door in his house has been made with the Fragment feature (the Fragment contains transparent cells replacing the ceiling and nice egdes replacing the walls). Fragments are placed in the lba_grid.hqr at specified index, and they are referenced by their index relative to the first Fragment. It means that all Fragments that are going to be used in the game should be planned before starting work on the Grids, because later if you decide not use one of the Fragments it will have to be marked as ‘empty’ (blank entry in the HQR). It can’t be deleted, because this will change indexes of the Fragments above the deleted one (so indexes in the Scene will point to wrong Fragments). It is not much bothering, but can lead to many mistakes and problems.

The idea for the feature I am working on now is simple: reference Fragments by their names instead of indexes. If you want to use a Fragment in a Grid, add it to the Scenario (it will get automatic name, like ‘Framgent_1″, that can’t be changed yet), and use its name in the Script and in the Zones of type 3 (they automatically trigger Fragment replacing when player enters inside). Architect will add information about which Fragment is associated with which place in the Scene to the Scenario, and when you use that Scenario in Designer, it will automatically add all necessary Fragments and put their final indexes to the Scene. This will eliminate the need for manual creation and planning around the Fragments.

And now why it is taking so long: apparently this is much harder to make than I expected. the Builder part is finished (but not tested, so it may contain bugs), and I am now starting to implement it in Designer.

The second reason for the delay is the real life :). I am involved socially much more now than before, and therefore I have less time to work on this.

I hope this year will bring some more interesting developments in the Prequel :).

The following issues have been resoved now:

• The main menu items for Fragment support. Specifically: opening Grids as Fragments (intended for use with the original LBA 2 Fragments which are in the same format as regular Grids), copying selection to a new Fragment, closing the current Fragment and closing everything - it restores the program to state like it have been just started.
• Popup menu items for selection: Selecting everything, deleting the selection, and the meaning of “Copy sel. to…” and “Copy sel. the a new Fragment” have been changed. Now they don’t copy the selection, but move it, deleting the selected part from the original. This change was necessary, because I realized that there were no way of doing it with the options working as “copy”. This was because the selection is cleared while switching Fragments. Of course there is a possibility to copy instead of move by pressing Ctrl.
• All opening ways are now working for both regular Grids and Fragments,
• I have fixed some bugs,
• And I have added list of recently used Scenarios to the File menu for quicker opening. You will probably get an impression that Scenarios are something like “projects” in other software - this is a good association, and in fact I’m aiming to make them as comfortable to use as I can.

You probably wonder why these little things took me so long. This have been caused by two reasons:

1. I have less time recently. I can work on Architect only once per couple of days, and not for long each time.
2. When implementing these things I have found many bugs and inconsistencies that I just couldn’t leave that way. For example the selection moving feature didn’t allow for putting the selected area below [0, 0, 0] position, so for example when choosing Select All and trying to reposition the contents one couldn’t move the stuff “back” so a part of it would be off the rear wall. Even if there was some empty space between the contents and the rear wall - this in turn is caused by the fact that empty areas are also selected with Select All function (yes, it really selects [B]all[/B]). Another thing was a bug that caused normal blocks being cut out while playing aroud with invisible blocks. There were some more, that I don’t remember, and that took me quite much time to fix.

Not much to show this time: just a screenshot of the File menu after changes. It’s getting quite big already.

I have just finished fixing the modified/saving system. Unless it is bugged I shouldn’t have reasons to touch it any more.
Remember the dialog that popped up when closing Architect with unsaved files?

I have modified it to be more user-friendly and also informative. It now looks like this:

As I promised, I will from now on post information on the Architect progress. In the recent comment to the previous article I said that Link would be supposed to post his progress infos too, but I forgot that Link was not in the Prequel team, thus he couldn’t do that :). However he will be posting progress on the MBN in this thread.

Here we go:
1.0.0 beta 6 - (Released) major changes:

• [Feature] Actor templates - you can now save an actor as a template, and then put it as many times as you want into the same or another Scene. References to the Actor inside its Scripts are maintained through the new SELF keyword, which, during compilation, will be replaced with the ID of the Actor, that the script belongs to.
• [Feature] Textual LABEL names (by LBAWinOwns) - it is now possible to use textual names for the Track Script LABEL commands and reference them by these names in all other places (including Life Script).
• Checking for broken Brick data has been added to both Builder and Factory. Factory shows list of indexes of broken bricks for easy repair.
• And many bug fixes.

Download: Primary server, Mirror [1.7MB]

1.0.0 beta 7 - (in development) major changes so far:

• [Bug] Builder crashes when using “select by layout” tool - resolved.
• [Feature] It turned out that there was no easy way to make disappearing ceilings in LBA1, because the game crashed when trying to use such ceiling. The reason for that is the “Layout usage list” - a list contained in each Grid, that tells the game which Layouts from the Library the Grid is using, so the game engine doesn’t have to load the remaining ones into memory. When trying to put a disappearing ceiling the used one of the “unused” Layouts the game displayed a wrong Layout, and sometimes crashed. This gave me an idea to make an option for filling the Layout usage list for Gird with all possible Layouts, so the game will always load them all, and this problem would be solved. I was wrong. The game then crashed every time, because it probably has some maximum amount of memory reserved for the Layouts, which has been computed from all the Grids (by checking which Grid used the most memory for Layouts) and hard-coded into the engine (in LBA 2 that value is stored in lab_bkg.hqr file), so Grids can’t use all Layouts from a Library, simply because they won’t fit into the limited amount of memory and the game will crash. This led me to another idea of an option to allow users to manually edit the Layout usage list for each Grid, especially to allow adding other Layouts to the list, but I don’t like this due to couple of reasons. Main reason is that users would have to manually edit this every time they start editing a Grid. Not a pleasant thing.
  So finally I have come to this: I’m gonna make the disappearing ceilings (called Fragments, but they are regular Grids in LBA 1 (in LBA 2 they have different format)) editing “incorporated” with the main Grid editing. All Grids and Fragments related with each other will be opened in the program at the same time, so the program will know exactly what Layouts should be put into the usage list so that everything will run smooth. Currently the multi-Grid system is working in Builder; things that need to be adjusted to be compatible with it: opening and saving system, selection and copying between Grids. Screenshots will tell you more.
• Scenario (*.HQS) file format have been changed in order to be able to keep any number of additional Fragments inside. Architect versions prior to beta 7 will bot be able to open Scnearios created with beta 7 and above. Factory and Stage Designer still need to be adjusted for compatibility.

Planned Beta 7 release: about two months from now (all the dates are likely to be changed in both ways).

I’m sure most of you are wondering about “what the heck is going on?” and “is this thing dead already, but noone is honest enough to admit that?”

Well, NO.

The recent absence of news has been caused by discussions among us about the future of this project. Now the discussions are almost done. No final decisions have been made, but we have come to a kind of compromise, that was necessary to continue the Prequel. Believe me or not, compromise is a good thing in current situation.

You know that the Prequel from the beginning was planned to be made with use of the original engine (LBAWin) or our custom engine (codename: Prequengine) that would be very similar to LBAWin, but would allow us to add some modifications (e.g. use of better quality sounds). Some time ago (can’t even remember when it was) some of us came out with an idea to, as we were writing our own engine already, make the engine use more detailed environments and object models. This was to be achieved by use of a ready-made graphics engine, such as OGRE (that’s why I asked once in a comment if GeForce2 would be a reasonable minimal requirement). RobG had become the leader of the engine project, as he already had some experience in OGRE programming, and he presented us some astonishing results of his early tests. Also the new engine would make the game development easier, because:

• it would use different object model format, which is suported by many professional modelling tools (including freewares),
• it would allow for higher quality sounds and voices (which means no struggle to make the LBA 1 format sound decent),
• it would allow for better quality movie clips.

But then after few months he just stopped responding and none of us knows what is going on with him. Unfortunately the Prequengine leader, alexfont, doesn’t have time any more to work on the engine, so we can’t currently foresight when and if we will ever have any custom engine.

This have led us to rethink our priorities, and we were forced to make the decision to stick with LBAWin for now, and in the future, if there are chances of getting a better engine, we will try to switch to it.

But this has consequences, from which the most important one is that we don’t have any 3D modelling tool that is easy to use (even vaguely resembling the industry standards), which means we have to write one or make a converter from more common standards.

As I am writing this I have information that someone is working on a modelling tool for LBA format. I just have released the LBArchitect beta 6, which is almost sufficient for us, and now I will try to write a converter between the 3D object formats (this is not as easy at it seems). I think it can be made faster than an editor, and I hope this will enable the work on Prequel going on again.

Before I had plans to start another engine project (I can’t help much with the other engine projects, because they are being written in C/C++, and I’m mainly skilled in Delphi), but as we have decided to use LBAWin for now, I will do the thing that is more needed for now. But I still keep the engine in mind and maybe one day I will return to the idea.

I hope that cleared up the things a bit, and that you haven’t lost interest yet

In case you didn’t notice, the MBN is down, and we’re not exactly sure what the issue is. Until we hear something, we know about as much as everyone else does.