Topics

1

OXCE Bugs FIXED / [FIXED] Weapon graphic/ammo counter visibility inconsistency

« on: April 06, 2020, 02:14:02 pm »

I remember reporting this in the main thread, but it was probably lost in the sea of replies. I therefore have no idea if this issue was ever looked at. It's very minor, but it is definitely OXCE exclusive, the latest OpenXcom nightly does not have it.

Compare the behavior of the bottom panel (is there a canonical name for it?) between OpenXcom and OXCE when firing a weapon on the battlescape:

OpenXcom: During the first shot, the entire panel is cleared - no soldier name, TUs, energy, health, morale, rank icon, or weapons are visible. When the projectile hits, the panel is fully restored. In case of auto-fire, the panel's state does not change at all on subsequent shots.

OXCE: During the first shot, the entire panel is cleared, like in OpenXcom. When the first projectile hits, the ammo counters and the green "2"s (indicating 2-handed weapons) reappear, but everything else stays hidden. If there are no more shots to be made, the normal state of the panel is restored shortly afterwards. Otherwise, on each subsequent shot, the panel shows everything except the weapon graphics (ammo counters and 2-hand indicators are missing as well). When a subsequent shot hits, the panel's normal state is restored. If there is another projectile to be shot, the weapons disappear again.

I don't really care that the sequence of events differs from OpenXcom, but whatever's going on here seems to lack consistency. IMO, the panel should either be completely empty or completely full, otherwise it looks weird. But I guess not everyone might notice...

[Spoiler]

2

OXCE Bugs FIXED / [FIXED] Fn key combinations cause OXCE to cycle through units

« on: March 28, 2020, 04:53:28 pm »

I'm reporting this in a separate thread so that there is less chance for my report to get lost within the main thread.

My keyboard has an Fn key which, combined with the various F-keys in the upper row, can perform a variety of actions (controlling volume, media playback etc). For some reason, when I use such a key combination, it also causes OXCE to select the next unit on the battlescape. This happens even with the default configuration settings (I deleted my OpenXcom folder in Documents to verify the bug).

In addition, with my configuration file, each time I use an Fn key combo, the whole battlescape suddenly acquires a weird green tint (sorry, I have no idea what this is supposed to be - see screenshot). When I use such a key combo again (not necessarily the one I used just before), the tint disappears.

Spoiler:

Also, I have a separate USB volume control with a big knob, and it also cycles through units each time I use it. But all this weirdness only seems to happen on my desktop PC and not on my laptop for some reason. I can provide detailed system information if necessary. My OS is Windows 10 x64, on both PCs.

The bug does not happen in OpenXcom nightly openxcom_git_master_2020_03_27_1613, only in OXCE (6.4.2 tested).

3

Open Feedback / UFO navigation tables exploding

« on: March 25, 2020, 11:00:46 pm »

Hello again.

It's been far too long since I played the original version, so it could be that my memory is failing me. But I don't remember UFO navigation tables (NOT wall-mounted nav computers - see screenshot below for reference) exploding in the original:



I certainly do remember them exploding in alien bases, but those are special since they constitute the "alien base control" objective necessary to destroy the base itself. But I don't recall these tables exhibiting explosive behavior in alien ships; however, this is exactly the case for OpenXcom/OXCE.

I wonder if anyone around here still has the DOS/CE version installed, along with some old save files... in this case I will greatly appreciate if someone could help me confirm or deny my suspicions.

4

Open Feedback / Problem with the bug tracker

« on: March 20, 2020, 10:02:29 pm »

Hey there.

I guess this project is still being worked on, which is nice. But it seems that I'm having some problems accessing the bug tracker. For example, when I attempt to log in, I receive a popup message saying "You are not allowed to access this page". It also seems that I cannot download files attached to certain reports (getting an error page instead).

I can't find any other place suitable for reporting bugs... the repository on Github does not have an issues tab. I wish someone could tell me where I can report issues so that they can be investigated whenever possible.

Thank you very much.

[Spoiler]

5

Suggestions / Monthly rating / statistics issues

« on: August 14, 2018, 02:27:08 pm »

UPD: this should probably be moved to "Contributions->Programming". Sorry, I was lazy to scroll the forums list down a little. 

