Openxcom MODS


  • Please log in to reply
62 replies to this topic

#1 luke83

luke83

    Sergeant

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male

Posted 01 July 2012 - 11:06 AM

As the development of Openxcom continues, more modders are starting to find themselves onto the forums, As such i have changed my personal mods storage site to a General Modders storage site to give a home to the ever increasing items showcased on the Openxcom Forums.

   As such Moriarty started showcasing his work on http://openxcommods....s.weebly.com/��, please head on over and check out his new flying suit Posted Image

Also there is some x-com modding guides stored under "How-To" on there also, they may not be written very well but it should be able to turn any x-com fanatic into a Openxcom modder.

#2 silencer_pl

silencer_pl

    Captain

  • Members
  • PipPipPipPipPip
  • 4,392 posts
  • Gender:Male
  • Location:Poland

Posted 01 July 2012 - 02:48 PM

Do you think that would be possible to make flying suit like in Apoc or Disruptor armor or is resolution in EU to low to make a good copy ?
Posted ImagePosted ImagePosted Image

#3 luke83

luke83

    Sergeant

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male

Posted 02 July 2012 - 08:38 AM

You could make a suit like that , the detail levels would be very low but a descent resolution inventory image would allow people imagination to fill in the gaps.

Does anyone have a exported copy of this sprite from Apoc , i would be willing to make a trial run to see how bad it looks with EU pixel count?

#4 silencer_pl

silencer_pl

    Captain

  • Members
  • PipPipPipPipPip
  • 4,392 posts
  • Gender:Male
  • Location:Poland

Posted 02 July 2012 - 10:52 AM

I would need something to extract data from TACDATA. XED doesn't do that.
Posted ImagePosted ImagePosted Image

#5 luke83

luke83

    Sergeant

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male

Posted 18 July 2012 - 11:10 AM

Just a update , We have increased our  "How To" section on my site and it now has SOMETHING on my Favourite programs needed to mod x-com, Sure there is still plenty to add ( especially since a BB_Toolkit section has been created) but we are trying to show just how easy it really is to make your own maps and sprites to be used in game.
Check it out http://openxcommods....com/how-to.html

Also for those not sneaking around the OpenXcom Site , Version 0.4 should be officially released at the start of next month.
http://openxcom.org/

#6 Bomb Bloke

Bomb Bloke

    The Smily Admin

  • Admin
  • PipPipPipPipPip
  • 4,625 posts
  • Gender:Male
  • Location:Tasmania (AU)

Posted 19 July 2012 - 01:15 PM

That's all kinds of awesome. A couple of notes on my stuff:

Quote

an interesting effect: when I tried gif2pck the first time, the sprite order in the resuting .pck file was all wrong. It might have been because I was running it from a USB memory device: apparently the tool did not actually sort the files itself, but instead relied on the file system to provide them in the correct alphanumerical order. once I moved the whole directory structure to the HDD, everything worked beautifully.
You're spot on about this; Java supposedly gets the file listing from the OS, and for whatever reason it's not alphabetically sorted when dealing with external drives. In fact, if memory serves, it's reverse order for those. I've no idea why. Perhaps I should apply an alphabetical sort of my own.

Quote

One problem is: the converter is a little bit too smart for our good and actually creates the .gif files with a reduced palette, omitting any colors that the current sprite doesn't use.
Er, which converter are you talking about? When converting to GIF with my tools, you should get the whole palette in the resulting GIF file, all 256 colours worth.

That said though, if you DO increase the colour depth and start editing, you could then tell GIMP to pack the image back down to GIF without palette matching yourself, then pass the result to gif2pck. It'll do the matching for you (though if you never increase the colour depth you'll avoid accidentally using colours that'll convert poorly, this function is handy if you want to copy'n'paste in art from other sources).
BB's X-Com Projects Page - X-Com Games At GamersGate
You're just jealous 'cause the voices only talk to me :P
We love Tammy! :)

#7 luke83

luke83

    Sergeant

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male

Posted 19 July 2012 - 07:06 PM

Hey Bomb Bloke, another modder is actually writing the help section on Your stuff , i will pass this info on to him.

#8 Moriarty

Moriarty

    Squaddie

  • Members
  • Pip
  • 5 posts
  • Gender:Male

Posted 19 July 2012 - 09:47 PM

