[OLD] Old OXCE discussion thread

[Yankes]

A small bug report... which is not even a bug... but a different side-effect than in vanilla.

When using GIF transparency (on an index different than 0), OXC can still somehow render it transparent, even though it isn't explicitly coded that way.

In OXCE, the "script blit" cannot do that anymore... so mods, which use this "side effect" don't work in OXCE, even though they somehow work in OXC.
The recommendation of course, is to use proper images... but, could you have a look if it would be easy to change the "script blit" to behave the same way?

Attached is a minimod to test it and two screenshots with more explanation.

One easy way to fix it is add script that will ignore 255 value, in may contexts you have value of background color, and instead of drawing new pixel we will draw background again making this effective transparent.
And for not work around solution, no. SDL can this because It create mapping between src and dest palettes. My blit do only 0 check (except for version that run custom scripts per pixel, but this is only when you ask for this). I would need recreate all SDL logic and with this overhead that it will bring.

[Meridian]

One easy way to fix it is add script that will ignore 255 value, in may contexts you have value of background color, and instead of drawing new pixel we will draw background again making this effective transparent.

Not worth it.
Each image can have transparent color on a different index.
And converting the image is a nicer, more robust and only official solution anyway.

And for not work around solution, no. SDL can this because It create mapping between src and dest palettes. My blit do only 0 check (except for version that run custom scripts per pixel, but this is only when you ask for this). I would need recreate all SDL logic and with this overhead that it will bring.

That's what I wanted to hear.
Thanks.
Now I can sleep well

[kikimoristan]

I'm working on the transifex Romanian translation right now. I'm a bit over 50% done

[Meridian]

@Yankes: while doing a "ruleset viewer" I noticed something I don't understand, see attached pictures

Is it intended or just forgotten?

[Yankes]

`-1` mean "use parent action" for rest of resorces costs. To get correct you should use getter function that replace `-1` with correct value.

[Meridian]

`-1` mean "use parent action" for rest of resorces costs. To get correct you should use getter function that replace `-1` with correct value.

But why is Aimed a parent of Auto and Snap?
Doesn't make any sense to me...

[Yankes]

But why is Aimed a parent of Auto and Snap?
Doesn't make any sense to me...

Idea was that modder usually wanted only tweak TU and rest of "cost" leave same for all "shoot" attacks. Same logic as I did for psi attacks.

[kikimoristan]

I have completed the Romanian translation for OpenXCom Extended.

I could not translate this "{N} of us are still fatally wounded" seems it has an issue between different spellings and won't let me provide a translation.

[Yankes]

I have completed the Romanian translation for OpenXCom Extended.

I could not translate this "{N} of us are still fatally wounded" seems it has an issue between different spellings and won't let me provide a translation.

I do not remember adding use of this string in OXCE, didn't you use OXCE+? If yes then you should post this in Meridian thread.

[Meridian]

One more observation Yankes:

When a weapon is defined like this:

Code: [Select]

  - type: STR_RIFLE
    battleType: 1
    compatibleAmmo:
      - STR_RIFLE_CLIP

... it gets the default damageType DT_NONE... but its attributes are different compared to the _damageTypes.at(DT_NONE)... i.e. the default templates


The questions are:
- Why did you add those extra rules for DT_NONE in Mod.cpp (see screenshot)?
- Do they serve any specific purpose?
- Are they the same in vanilla?

[Yankes]

Indeed, my bug, I tried to be more papal than the pope. Probably only correct way is to remove them because now behavior is inconsistent.

[Meridian]

Indeed, my bug, I tried to be more papal than the pope. Probably only correct way is to remove them because now behavior is inconsistent.

OK, thanks.

Done here: https://github.com/MeridianOXC/OpenXcom/commit/d3dcd52c430095ca9d6ce4488d6d936733243ced

[Yankes]

This is already done years ago, each item can have it own damage type that behave different. Addition there are 10 more resist types added by Meridian.

[Meridian]

@Yankes:

should getFlatUse() be used in Ufopedia?
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Ufopaedia/ArticleStateItem.cpp#L104

maybe use getFlatAimed(), getFlatSnap() and getFlatAuto() instead?

[Yankes]

Yes,
I see you did lot of check lately, what do you work on right now? This is some kind ruleset "dump"?