I have found several issues with how some of the values in the statistics window (displayed at the end of the campaign) are calculated, as well as with the monthly rating calculation code. I would like to provide a breakdown of all issues discovered as well as to propose and discuss solutions to them. Please correct me if some of the assumptions I make here are wrong; since I have only worked with the source code for a short time, it is difficult to maintain a consistent picture of all things in my head.

I'm sorry making for such a long post; I thought it would be better to collect everything in one place because the affected parts of the code are closely related. I've added some spoiler tags to reduce the visible length of the post. I hope the developers can look into it when they have the time. I can also provide pull requests to implement the solutions proposed here. In the end, I hope we all can make OpenXcom better together

The first group of issues is related to MonthlyReportState.cpp, in particular, to MonthlyReportState::calculateChanges.

#1. Questionable piece of code in MonthlyReportState::calculateChanges
Description:

Spoiler:

The last two lines in this piece of code do not seem to have any purpose (Source: MonthlyReportState.cpp, line 335):

Code: [Select]

int lastMonthOffset = _game->getSavedGame()->getFundsList().size() - 3;
if (lastMonthOffset < 0)
lastMonthOffset += 2;

Here the game calculates the index to use in vectors which store the values necessary to compute the last month's rating. If this index ends up being negative, then 2 is added to the resulting value. Since the value returned by getFundsList() contains at least 2 values at this time (it is populated by one value at the start of the game and then with another value just before MonthlyReportState::calculateChanges is called), the check "lastMonthOffset < 0" is practically equivalent to "lastMonthOffset == -1". Therefore, lastMonthOffset will be equal to -1 + 2 = 1 if getFundsList() is 2 values long, which happens only at the end of the first game month.

However, the actual computation logic for the last month's rating is guarded by additional checks on the corresponding vectors' sizes:

When accounting for XCOM and alien activities (Source: MonthlyReportState.cpp, line 343):

Code: [Select]

if ((*k)->getActivityXcom().size() > 2)
_lastMonthsRating += (*k)->getActivityXcom().at(lastMonthOffset)-(*k)->getActivityAlien().at(lastMonthOffset);

When adding the research score (Source: MonthlyReportState.cpp, line 357):

Code: [Select]

if (_game->getSavedGame()->getResearchScores().size() > 2)
_lastMonthsRating += _game->getSavedGame()->getResearchScores().at(lastMonthOffset);

All these vectors - funds, XCOM activities, alien activities, and research scores - have the same size, because they are updated more or less at the same time (funds and research scores are updated in SavedGame::monthlyFunding, the other two are updated in MonthlyReportState::calculateChanges just before the rating is calculated). Therefore, adding 2 to lastMonthOffset if it ends up being negative does not serve any purpose at all - it will only end up negative if the size is 2, and if that is true, the "if" branches in the last two snippets will not be executed, effectively leaving the last month's rating at 0.

Proposed solution:

Spoiler:

Depends on what exactly should the last month's rating be equal to after the first month. In both cases, the last two lines in the first code snippet should be removed.

If the last month's rating at the end of the first month should be the same as the current month's rating, then calculate lastMonthOffset as follows:

Code: [Select]

int lastMonthOffset = std::max(0, _game->getSavedGame()->getFundsList().size() - 3);

Also, both "if" checks in the last two snippets above should be removed.

If the last month's rating at the end of the first month should be 0 (current behavior), then replace both "if" conditions in the last two snippets above with "lastMonthOffset >= 0".

#2. Possible oversight in MonthlyReportState::calculateChanges
Description:

Spoiler:

There is a comment in MonthlyReportState::calculateChanges which says (Source: MonthlyReportState, line 348):

Code: [Select]

// apply research bonus AFTER calculating our total, because this bonus applies to the council ONLY,
// and shouldn't influence each country's decision.

However, what the comment says seem to contradict what the code below actually does. Specifically, it passes the value of xcomTotal in a loop to Country::newMonth when sending the rating information to all countries (Source: MonthlyReportState, line 380):

Code: [Select]

(*k)->newMonth(xcomTotal, alienTotal, pactScore);

And note how xcomTotal is calculated (Source: MonthlyReportState, line 355):

Code: [Select]

xcomTotal = _game->getSavedGame()->getResearchScores().at(monthOffset) + xcomSubTotal;

xcomTotal includes the research score, which is in turn passed to all countries. However, the comment above says that the research bonus applies to the council only, and shouldn't influence each country's decision. This is probably an oversight.

Proposed solution:

Spoiler:

