Some stuff

[Conti-k]

When looking at SupSuper's screenshot I was lil' uncertain this feature, but after some thinking: bring it back! To highlight landing zone in night I'll add small-ish "landing" lights to crafts. Effect should be great. Besides, it's possible to tweak values here, and there - there's a wide range to play with (0-10).

Also, I've been watching that video with turned sound on, and I really liked the music 


----------------EDIT

I've made a quick test with lights attached to Skyranger's landing gear because this kind of highlight of landing zone does make a perfect sense (of course, light is spreading through all levels because nothing is blocking it right now). This is going to be great feature 

[Daiky]

Yeah, if you enable it, you would need a mod where landing gear emits light - good idea.

Also, I've been watching that video with turned sound on, and I really liked the music

Thanks, it will be part of my sound FX & music pack, to be released somewhere end of this year :p

[Conti-k]

Why ground tile (with non standard "height") overlaps scenery from one side while other is working normally? What's going on? Is there some logic behind it? If not, how about fixing it, because it's looking really ugly

-------------EDIT

Of course, I could "fix" the tile, but non standard height tiles that are completely rendered under the scenery (under the walls to be more specific) would be nice to have.

Speaking of that map: I've made a quick visualization of roof that fits with the rest of the building, instead of showing front walls. It's looking much better, much more naturally, I'd say

[Daiky]

There is logic behind it. It's the way how the engine works. Each tile is drawn first floor, then walls, then object. And then to the next tile, drawing the floor, if the floor is not flat, it will draw over the previous tile, then the westwall which will overlap the floortile (it's why you see half of it overlapping by the west walls)
I took over the way of drawing of the original xcom (this glitch is exactly the same as in the original- can show you screenshot if you want) because it was easier as sprites and maps are based on how the engine draws things.
It's probably possible to fix these kind of glitches.... but I don't know a nice way to do it right now.

[Conti-k]

Thanks for explanation, Daiky.

(this glitch is exactly the same as in the original- can show you screenshot if you want)

I know, and that's why I've posted it in suggestions forum 

I just want to finally enjoy original UFO without any overlapping (only this, and HWP on crafts ramp left), or any lights that highlight through solid floors/walls/whatever because this burns my poor eyes

[Conti-k]

It's related to how engine(s) draw things discussion thus I'll attach my post here.

Anyway, today I've noticed another proof that seems to confirm my (newest) theory that OpenXcom draws things like MapView does (except negative "tile y offset" value), which is in two cases different than original engine.

a) Step backward  (perhaps it should go to bugs forum? ):

Pieces that are raised to 24 voxels (they're sitting in wall slots) are overlapped by tiles level above. Details: there's no tile at the same grid, or "before" it level above. And they should overlap next tile to it, which means tile "after" level above (but it's opposite). I've been testing super-cool-looking cut-off pilot's compartment <==> cargo bay (advanced usage of engine's features ). See  attachment (top - OpenXcom/MapView, bottom - original engine). Of course, this should happen with "tile y offset: 24" only, because 24 is another level, but is displayed on level is placed as well, but when switched to level above, visually acts like object placed there (without "shadow casting", only proper drawing order - see original engine). Would be really great to make engine display stuff this way.

b) Step forward:

On a side (brighter) note: I've tried to move ground tiles one pixel down, and since it's not possible via frame editing - 32x40 limit - and that means one pixel less of height thus four pixels(!) would be lost, so I've tried to use "Print Level Adjust" (Tile Y offset) feature... Unfortunately it's possible to move frame down only with MapView (255 value is treated as -1). Both engines treat it as 255 up thus tile isn't visible at all. I thought it's working in similar way as "Terrain Level" (Unit Y offset): 256 - 8 (going up), and 0 + 8 (going down), but it looks like not... So I figured out I'll move walls one pixel up... and shit happened (you can see where walls are that are under it) so, I've tested it with OpenXCom... Awesome!

Of course, we shouldn't forget about this (step forward):

On a side note: I'm glad you've fixed overlapping issue...



(top - original engine, bottom - OpenXCom)

Dunno, to what it's related. Maybe it's Daiky's fix?



----------------------EDIT

By the way, funny side effect of odd HWP's behavior on hilly stuff 

[Conti-k]

- Add support for excellent Power/Flying Suit inventory images (BB's Mod Pack). Example:



For example, if these files exist in UFOGRAPH directory:

MAN_2F0.SPK - MAN_2F3.SPK
MAN_2M0.SPK - MAN_2M3.SPK
MAN_3F0.SPK - MAN_3F3.SPK
MAN_3M0.SPK - MAN_3M3.SPK

engine will use them, instead of MAN_2.SPK and MAN_3.SPK. Default ones could be used in UFOPaedia.

I have one question related to my request... I've noticed this in rulesets:

spriteInv: MAN_0
spriteInv: MAN_1
spriteInv: MAN_2
spriteInv: MAN_3

so I've made such trick to test the stuff:

type: STR_NONE_UC
spriteSheet: XCOM_0.PCK   
spriteInv: MAN_0 ==> MAN_2

Then I've added MAN_2F0.SPK, etc. to UFOGRAPH directory, but game crashes... the same happens with MAN_3. But changing MAN_0 ==> MAN_1 works... removing both MAN_2.SPK, and MAN_3.SPK gives an error about missing files... is there somewhere hardcoded the way how inventory artworks work in original engine? Or maybe I'm doing something wrong?

[SupSuper]

You did nothing wrong, just ran into an unimplemented feature. I've added support for the inventory suit sprites now and it should also work with custom ones.

[Conti-k]

Working like a charm, both with default, and helmetless version (if it's present, of course). Thanks for implementing this feature, SS.

[Zharik1999]

Will this feature with helmets be implemented? I finds it really cool because in the late game all your operatives look the same.

[moriarty]

the inventory images are just that: images. for now, openxcom uses the original images, but if you simply replace them with the other ones, it works just as well. so basically there is no need for openxcom to be changed

[Volutar]

It's too pity openxcom still doesn't have moddable easy-editable image resource format, like bmp maps (similar to used in ufotts, including "converter").

[luke83]

It's too pity openxcom still doesn't have moddable easy-editable image resource format, like bmp maps (similar to used in ufotts, including "converter").

Whats so hard about modding the original formats?

[Volutar]

luke83, ugly format, ugly tools, ugly palette. I don't see any problem to go into 320x200x24bit. There are no real commitments to stick to 256 color. It's possible even now.

[luke83]

Sooo , how would that affect the whole "Original Game Data" issue. If it used different format , you would then need to supply converted data, wouldn't that be a copyright issue?