[OLD] Old OXCE discussion thread

[Meridian]

Yes,

Fixed here: https://github.com/MeridianOXC/OpenXcom/commit/c20fbbc170f0bc568bf4c6921edbc8b846bffbb6

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

Yes, it's a ufopedia extension for nerds who need to know all numbers... so that the modders don't have to write themselves to death.

[kikimoristan]

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.

Is there . I asked in discord they told me is because the string has a correction so I had to translate both the correct and wrong string in order to be approved

[ohartenstein23]

Hi Yankes, I'm having trouble with the multiple ammo slots code - I'd like to be able to have two different ammo slots use the same ammunition type, such that I can simulate having to load two different 'chambers' of a weapon separately.  However, whenever I set two slots to use the same ammo type, only one will be loaded unless it has a second compatible ammo type to be loaded in it.  For example, in the following code snippet, a player would never be able to fire the aimed shot of the rifle because ammo slot 1 will never be filled with a rifle clip:

Code: [Select]

items:
  - type: STR_RIFLE
    ammo:
      0:
        compatibleAmmo: [STR_RIFLE_CLIP]
      1:
        compatibleAmmo: [STR_RIFLE_CLIP]
    confAimed:
      ammoSlot: 1

Is there a way around this?

[Yankes]

no, this functionality was designed to only work with different ammo types per slot. It will be hard to remove because in multiple of places logic really on this.

[Meridian]

Hi Yankes,

I'm trying to understand the functionality in the attachment... and I just can't understand it no matter how long I look at it.

How is "damage >= type->SmokeThreshold * 2" equivalent to "type->SmokeThreshold == 0" ??

And why not just use "type->SmokeThreshold == 0" ? Why instead doing multiplication by two and comparing it with damage??

[Yankes]

Code is ok, comments are special case.
This code cap effect when its lot larger than threshold.

Example:

Damage = 50, Threshold = 100 -> 0% smoke
Damage = 101, Threshold = 100 -> 1% smoke
Damage = 200, Threshold = 100 -> 100% smoke
Damage = 300, Threshold = 100 -> 100% smoke
Damage = 5, Threshold = 0 -> 100% smoke

[Meridian]

Hi again Yankes,

am I right if I say that methods fireWeapon1() .. fireWeapon4() are not used anywhere and can be removed?
I would "need" to remove them to merge some recent nightly fixes...

https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L1233

[Yankes]

Hi again Yankes,

am I right if I say that methods fireWeapon1() .. fireWeapon4() are not used anywhere and can be removed?
I would "need" to remove them to merge some recent nightly fixes...

https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L1233

https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L960 (compare with master)
This was use place of this, probably after couple of refactoring I forget remove them.

[Meridian]

OK, one more "merge" thing... for about a year, the animation of bigger units is broken... I think I found the reason, but I am not sure:

I think that this commit was not merged properly: https://github.com/SupSuper/OpenXcom/commit/5a363721372e3818d56008f2f8be73c1ae86d254

There was an attempt to fix it: https://github.com/Yankes/OpenXcom/commit/64168e2befa7cf249cf9b549405ce5bef05d88f8

But it only fixed it partially.

I think that
getTerrainLevel(westUnit->getPosition(), westUnit->getArmor()->getSize())
needs to be removed completely, because it is (probably) done in
calculateWalkingOffset(westUnit, &offset);
already

Would you agree?

In attachment, you can see the visual manifestation of the issue.

[Yankes]

Yes, exactly.

[ohartenstein23]

Hey Yankes, I've noticed that newTurnUnit now runs on civilian 'turns' during terror site missions - was it always this way? This means that scripts I expect to run twice per player turn run three times for terror missions, which ruins any balance that depends on these scripts. Is there any way to get the faction of a unit with createUnit and newTurnUnit?  I can use that to determine whether civilian units are on the map and therefore have to change the newTurnUnit logic to match.

Edit: Oh, is this what the purpose of the 'side' variable in newTurnUnit is?  It returns a value equal to which side's turn is starting, with 0 = X-Com, 1 = Aliens, 2 = Civilians?

[Yankes]

Yes. this mean you can run some code only on one side "end turn".

[Ethereal]

People, it may be time to think of something, what would speed up the load \ save? Save file grew to 5 megabytes (half of this volume is occupied by soldiers' statistics) and it loads for a very long time. Need to somehow speed up the load of large files.
5 megabytes! And this is the middle of the game and the end is not even visible with binoculars. That is it is visible, but it more likely the end of an admissible volume of the loaded information from a file of saving. It can be divided him into 2 or 3 parts?

[Meridian]

You can disable soldier diaries in options.cfg, just set:

Code: [Select]

  soldierDiaries: false

Btw. it's not about the size of the file, splitting it into multiple parts won't help.

[Ethereal]

You can disable soldier diaries in options.cfg, just set:

Code: [Select]

  soldierDiaries: false


We have already discussed this. Without statistics, half the interest in the game is lost.

Btw. it's not about the size of the file, splitting it into multiple parts won't help.

Will help. If all the statistics are moved to a separate file, which is loaded only when the player turns to the statistics. That's why in combat is loaded, all the statistics?  In battle, there is a buffer, where all the actions of soldiers are recorded, which can be entered after the battle into the statistics file, instead of loading the whole array of statistics every time, which is not used at all and just increases the time load\save in combat.