[OLD] Old OXCE+ discussion thread

[Meridian]

Before I start looking into Quick Battle... you do agree with what I wrote before about Equip Craft (not in Quick Battle), right?

[robin]

I understand that if you start with more items than allowed in the craft, the game goes into negative to fix the total amount of items, so it matches the max available. Is it correct?
Anyway wait, let me page Solarius and Dioxine to see if they have the same behavior; if not, then it is on my end...

[Solarius Scorch]

Anything for you, man...
Indeed, there are strange effects. For example, right-clicking on the up arrow gave me... -10 rifles. ADDIND more decreased the negative number. What?
Also, non-soldier units (dogs) seem to occupy the ship. Even though they're soldiers, not HWPs.

Anything else you want me tested?

[Meridian]

In standard Equip Craft dialog or in Quick Battle; or both?

[robin]

In standard Equip Craft dialog or in Quick Battle; or both?

It happens (to me) in Equip Craft too.
I actually first noticed there, because I reached max items and I misclicked to add more, instead of removing them.
(Not trying to make you angry Meridian, I'm sorry if it seems so).

Anything else you want me tested?

Nothing, thanks!

[Dioxine]

I confirm (QB mode at least), something's very wrong. For me, L-clicking on a Longsword gave me -40 Longswords each click. L-clicking, not R-clicking, to be very clear.

[Meridian]

Fixed.
(I couldn't reproduce it, because the fix for scrolling issue already fixed it)

[Stoddard]

Hi.

The linux build farm unanimously choked on

Code: [Select]

Basescape/CraftEquipmentState.cpp: In member function ‘virtual void OpenXcom::CraftEquipmentState::init()’:
Basescape/CraftEquipmentState.cpp:238:10: error: second operand to the conditional operator is of type ‘void’, but the third operand is neither a throw-expression nor of type ‘void’
  _reload ? initList() : _reload = true;

this is https://github.com/MeridianOXC/OpenXcom/commit/192cd34179fc0d2e224721a0fd9b71f5dd4c0907

As for

every build reads "oxce3.5-plus-proto-<hash>-<date>-<os>.7z".

if it wasn't for the date and creation date of the file, I wouldn't know which one to pick, as the version number is the same for all. Maybe you didn't intend this.

"oxce3.5-plus-proto" is the name of the git branch, and thus isn't strictly bound to the version number. Sorry for the confusion.

EDIT: I'm open to suggestions re version naming. I can extract "Extended 3.7a+" or "3.7.0.0" or both from the sources and incorporate that into the name. What naming would be least confusing?

[sectopod]

@Stoddard
to me as an end user

Extended 3.6+
Extended 3.7+
Extended 3.7a+

looks more appealing. it is what everyone is using on the forum and it also is the same what it says in-game on the title screen.

[Stoddard]

I set it up this way for the trusty64 build.

When the code is fixed and actually builds, I'll set up the rest of the builds the same way.

[Meridian]

When the code is fixed and actually builds, I'll set up the rest of the builds the same way.

Try now pls.

[Stoddard]

Try now pls.

Builds ok now, thanks.


EDIT:

Ok, the build scripts were fixed to produce " Extended-3.7a+-3e78dbd-2017-03-20-xenial-x86_64.7z" and the like at https://lxnt.wtf/oxem/ .

Old stuff is in the 'Attic'.

[sectopod]

thanks from a linux user.

[Stoddard]

thanks from a linux user.

You're welcome. Please don't hesitate to PM me if something breaks.

[Solarius Scorch]

Meridian, would you be interested in adding a feature of random X-Com base names? I don't like coming up with names that much, plus it would be kinda fun to write the generator.

The only difference, game-wise, is that at building a new base, when you are prompted for name, there would be a string already - you can delete it or just press Enter. (Of course you can also rename the base late, like always.)