[OLD] Old OXCE discussion thread

[Yankes]

Thanks for reports, last one probably should be fixed in `drawTarget` by replacing `blit` with function that will flip bits when draw.
This will allow adding `const` to `Surface *` because modifying this surface is not needed there (this is design error to require to modyfing shared data do draw anything). I will prepare some fix for this.

As you post some erros to fix, I will grab them and when I find some time publish new bugfix version.

[SIMON BAILIE]

Not a major glitch but a wee bit annoying, in the save attached I've mc'd the snakeman leader but it won't let me set waypoints to fire his blaster launcher?

[Meridian]

Not a major glitch but a wee bit annoying, in the save attached I've mc'd the snakeman leader but it won't let me set waypoints to fire his blaster launcher?

It's because aliens are not allowed to use explosives before turn 3

Small refactoring oversight, that can be easily fixed.
Here's the code: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/SavedBattleGame.cpp#L890

This

Code: [Select]

if (unit->getOriginalFaction() == FACTION_HOSTILE && getTurn() < rule->getAIUseDelay(getMod()))
should be changed to this

Code: [Select]

if (unit->getFaction() == FACTION_HOSTILE && getTurn() < rule->getAIUseDelay(getMod()))

Fix: https://github.com/MeridianOXC/OpenXcom/commit/68ec0b2b45fd5aa275b3cab3332869901d984b49

[SIMON BAILIE]

Testing out your latest oxce+(v3.10a of 06/01/18) I get this image when a ufo has landed. I have got the language as en-US. Is this right? The ufo in question is a supply ship for alien base 1.

[Meridian]

Testing out your latest oxce+(v3.10a of 06/01/18) I get this image when a ufo has landed. I have got the language as en-US. Is this right? The ufo in question is a supply ship for alien base 1.

There is a translation for this: https://github.com/MeridianOXC/OpenXcom/commit/3d80cbec3a5614326a0d911baa9382f2fb82afc1
You probably forgot to update the data files.
Updating only the EXE is not enough.

[ohartenstein23]

Hey Yankes, would you consider removing the validation checks on item costs for facilities here?  I feel like this is unnecessarily limiting modders and assuming only one type of facility refund. For example, in my mod I have a non-functional hangar in a starting base containing a crashed craft; I'd like to be able to remove it to gain back the damaged craft for repairs, but I found it non-intuitive that I needed to be the damaged craft as a build cost before the refund would work.

Edit: Meridian just wrote a commit to change this, if you'd like to use it.

[Yankes]

Ok, valid point. It could work other way, but build using X but as refund you get trash Y.
I will include this in next version.

[Ethereal]

bug in documentation, both UFO and XCrafts can modify `sightRange`, all things defined in `craftWeapons`->`stats` can be used in craft and ufo too (but some are not used).

E ... Ie, if set "sightRange" for a UFO, then can increase the distance and the probability of finding X-COM base?

[Yankes]

Range yes, chance no.

[Ethereal]

Range yes, chance no.

Can find out what is the default range? Is it the same for all UFOs? Maybe should enter this information in the "Readme"?

[Meridian]

Can find out what is the default range? Is it the same for all UFOs? Maybe should enter this information in the "Readme"?

It's the same as in vanilla, no need for readme if there's no change...

[ohartenstein23]

Hi Yankes, after having a discussion with Hobbes about using craft weapon stat bonuses to create external fuel tanks, I came to the realization that removing such an item when the craft is fully fueled, you will lose that extra fuel; this means loss of an item if the craft uses E-115 or some other item to refuel. Could this be changed such that extra fuel would be returned as an item, as long as it is equal to at least the refuelRate of the craft?

[Yankes]

Hi Yankes, after having a discussion with Hobbes about using craft weapon stat bonuses to create external fuel tanks, I came to the realization that removing such an item when the craft is fully fueled, you will lose that extra fuel; this means loss of an item if the craft uses E-115 or some other item to refuel. Could this be changed such that extra fuel would be returned as an item, as long as it is equal to at least the refuelRate of the craft?

There is already code for this:

Code: [Select]

int overflowFuel = _fuel - _stats.fuelMax;
if (overflowFuel > 0 && !_rules->getRefuelItem().empty())
{
_base->getStorageItems()->addItem(_rules->getRefuelItem(), overflowFuel / _rules->getRefuelRate());
}
setFuel(_fuel);


[Meridian]

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.

[Solarius Scorch]

Well that's even terrible for everyone who use OXCE+. Sad news for me. 


I'll wait for future updates to fix it then, that way transparency problems go away.

Or just don't use gif, use png. Gif has other issues anyway. And if you really want to use gifs, make transparent background transparent instead of green or whatever people use.