If what the code does is actually wrong, then pass the value of xcomSubTotal instead of xcomTotal when updating the data for the countries.

The next set of issues is related to the statistics window, which shows various statistical information to the player after the game has ended.

#3. Average monthly rating is incorrectly calculated based on research scores only

Description: See issue #1409 on the bug tracker.

Proposed solution: depends on the solution to the following issue #4. See below.

#4. Consequences of the limit on the number of values stored in certain vectors in the save file
Description:

Spoiler:

The total income and expenditure values are based on the data for the last 12 months only. This is because of how many individual values are stored in the save file, which is at most 12. This behavior is not a bug per se (it seems to be very much intended according to the comments in the code), but if the campaign has lasted for more than 12 months, then summing these values up will not result in the correct totals for the whole campaign. The same issue applies to various other values, including but not limited to: funds, research scores and XCOM and alien activity in regions and countries.

Proposed solution:

Spoiler:

There are at least two possible ways to solve this as well as #3.

• Store cumulative values for income, expenditure and monthly score in the save file. These values can be updated in MonthlyReportState::calculateChanges (monthly score) and / or SavedGame::monthlyFunding (income and expenditure). It is probably most consistent to update the corresponding cumulative value at the same time when calculating / pushing the normal value. Then, when calculating total income and total expenditure, the resulting cumulative values can be used. The current month should also be accounted for, since the cumulative values are only updated at the end of a game month. This means that for incomes / expenditures we need to also add the last values from the corresponding vectors to the respective cumulative values, and for the monthly score we have to calculate it based on the current research score as well as XCOM and alien activities in the current month.
• Lift the limit of 12 values to store in the corresponding vectors. For consistency, it would probably be best to lift this limit on all vectors where it is currently present. This will also necessitate some changes in GraphState.cpp so that only the last 12 values are used when calculating graph data. Then, when calculating total income and expenditure, no change of the current code is required. However, the monthly rating calculation will still need fixing to account for XCOM an alien activities in addition to research scores.

#5. Unused values in StatisticsState.cpp
Description: There are at least two values that are calculated but not used when displaying the statistics window. These are, respectively, the number of alien bases destroyed and the number of XCOM bases lost. They are calculated when iterating over the mission statistics vector (Source: StatisticsState.cpp, line 147):

Code: [Select]

if ((*i)->isAlienBase() && (*i)->success)
{
alienBasesDestroyed++;
}
if ((*i)->isBaseDefense() && !(*i)->success)
{
xcomBasesLost++;
}

Proposed solution: pull request.

6

Open Feedback / UFO_170.map and the universal patch

« on: August 05, 2018, 10:50:07 am »

Hi.

I've been playing XCOM 1 using OXCE+ and sometimes there have been cases where aliens on the second floor of the Supply Ship UFO can see my soldiers down below and shoot through the wall / floor. I thought it was an engine bug at first but then I found this and eventually it led me to this thread where people say the issue is fixed in the universal data patch provided here: https://openxcom.org/download/extras/universal-patch.zip. However, I have the patch installed and the issue is still present.

To quote the aforementioned thread, user hellrazor posted an attachment with the fixed UFO_170.map file and user Tarvis said:

Well, I don't know what to tell you. hellrazor's modified map file is identical to the one in the universal patch.

I just checked and this is not true. Even the size of the two files differs (attached is 9604 bytes long, the one which comes with the patch is 9603 bytes long). hellrazor's attached file does indeed seem to patch the "hole" in the UFO. If possible, could the maintainers of the patch update it with the fixed file? Thank you very much.

7

Open Feedback / Question about alien psi abilities and mind control

« on: August 14, 2016, 09:36:05 pm »

Hi.

I've been playing OpenXcom for about a week (not continuously, of course) with the purpose of having some fun and possibly finding a few bugs in the process (already reported some issues on the bug tracker).

I now have a question about using aliens' special abilities when they are under your control, which wasn't possible in the original game. Namely, psi abilities. For example, when I mind control an Ethereal, there is a "PSI" button in the upper right corner of the screen which allows me to make use of the Ethereal's psi skills. However, it seems that this button is only used to conduct panic attacks, and not mind control. Is it deliberately made impossible to mind control an alien with another alien without the use of a Psi-Amp, or am I just missing something? If it is the former, is there any explanation behind it? It seems perfectly logical to me that this option should be available.

Sorry if this has already been asked, forum search didn't yield any useful results.