View PostBomb Bloke, on 19 July 2012 - 01:15 PM, said:

In fact, if memory serves, it's reverse order for those. I've no idea why. Perhaps I should apply an alphabetical sort of my own.
Actually, for me it started at an offset. I think it was 30. It makes me think that instead of actually being sorted alphabetically (or alphanumerically) they might simply have been added in the actual physical order of appearance on-disk, being a fat-32 USB memory device in this case. Though why they would be in that order specifically eludes me.

Quote

Er, which converter are you talking about? When converting to GIF with my tools, you should get the whole palette in the resulting GIF file, all 256 colours worth.

That said though, if you DO increase the colour depth and start editing, you could then tell GIMP to pack the image back down to GIF without palette matching yourself, then pass the result to gif2pck. It'll do the matching for you (though if you never increase the colour depth you'll avoid accidentally using colours that'll convert poorly, this function is handy if you want to copy'n'paste in art from other sources).

My little experience comes from pck2gif, and the resulting images did not have a full palette. Or definitely not all of them. The colors that are used are there, but some or all of the unused ones are either changed to #000000 or missing entirely (if the number of colors used is 16 or less, I guess).
I'll try and check again ASAP, to see if I've made a mistake or else if I can provide some more information on the matter. :)

BTW, did you find the bullet/projectile sprites yet? I checked today and found the data in the openxcom source code (they adopted the hardcoded approach for now), but I lack the programming skills (or the patience) to convert the raw bytes into a gif or pck :(

#9 Bomb Bloke

Bomb Bloke

    The Smily Admin

  • Admin
  • PipPipPipPipPip
  • 4,625 posts
  • Gender:Male
  • Location:Tasmania (AU)

Posted 20 July 2012 - 02:31 AM

What I suspect's happening is that you opened some of the GIFs in some other editor (Paint or something) and re-saved them. That might've dropped the colour depth in a bid to reduce file sizes. (Not much point though, as these particular images use less then a typical cluster anyway; thanks to slack space, they effectively can't be shrunk.)

Sorry about the bullet sprite thing; I'm easily side tracked these days. I've now found the post I'd been thinking of.

To explain how it works: Each bullet is composed of a number of 3x3 sprites (up to 35 of the things, it seems). When you fire, the game figures out an angle, and starts processing a line from your unit that gets longer and longer each frame. Near the end of that line it draws the bullet sprites, close enough together that most overlap. Some of the sprites are empty, signifying "gaps" in the bullet trail, and some sprites aren't part of the bullet at all (they may be used to show the smoke that trails behind a rocket for eg). Using this system, bullets can be rendered in a way that looks "natural" regardless of the angle of fire.

As far as modding the things goes? Well, the easiest way would be for OpenXcom to load the sprites from an image file, like the one Volutar posted. In fact I've gone ahead and shrunk that one down to just the sprites, dropped the resolution and colour matched it:

bullet sprites.gif

The idea is that OpenXcom would come with a file like this that'd it'd load on startup. If you wanted to edit bullets, you'd simply edit this file. Pretty similar to how the old WinAmp skins work (or how MineCraft texture modding works, if you've ever messed with that).

Of course something could be coded up to rip the sprites from the original game to such an image (or dump it back into the EXEs). In terms of OpenXcom, this'd mean that it wouldn't need to include the original graphical data - if it couldn't find the sprite image file on startup, it'd create one from the user's copy of UFO, then use that from then on.
BB's X-Com Projects Page - X-Com Games At GamersGate
You're just jealous 'cause the voices only talk to me :P
We love Tammy! :)

#10 Moriarty

Moriarty

    Squaddie

  • Members
  • Pip
  • 5 posts
  • Gender:Male

Posted 20 July 2012 - 02:12 PM

Thanks for the bullet sprite info! I suspected something like that. I agree that it would be best to externalise that as an image file somewhere... let's see if the devs agree :P

as for the GIFs, no, I definitely did not open them in any other editor before that.

I just re-tested it: I took the original game files, used "pck2gif handob" and here's the resulting image for the first rifle sprite, to the right of it the actual palette of that image as shown by GIMP, no additional steps in-between. maybe java has changed since you programmed it first? are you using a routine that may have been "upgraded" to do things automagically?
Posted Image

