Tool for converting Ultima Underworld and Shock 1 Levels into Unity.

[67428d2cac3a4bluemess]

@up: WTF?

[67428d2cac8f5Al_B]

Usually the guard is placed in the include file itself, not in the files including it.

As an addition to this, you appear to have the guard conditionals for all include files in the include files themselves.  For a larger project this would become a nightmare to maintain and isn't necessary.  Something like this is normally sufficient - using textures.h as an example:

Code: [Select]

#ifndef textures_h
#define textures_h

#define CAULK -1
#define VISPORTAL -2
#define NODRAW -3
#define TRIGGER_MULTI -4

typedef struct texture
{
int textureNo; //internal texture no.
...
} texture;

extern texture *textureMasters;

#endif // _textures_h

(As you're using C++ there's also no particular need for the "typedef" and the trailing "texture" after the structure declaration but I'm sure you weren't looking for a full code review )

[67428d2cacb52hank morgan]

Before I started this project I hadn't touched any c based language in about 10 years. I had started the tool as a relearning project and I have no doubt the code is a bit ugly so thanks for the comments. I've just cleaned up that code a small bit.

As for actual progress I can now load place-holder objects into System Shock levels and I can click on them in the map editor and see from their description what they should be and from a quick visual check most things appear to be loaded correctly. This is kind of a big milestone in the project since I'm now at the point on all three games where I can sit down and see how much work is involved.

The way I load my place holder objects is through a config file that maps the games internal ids (in my code it is the item_id value) to a model path. This file also contains a couple of values which tells me what the type of the object is and whether it is a static model or an entity. This saves me somewhat from diving into the original files too much since most things have obvious properties that don't need to be copied or converted over.  I use a similar file for texturing that includes the alignment parameters and texture path that I need.

In System Shock that file is about 475 entries long. Underworld is sightly less at 463 entries.

[67428d2cacd2ficemann]

Final easy task left by the sound of it: Getting it to play the assigned music for a level.

Rest will be the "fun" stuff.

[67428d2cace97bluemess]

@hank morgan: It can be seen that you're an old timer because you basically write in ANSI C Ugly code is not necessarily a bad thing. Usually projects can be divided into two kinds: projects with fancy pretty code, and projects that actually get finished and work. Anyhow, do yourself a favor, and look up how to use include guards because you're really doing it unnecessarily hard way.

[67428d2cad38chank morgan]

Thanks everyone for the coding advice. I've cleaned out must of those defines now with the exception of one circular reference between d3DarkMod.h and tilemap.h. I'm a very procedural kind of programmer which probably makes things more inelegant than OO implementations would. I feel a bit embarrassed when I look at the code of similar projects because they've made it look so simple in comparison.

Final easy task left by the sound of it: Getting it to play the assigned music for a level.

Rest will be the "fun" stuff.

  I haven't even thought about music yet. Anyway I've made progress on item 1 of 475: Logs. I can now read logs left scattered around the levels and I have prototyped audio playback via script when a log is opened.

@hank morgan: It can be seen that you're an old timer because you basically write in ANSI C

Jeez. I'm not that far gone yet.

[67428d2cad691bluemess]

[...]
Jeez. I'm not that far gone yet.

Don't cut yourself short, a lot of things can change in ten years

[67428d2cada6eRocketMan]

What's wrong with ANSI C?  I find it far more intuitive than C++.

[67428d2cadd6cvolca]

Nothing is wrong with plain C. The source code seems like a C code to me, anyway (aside from some includes, such as <fstream>). Just the extensions advertise the C++. With some minor changes it looks it would be just plain C code.

[67428d2cae052volca]

@hank morgan: It can be seen that you're an old timer because you basically write in ANSI C Ugly code is not necessarily a bad thing. Usually projects can be divided into two kinds: projects with fancy pretty code, and projects that actually get finished and work. Anyhow, do yourself a favor, and look up how to use include guards because you're really doing it unnecessarily hard way.

I realy hope you're not right 
Can we at least pretend boost is an exception to your rule? Please?

[67428d2cae490bluemess]

What's wrong with ANSI C?  I find it far more intuitive than C++.

I don't think that it was implied anywhere here that there is something wrong with C, and I don't think that either. Many great libraries these days are still written in C. I've just pointed out that the code looks almost like plain C. There's nothing wrong with Assembly either, C just offers faster, more convenient, and less error prone ways of coding, and so is C++ over C (also, with some exceptions, C++ is backward compatible with C). As C++ is so reach in available features that it is overwhelming, the thing is that you don't need to use or know them all, just use at your convenience the ones that suit your needs.

I realy hope you're not right 
Can we at least pretend boost is an exception to your rule? Please?

Not my rule, I've just seen it popping around here and there Like most rules, this one has its exceptions. C'mon, boost? This rather applies to one person hobby projects, not to the one of the worlds largest, most supported library, written by the best specialists there are.

[67428d2cae5c9volca]

Well, they we're okay

It may mean that taking shortcuts can be benefiting, as you reach the goal sooner. It would worry me though to use this strategy on anything larger than a simple command line tool, though - the aftereffect being you may have to pretty much rewrite the damn thing.

[67428d2cae761bluemess]

@volca: I agree, but I wouldn't call it a strategy, or a rule to follow. You can make some "dirty" solution from the top of your head to a problem at hand that works, and move on, or spend time trying to make it fit some paradigm that is considered nice and clean, maybe make it more generic and reusable (which very likely will not be anyway). In the first case you're progressing faster (and seeing progress is rewarding and motivating), but later it might come back to bite you. In the second case you might just burn out, and lose interest because progressing will seem slow. These cases don't necessary contradict each other, you can write nice code and progress fast. The idea is to find the middle ground, and not prioritize how the code looks over making actual progress.

