File formats for crusader levels

IGTC

IGTC

New member
Anyone know of any sources where to find the formats used to define crusader levels?

Cheers,
IGTC
 
Hi

What have you tried so far?
As known, Crusader uses a modified U8 engine.

The original formats are explained here:
http://wiki.ultimacodex.com/wiki/Ultima_VIII_Internal_Formats

Also the Pentagram Team has done an reimplementation of U8 as well as partial work for Crusader:
http://pentagram.sourceforge.net/

You may find something useful in their docs.

Right now I also wanted to create an map/level viewer, I've done an ShapeViewer so far...
 
Do we know if there's an accompanying file which can translate exported SHAPES.FLX filenames to more verbose/friendly names? I have several hundred sprites which I cannot identify by eye and that threw a wrench into the engine I was making.
 
compelx said:
Do we know if there's an accompanying file which can translate exported SHAPES.FLX filenames to more verbose/friendly names? I have several hundred sprites which I cannot identify by eye and that threw a wrench into the engine I was making.
Click to expand...

Yes that's a good question, I've also already thought about that - however the obvious thing is that there is no official source for these shapes?
I dont know of any - if you know then it would be possible to tie this one to the shapes, otherwise all that's left is naming the shapes on your on 1 by 1. :dodgy:

Im also looking for the logic in the TYPEFLAGS.DAT file, while I've read them and already figured out certain combinations which give me all weapons/items etc.
The overall picture is atm still pretty small... anybody has invested work in that already?

Edit:
Why did it stop you from making your engine?
Isnt it, if you want to load an map that the map data will tell you what shape to render at what (x,y,z)?
So basically there is no real need to know the official name of the thing... of course it would be insightful - but thats just for human purposes.
 
Yeah technically speaking I could ignore it and continue but I reached a point where I wanted to load in the extracted sprites as resources in my executables embedded library and when I attempted to put together/layout a new level it was difficult to do so without easily identifiable sprite names.

Edit: I'm under the impression a TYPES file for this exists but it may not have shipped with the game based on talks I had.
 
Hmm yeah probably, the original devs would have had such an resource for sure.
But its not that hard, for the aprox. 1450 sprites there are most of them are identifiable, like Explosions, Civilians, Weapons, Solider, Platforms (mechs) etc.
You just have to name them then, and let those out which are ambigious or unidentifiable - sooner or later you'll have them all.
 
Yeah that's the approach I took. At the moment I just need to assemble a sandbox level where I can test collisions. The one I have works but is very simple. I wanted something more normalized and realistic. I wanted to try and recreate rebel base but got bogged down on sprite management.
 
How are you managing the sprite properties, I take it you dont use the `Typeflags` - so you respecifying?
Well I guess simple wont hurt, I'd expect that collisions works all the same - in an isometric game it cant be that hard...
 
I could make calls to it but the software I'm using doesn't allow for programmatic environment building so assembling a room or view requires manual placement of sprites on the grid. The sprites collision mask is handled automatically by disregarding the green filler areas of each sprite. Because I chose to handle collision checking from the native viewing angle (as opposed to making it work like a top down and then pivot it) it was quite tricky!  Smooth collisions with and without sliding work but I was curious how what I build would behave in one of the original level environments. There are some things I think I may have improved on.
 
You must log in or register to reply here.
Back
Top