#11 Bomb Bloke

Bomb Bloke

    The Smily Admin

  • Admin
  • PipPipPipPipPip
  • 4,625 posts
  • Gender:Male
  • Location:Tasmania (AU)

Posted 21 July 2012 - 01:01 AM

No, I'm not using any in-built Java routines for the GIF encoding. I wrote them from scratch.

So I'm going to blame GIMP. That particular image only uses colours within the first 16 indexes of the palette, and so it decides the rest is superfluous and omits it (presenting the file as 4-bit). But I bet if you right click the files my tool is outputting in Windows Explorer, bring up Properties and check the Summary/Details panel, it'll tell you they're 8-bit.

Dunno if it helps you narrow things down, but I can tell you that the complete 8-bit palette takes up 768 bytes of data; for the PCK sprites, you'd expect the overall filesize to be something like 800-1,200 bytes all up. For a 4-bit image it'd only be 48 bytes worth of palette data, so the file sizes would be more like 150-400 bytes all up.
BB's X-Com Projects Page - X-Com Games At GamersGate
You're just jealous 'cause the voices only talk to me :P
We love Tammy! :)

#12 Moriarty

Moriarty

    Squaddie

  • Members
  • Pip
  • 5 posts
  • Gender:Male

Posted 22 July 2012 - 06:06 AM

View PostBomb Bloke, on 21 July 2012 - 01:01 AM, said:

No, I'm not using any in-built Java routines for the GIF encoding. I wrote them from scratch.

So I'm going to blame GIMP.

you know what, I think you're right. I never thought it possible, but I tried opening the same file with irfanview and saving the palette info from there, and it gives me the full palette as .pal text format.
I'm going to write a message to the GIMP dev community. I can only see this as a bug. There appears to be no way of making the GIMP show the actual palette. Even if you use it to export the image's palette, it gives you the reduced one.

I'm sorry for suspecting your converters when in fact the GIMP was the culprit :)

#13 Bomb Bloke

Bomb Bloke

    The Smily Admin

  • Admin
  • PipPipPipPipPip
  • 4,625 posts
  • Gender:Male
  • Location:Tasmania (AU)

Posted 22 July 2012 - 11:01 AM

Can't say I blame you; I'd be inclined to blame my messy-looking stuff too (if I didn't already know exactly what it can and can't do).  ;)

It's possible it's on oversight, but I'm thinking someone somewhere wants it to work like that. If you submit a report, be clear on the current behaviour in addition to the expected behaviour, and why you want it to act the way you do.
BB's X-Com Projects Page - X-Com Games At GamersGate
You're just jealous 'cause the voices only talk to me :P
We love Tammy! :)

#14 Bomb Bloke

Bomb Bloke

    The Smily Admin

  • Admin
  • PipPipPipPipPip
  • 4,625 posts
  • Gender:Male
  • Location:Tasmania (AU)

Posted 27 July 2012 - 11:37 AM

View Postsilencer_pl, on 02 July 2012 - 10:52 AM, said:

I would need something to extract data from TACDATA. XED doesn't do that.
spitting.gif
BB's X-Com Projects Page - X-Com Games At GamersGate
You're just jealous 'cause the voices only talk to me :P
We love Tammy! :)

#15 Moriarty

Moriarty

    Squaddie

  • Members
  • Pip
  • 5 posts
  • Gender:Male

Posted 27 July 2012 - 11:43 AM

so you're saying that XED does extract data from TACDATA? sweet. go silencer_pl, grab some armor sprites and we'll try making them into UFO:EU/openxcom format armor files :D



also, I've submitted that weird GIMP behaviour as a bug: https://bugzilla.gno...g.cgi?id=680453

I wonder if they'll find what causes it.

#16 Bomb Bloke

Bomb Bloke

    The Smily Admin

  • Admin
  • PipPipPipPipPip
  • 4,625 posts
  • Gender:Male
  • Location:Tasmania (AU)

Posted 27 July 2012 - 12:26 PM

No, I'm saying I can extract data from TacData.  ;)  I've spent the last few evenings figuring out (what I hope to be) the bulk of Apoc's sprite formats.

But I probably won't have all the armour sprites pulled until sometime tomorrow. Some of the blighters don't want to come out yet and it's getting late here now. There's a lot of them, too - over a hundred images for Marsec helmets alone, for eg.