[67428d2caea35hank morgan]

Some slow and also good progress this week. I had an interesting challenge this week with the way SS1 stores objects that extend over multiple tiles that was causing object duplication and in some cases infinite loops when running through the linked list of objects. That's behind me now I hope and I've done some work on reading in trigger properties and actions (per sspecs.txt) so hopefully in the next week I will have written a similar script generator to what I'd prototyped with Underworld 1.

I also had a fun little experiment with this little serv-bot.
Image: http://i.imgur.com/cKNAo2w.jpg
Not only is he a sprite but he's also an animated sprite. He's not an AI though and he just stands there waving at me. He's just a texture material file that loops through a few animation frames. I just apply that texture to a surface and with the correct parameter(deform sprite) that surface will always point at the camera. I've also tested it with a few item sprites as well. The sprites appear to work when applied to a worldspawn brush, a func_static but not on a model as far as I can tell so far but I only did a quick and dirty test on that.
Another cool thing is that I can change how the sprite appears or change what image appears via script)  I don't know yet if this is a direction I will go in for basic object generation as I still have a few issues with automatically tying object frame indices (objprops.dat) to their correct sprite. I could always manually match the entries up but I'd rather let the tool do that for me plus given how small most of the sprites are as well it makes it hard for me to visually identify what I'm looking at when I'm poking through the art files using DumpTex.

I've also played around with using a func:forcefield to act as a repulsor lift and I've been killed about 50% of the time I've gotten on one.

[67428d2caebfbJoin2]

Attention! The Metal Mother is pleased and impressed with your abilities and progress, insect. She considers promoting you to the title of "Vermin", a never before awarded title to any of her puppets. But remember, what SHODAN gives she is more than able to take away.

She also insists you do her game modification-related biddings until you expire. I am merely the vector of her commands. Expect more commands once this project is finalized.

[67428d2caf201unn_atropos]

I just apply that texture to a surface and with the correct parameter(deform sprite) that surface will always point at the camera.

Does that mean it will recreate sprite behaviour like in System Shock 1?
On http://tcrf.net/System_Shock there are some sprite sheets.

All of the "human corpse" sprites in the game have a full set of 8 rotations in OBJART.RES, though the game always displays the same one regardless of angle. Whether this is deliberate or the result of an oversight is unknown.

[67428d2caf3a5voodoo47]

I was just about to mention that - it'd be nice to have this fixed/readded in the future.

[67428d2caf5e8hank morgan]

So the above method doesn't appear to work with models but it does appear to work when I use my material file(that contains the animation) as a particle. So after following this article http://wiki.thedarkmod.com/index.php?title=Particle_Attachment_for_AI I was able to make this work. Image: http://i.imgur.com/m8reooL.jpg The sprite follows the AI anchored around his head.

If the article is to be believed then I think it could be possible to have a different particle for each type of animation that the AI will go through (orientation from different angles would be a problem though) and attach it to an invisible AI for clipping. Again I'm undecided if I'm going to go down the sprite route just yet.

Note the ugly halo is a result of a quick and dirty conversion of the art files. I'd ideally like to have a tool that converts straight from the objart.res files into .tga format with alpha channels set up. (Irfanview doesn't appear to do alpha channels)

[67428d2caf715Carrot]

I've been following your check-in notes on github.  You seem to be working on this still, are you waiting on something big to update this thread with?  Small updates are awesome too

[67428d2cafac7hank morgan]

I've been following your check-in notes on github.  You seem to be working on this still, are you waiting on something big to update this thread with?  Small updates are awesome too

Still plugging away. There were a few things I wanted to get working before I posted again. My current quality target is to be able to traverse the entirety of level 1 without needing noclip and to be able to unlock doors using keys.

At the moment I have really dangerous and buggy repulsors (upwards only at the moment). I'm most of the way there on elevator platforms and I have working ladders. Switches (in easy mode ) and step on triggers work and for a lot of things even if there is no physical actions being performed at the very least the in-game console will display what should be happening for all the actions. I've yet to touch doors due to the different way SS1 handles object orientation though but I'm hopeful that they won't be a huge problem since I already have doors working in Underworld.

I'm also having to spend a bit of time researching various trigger/object properties. Things can be slow in some parts since I am up against the limit of what is documented. I'm starting to get a good picture of things in my head now and I have started recording undocumented stuff at the github wiki.

[67428d2cafc0dhank morgan]

So here's a cool useful thing I should have realised earlier. Just like Underworld, Shock saves a copy of the level datafile with each save file. And my tool just happens to be able to work with those files since they are the same format as the archive.dat so I can just create a before and after file for each type of thing I need to investigate and just compare the properties to see how they work.

[67428d2cafd5eAl_B]

Good to know that SS1 does the same thing - it was very helpful in analysing Underworld.  It's also useful to change the files themselves and see the effects that has in-game.  (e.g. change repulsors and see if it backs up your current theories).

[67428d2caff02hank morgan]

It's high time I actually released a properly packaged map. You can download it below. In order to play it you will need the Dark Mod installed. Just save the contents of the zip to [darkmod]/fms and use the New Mission->Install option in game.

Note that there is absolutely zero game-play, every model is a place-holder and some textures are misaligned. You might get some slow frame rates in a couple of places as well due to a feature I'm experimenting with.

I didn't quite get to a place where I was happy with replusor behaviour so they do not work here and there are no force-bridges yet so you will need to noclip to get past the radiation trench area to fully explore the level. Most scripts will have console output though so every now and then you should open the console (ctrl+alt+tilde) to see what should be happening behind the scenes.

[67428d2cb0026Carrot]

Very cool, just downloaded.  I'll try to give it a run and some feedback later today!