Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Player701

Pages: [1] 2 3
1
I see. I guess this is a classic example of "too much effort for too little gain", then. Well, at least I've re-reported the issue properly (in its own thread), so now there is less chance to forget about it.

2
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...

3
Well, I did test it in OpenXcom of course. I suppose it'll work in OXCE too, if there haven't been any significant changes to that part of code.

4
2/ As for selecting next soldier... it is actually selecting previous soldier, not next :) Can also be fixed by assigning a hotkey to that action (by default the hotkey is empty in OXCE)

Yes, I already got that. However, assigning every unassigned action to something is a workaround and not an actual fix. I hope it can eventually be fixed for real. (and if for some reason it doesn't, maybe I'll even try to do that myself - just have to stop being lazy and take some time to set up the development environment again)

UPD: Here's my attempt to fix this: PR upstream

UPD2: The PR has been merged. Thanks to everyone who replied in this thread!

5
Reported as #1481.

It seems that the Markdown parser on the bug tracker doesn't work for some reason. Doesn't look like it's been getting much attention lately... I hope the developers still use it.

6
I just disabled ALL shortcuts in Options -> Controls, and now Fn combos and my volume control do some really weird stuff. During a battle, it ended the current turn, opened the options menu, prompted me to abort the mission, and also brought up the firing modes menu for the selected soldier's weapon - and all of this happened at the same time.

It appears that this bug triggers when a shortcut is unset. In my preferred configuration, I did disable the night vision shortcuts (never needed it before, so I disabled it to avoid messing with it accidentally) - that's why it turns on with my config file but not with the default one. "Select Previous Unit" is unbound by default, and I haven''t touched it. If I bind it to anything, it no longer activates when I use the Fn key or the volume control.

In OpenXcom, "Select Previous Unit" is bound by default, that's why the bug doesn't happen there. But if I unbind it, it starts triggering to. So this is actually an issue from upstream, it seems.

7
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).

8
Open Feedback / Re: UFO navigation tables exploding
« on: March 26, 2020, 07:29:41 am »
Okay, if you are sure about it then I guess there's no bug in OpenXcom. Than you very much :)

9
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.

10
Open Feedback / Re: Problem with the bug tracker
« on: March 20, 2020, 10:43:51 pm »
Oh, I see. I have now been able to restore my password and log in. Thanks for your help! I've bumped an old bug there, although it doesn't seem to show up in the recent activity log, so maybe I should open a new one instead... It's nothing game-breaking, but it can be annoying at times.

Edit: seems to show up now, everything's OK. Thanks again

11
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.

12
OXCE Builds & Ports / Re: OXCE v6.3.4 for Android
« on: February 14, 2020, 11:23:38 pm »
Thanks, I guess I'll try it out if there's no other way right now... but the requirement to use third-party apps to gain access to some of the game's features is just plain wrong.  :-\

13
OXCE Builds & Ports / Re: OXCE v6.3.4 for Android
« on: February 14, 2020, 07:26:59 pm »
    Hi again! I've been running the Android version for a few days, everything seems to be ok so far, no crashes! Thank you very much, please keep up the good work!  ;)

    I have run into a couple issues though:

    • MIDI music doesn't work for some reason (can't use a mod with custom MIDIs :( ).
    • There doesn't seem to be any support for features that require to press and hold a certain key in the desktop version (e.g. Ctrl to ignore line of fire).

    Sorry if those issues have already been brought up before; I couldn't help but mention them since they are rather easy to notice. I'd be happy to see them addressed somehow in a later version.

    Thanks again. :)

14
Suggestions / Re: Monthly rating / statistics issues
« on: August 17, 2018, 03:55:24 pm »
Thank you for you input.

I can see your code is heavily changed compared to the original version, so I'm not sure if it would help me much with analyzing the master branch. I can clearly see, however, that in your version the research bonus is indeed applied after all the countries' data has been updated, so perhaps issue #2 is indeed valid.

I'm not so fond of proposing more fundamental changes, because I usually try to follow the pricinple: "if it ain't broke, don't fix it". I usually try to take note of any suspicious behavior I observe during my playthroughs and attempt to reproduce it reliably, then try to find the part in the code which causes it and then make a report / PR (though my interest in the game is usually seasonal / periodic, and I may not always be active).

In this case, I initially noticed that the "average monthly rating" value displayed when I won the game was clearly wrong, and further investigation revealed several other potential bugs / inconsistencies which I thought I would report in one post instead of filing separate issues on the bug tracker, because: a) the forums seem to be more popular than the bug tracker, and b) the affected parts in the code are more or less closely related to each other.

Regarding totals for statistics: ignoring the current month is possible, but then what should the game display if the campaign is won / lost in less than a month? Technically, it is possible to do (perhaps not without the use of mods / cheating), so this should also be accounted for. 0 could be used as a fallback value, but this will probably look a little weird (especially since other kinds of data for the current month is not discarded).

15
Open Feedback / Re: UFO_170.map and the universal patch
« on: August 14, 2018, 11:15:08 pm »
I am not experiencing the issue. I can confirm that the map file I am using for the supply ship does have the hole (seen in MapView), but does not have the hole present in-game (unable to fly up).

Versions tested:
OXC Nightly 2017/11/09
OXCE+ 3.10b 2018/07/21

It is indeed not possible to glitch through the UFO hull using this hole; perhaps OpenXcom fixes the behavior so that flying up into objects is not possible. However, shooting through the hole is still possible. Try aiming at the tile below the one highlighted on the attached screenshot, while standing at the same place where the soldier is. Most of the time the shot will hit the UFO floor (guess this is due to rookie's low firing accuracy), but sometimes it will pass through to the ground. There certainly is a valid line of fire there, which can and will be used by aliens provided they are in the right position. I have experienced this several times during supply ship assaults.

Pages: [1] 2 3