I'm interested to see what they have to say about the colours thing. Thanks for the link, I'll keep an eye on it.  :)

Out of interest, if you:
  • Load one of the affected images
  • Apply the full palette to it
  • Save as a new GIF and quit GIMP
  • Restart it and reload the new file
... does it drop the colours again? What about using other palette-based formats the program might support (eg 8-bit BMP)?

To be clear on how the palette in an image file works, it has to be of a length equal to a power of two. For example, 256 is two to the power of eight; 16 is two to the power of four (see where the terms "8-bit image" and "4-bit image" are coming from?).

What I'm assuming is that while GIMP loads the image, it keeps track of the highest colour index used, then loads an amount of indexes from the palette equal to the lowest power of two it can get away with (instead of loading whatever the file header tells it to load).

For eg, if the highest colour used is 13, then it loads the first 16 colours (it doesn't really care if all those colours are used in the image, it just thinks it doesn't need more then that - two to the power of three is only eight, so it has to jump to two to the power of four, which covers 16). If the highest colour index was 43, it'd load the first 64 colours (two to the power of five is only 32, but two to the power of six is 64), and so on.

However the file header DOES state exactly how many colours are in the palette, and so GIMP should respect that and load the lot. The catch is this means a larger file size when it doesn't seem to be needed (hence why I think someone somewhere thinks this is a feature).
BB's X-Com Projects Page - X-Com Games At GamersGate
You're just jealous 'cause the voices only talk to me :P
We love Tammy! :)

#17 luke83

luke83

    Sergeant

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male

Posted 27 July 2012 - 09:47 PM

Nice work exporting the Apoc Sprites , i would leve to get my hands on them also for some experiments

#18 Moriarty

Moriarty

    Squaddie

  • Members
  • Pip
  • 5 posts
  • Gender:Male

Posted 28 July 2012 - 12:37 PM

View PostBomb Bloke, on 27 July 2012 - 12:26 PM, said:

I'm interested to see what they have to say about the colours thing. Thanks for the link, I'll keep an eye on it.  Posted Image

Out of interest, if you:
  • Load one of the affected images
  • Apply the full palette to it
  • Save as a new GIF and quit GIMP
  • Restart it and reload the new file
... does it drop the colours again? What about using other palette-based formats the program might support (eg 8-bit BMP)?

To be clear on how the palette in an image file works, it has to be of a length equal to a power of two. For example, 256 is two to the power of eight; 16 is two to the power of four (see where the terms "8-bit image" and "4-bit image" are coming from?).

What I'm assuming is that while GIMP loads the image, it keeps track of the highest colour index used, then loads an amount of indexes from the palette equal to the lowest power of two it can get away with (instead of loading whatever the file header tells it to load).

For eg, if the highest colour used is 13, then it loads the first 16 colours (it doesn't really care if all those colours are used in the image, it just thinks it doesn't need more then that - two to the power of three is only eight, so it has to jump to two to the power of four, which covers 16). If the highest colour index was 43, it'd load the first 64 colours (two to the power of five is only 32, but two to the power of six is 64), and so on.

However the file header DOES state exactly how many colours are in the palette, and so GIMP should respect that and load the lot. The catch is this means a larger file size when it doesn't seem to be needed (hence why I think someone somewhere thinks this is a feature).

I've done some further testing and updated the bug report... apparently, the GIMP only loads the palette up to the last used color. everything after that is simply dropped. I think I remember an occasion were some colors from in-between have also been dropped, but as of now I haven't been able to re-create that.

#19 luke83

luke83

    Sergeant

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male

Posted 01 September 2012 - 11:05 AM

Another Openxcom modder has started sharing his work on the Mod site , check out his new combat sprites.

Attached Thumbnails

  • ARMY1.png


#20 Hobbes

Hobbes

    Peace through superior hairdos!

  • Fan Fiction
  • PipPipPipPipPip
  • 1,197 posts
  • Gender:Male
  • Location:Area 51

Posted 23 September 2012 - 12:55 AM

Hey Luke, I've just replied to you and I've been looking at your site, very nice work so far.
Terrain Pack - 44 new terrains for the original game, using OpenXcom

My X-COM Fan Fictions: The Unknown Menace, Abyssal, Eulogy




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users