Wednesday, 28 January 2015

Metasequoia 4 Plugins – part 5

We can create a project template to generate an empty Metasequoia plugin project with most of the project properties already set.

Once we have created the project template we can select it from the list of templates in the File>Add>New Project dialog.

This means we won’t have to set all the project’s properties manually every time we create a new plugin.

Friday, 23 January 2015

Metasequoia 4 Plugins – part 4

This time we will create an Import plugin.

I will not use the class technique for creating the plugin.

I wrote a Metasequoia Python script [link] to import MilkShape 3D *.ms3d files and will write a plugin to do the same.

Plugins have access to more of Metasequoia’s inbuilt functions than scripts.

MilkShape 3D released a *.ms3d viewer with C++ source code [link].

We will use the *.ms3d file loading code from the viewer in our plugin to read the *.ms3d file so download msViewer2.zip and extract it somewhere.

Thursday, 22 January 2015

Metasequoia 4 Plugins – part 3

For more practise with creating plugins we will build a sample plugin that is bundled with mqdl’s Keynote plugin [link]. [web.archive.org]

Keynote is a plugin that allows animating in Metasequoia and includes another plugin to save the animations to *.x format.

The sample plugin included with Keynote is an Export plugin and demonstrates how to get the data from Keynote so you can save an animation.

The sample plugin doesn’t actually save a file but displays it in a console window.

The plugin needs the Keynote plugin (bone.dll) installed because it uses Keynote functions to access the data.

Instead of installing the Japanese version of Keynote there is a translated version available at the Sword of Moonlight forum [link].

I only tested with the Japanese version and the sample files and sample plugin are only included in the Japanese download.

To access the data Keynote must also be activated in the command panel otherwise the sample plugin reports an error.

Tuesday, 20 January 2015

Metasequoia 4 Plugins – part 2

I will write a plugin that does nothing much to show the basic process.

Open “mqsdk_en.html” which is found in the SDK root folder and click “Using Visual Studio” to open the instructions for writing a plugin for Metasequoia.

We configured the solution in the previous post so can jump to step 3 of the instructions and add a new project to the solution.

Monday, 19 January 2015

Building TRViewer – part 6

Running the Debug configuration in Visual Studio’s debugger means we can pause the program at some line and investigate the values of the variables.

We can then choose to execute the program line by line to see if the program does what we want it to do.

You pause the program by setting a breakpoint which is done by clicking in the gutter of the text editor.

A breakpoint is shown as a red dot in the gutter.

Set a breakpoint

Building TRViewer – part 5

If you are not an experienced programmer it can be difficult knowing where to start analysing a complex program like TRViewer.

C/C++ console programs usually start at the function named “main” so you look for that and start tracing the program from there.

Graphical User Interface (GUI) C/C++ programs also start at the “main” function but it may not be easy to find it, MFC hides it for instance and sometimes it’s called _tmain or WinMain.

Even if you do find it, it may not be much use since it usually just runs the program loop.

To analyse a GUI program like TRViewer, consider how you interact with the program.

Building TRViewer – part 4

TRViewer was written well before Paolone’s Next Generation Level Editor (NGLE) and next generation enhancement to tomb4.exe (TRNG) were on the scene.

Paolone did update TRViewer to open next generation levels and that version can be found in the Tools folder of your NGLE installation.

With help from meta2tr, I released a further updated version in this thread [link] that addressed some bugs and added some more features. Note that the changes were mainly tested with TR4 files and may not be correct for the other TR versions.

I have uploaded a zip containing the files that were changed to create the latest version (revision 5) of TRViewer at mediafire [link].


Saturday, 17 January 2015

Building TRViewer – part 3

We have successfully built both the Debug and Release configurations of TRViewer but when you try to open a file using the toolbar or menu in the Debug version TRViewer stops with the following runtime error.

Debug configuration runtime error

This is not a program “crash” in the ordinary sense.

The program “hit” an ASSERT statement which halted the program.

Friday, 16 January 2015

Building TRViewer – part 2

To build the release version of TRViewer, change the active configuration in the toolbar to Release and click BUILD>Build Solution.

Change active configuration to Release

Thursday, 15 January 2015

Building 3D Studio File Toolkit in VS2013

I’ll preface this post with the disclaimer that I am only a novice in C/C++ programming and using Visual Studio.

In the course of building TRViewer [link] the linker gave an error about not being able to open LIBC.lib.

LIBC is an old version of the Microsoft C runtime that was removed in Visual Studio 2005.

TRViewer is a Visual Studio 2003 project and so the third party libraries it uses from that era may use old Visual Studio default libraries.

It was found that the library requiring LIBC was the 3D Studio File Toolkit, ftkvc40.lib which had presumably been built in Visual C 4.0.

3D Studio File Toolkit is used to manage the 3D modelling format, *.3DS.

The quick fix was to set the linker to ignore LIBC using the /NODEFAULTLIB option.
According to posts found on the internet [link1, link2, link3] the proper thing to do is to recompile the library dependent on LIBC in the same version of Visual Studio in which you are building your program.

The rebuilt library must also use the same C runtime as your program.

The C runtime that a program uses is set in the project’s property pages.

See Configuration Properties>C/C++>Code Generation>Runtime Library where you have the choice of four runtimes, /MT, /MTd, /MD or /MDd.

Four runtimes

/MT and /MTd link to static runtimes and /MD and /MDd link to DLL runtimes.

Wednesday, 14 January 2015

Building TRViewer in VS2013 Community Edition

TRViewer is a program used in the Tomb Raider Level Editor (TRLE) community.

TRViewer screenshot

To compile and build TRViewer Microsoft Visual Studio must be used because TRViewer is a Multi Document Interface (MDI) program that uses the Microsoft Foundation Classes (MFC).

MFC is only included with the professional versions of Visual Studio and to use MFC with the free Express versions you had to complete a complicated process outlined at the CodeProject site. [link]

Microsoft has released a free version of Visual Studio that includes MFC called Visual Studio 2013 Community Edition so we will see if it can be used to build TRViewer.

TRViewer was originally built in Visual C++ 6.0 and Visual Studio.Net 2003 and if you have a copy of those programs you should use them.

Because there have been lots of changes in the C++ language and Visual Studio since 2003 we will get lots of errors in Visual Studio 2013 building TRViewer and there is no guarantee we will be successful.

I only know the basics of C/C++ and am a novice with Visual Studio and MFC but let’s give it a try.

Monday, 12 January 2015

NuGet Package Manager – part 1

NuGet Package Manager is an extension for Visual Studio that simplifies installing third party libraries for a project. [link]

NuGet Package Manager downloads a package containing the third party library and configures the project to use the library.

Normally you would have to download and extract the library, configure the project to find the Include and Lib directories of library and add the library’s *.lib file or files to the project’s dependencies in the project’s Property Pages.

Metasequoia 4 Plugins – Getting Started

New features can be added to a registered version of Metasequoia by installing plugins.

A plugin is a *.dll (dynamic link library) file.

A *.dll is a type of program created within a software development environment such as Lazarus, Delphi, Visual Studio, CodeBlocks, Orwell's DevCPP, NetBeans, ZinjaI, Pelles C, Falcon C++, CodeLite or text editor/compiler/linker combination.

A *.dll cannot be executed by double clicking on it for instance, but must be loaded by another program and just contains coded functions which are used by the other program.

tetraface Inc. provides a Software Development Kit (SDK) that must be used to write plugin *.dlls for Metasequoia.

In this post I will outline the process of building the plugin examples included in the SDK.