Messages

91

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 06, 2020, 05:57:02 am »

I've already said the code is useless. 90% of it is the "artificial" implementation and the remainder you can figure out yourself. I have not been talking about more than a single line of code, for a long time. But you didn't understand when I told you that, and didn't want it clarified.

Just letting modders set the global variable on line 416, and even all the maintenance needed for it, is far, far less work than you've already done in responding to me.

I'm not responding anymore. This topic needs to die. At this point it is purely about "saving face".

92

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 05, 2020, 11:09:06 pm »

One line out of tens of thousands, but okay... ty for consideration...

93

Offtopic / Re: XCOM Inspired Fantasy Game

« on: February 05, 2020, 08:29:07 am »

Yeah I clearly jumped into a conversation without reading the context lol

94

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 05, 2020, 01:59:43 am »

Just let modders control the global variable on line 416. No extra formulas, they can just give a flat value for the integer. That's sufficient.

95

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 04, 2020, 09:27:59 pm »

The helper function is 90% of what I want.

I suggest using the helper function in setupEscape() (AI prefers to escape to partially obscured positions), in findFirePoint() (AI prefers not to shoot at enemies which are partially obscured), and player UFOextender accuracy prediction. But you can probably figure that out yourself, so ignore this paragraph if you don't understand it.

However, I suspect that the helper function will tell you that partial cover is awkward in vanilla. This is because of the code in src/Battlescape/Projectile/applyAccuracy(), the way in which accuracy is converted to deviation on lines 411-416, means that only the cover in the very small 10 deviation cone when you roll a hit has any impact.  The few times that the 10 deviation cone is partially obscured, it's likely to obscure it by something like 50%.

This is why I suggest allowing modders control over the formula used in lines 411-422. The modders could do things like:

• Make rolled misses always miss (no 100% hit chance with a sniper rifle point blank range), by changing lines 420-422 to have 40 guaranteed deviation when missing, rather than possibly having 0 deviation.
• Make rolled hits always hit (and partial cover is totally ignored) by decreasing hit deviation on line 416 to 0.
• Make partial cover more relevant and less binary by setting hit deviation on line 416 to 20, or to 10-50 depending on how high your roll was.

Also, a helper function which shows hit chance considering cover is good. But a helper function which shows hit chance considering cover, the fact that rolled misses sometimes hit in close range, and the fact that rolled hits sometimes miss because the target is so small or the shooter so far away, would be the best. But probably too hard to code.

If you still don't understand what I'm saying, and still want to, we could schedule a live text chat.

96

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 04, 2020, 02:58:53 am »

Ignore the artificial thing then. Correct me if I'm wrong, but you seem interested in adding the approximation function, which is good for vanilla. If you do that, "subverting the functions" would be as simple as letting modders change the (accuracyRoll->deviation) formula, so not much reason not to do it.

97

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 03, 2020, 01:34:24 am »

Rubber, I agree in general. I did implement two things to counteract some of your concerns: certain weapons like grenades cause the AI to ignore cover, and cover is only considered when escaping into cover or firing at enemies in cover. It could be a complex problem, idk because I don't know the math, or we can just simulate it 1000 times every time the want to shoot if that somehow doesn't lag. It is a LOT simpler if using the "artificial" method I already implemented, but that method won't get much support among the project leads.

98

OXCE Suggestions Rejected / Re: [question] Is multifoor basescape possible?

« on: February 02, 2020, 10:46:20 pm »

It would be easy to implement using an engine modification. But it seems almost mechanically identical to just having more bases, just a thematic difference.

99

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 02, 2020, 09:43:24 pm »

Yankes, plz keep responding. What I want to do is b)Teach AI to avoid obstacles when shooting and maybe when moving. It is my opinion that the best way to do this is the following:

• When in setupEscape(), the AI will consider enemy units against which it has cover as only a fraction of a spotter.
• When in findFirePoint(), the AI will prefer not to shoot at targets it is unlikely to hit.
• For the player's convenience, UFOextender accuracy should show the chance that the shot will actually hit. Otherwise, a realistic partial cover system will just be confusing as you have no idea how good cover is.

I consider all three elements of this essential to a decent realistic partial cover system. They are all fairly easy to implement, but in all three I am missing one key component: a function which determines a shot's actual chance to hit. The key is surely in applyAccuracy(), but I don't understand the math in applyAccuracy(), so that's where I need your help. I can implement everything else and give you the tools to balance it further.

Imo vanilla hit deviation isn't big enough for partial cover to matter (do some tests in debug mode if you like), and that's why the AI works well without understanding partial cover at all: it doesn't matter. But vanilla should stay vanilla. Which is why I also suggest allowing modders to add hit deviation between 10-50, but that is a secondary concern and pretty trivial to implement, albeit possibly difficult to balance.

------------------------------------------------------------------------------------------------------------------------------------------

The difficulty of that final component is the main reason I originally went with the "artificial" method. If the function is impossible to implement, I would like to resume my work on the "artificial" method, because having artificial cover is better than the vanilla approach of having almost no partial cover. At least as a modding option, assuming it doesn't cause glitches in the engine. However that won't mean much if it's a separate fork that never gets updated while the main branch gets all the updates, so I won't do it unless there's a chance it will be merged into the main branch.Also keep in mind that the "artificial" method is used by FiraxisCOM and Xenonauts, but the "realistic" method has only successfully been implemented by Phoenix Point. 96COM  and by extension OpenXCOM does not really have partial cover, so it gets away without the AI knowing about it. So if you can't implement the "realistic" method of accuracy prediction, please support my attempt to implement the "artificial" method by merging it once it is complete (if it is not buggy).

100

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 02, 2020, 06:23:57 pm »

Yankes, I can implement the other more "realistic" method of cover which you implicitly mention and I call "Realphyzek" if you want. Basically just make the deviation more of a spectrum from 0-150 instead of that sudden jump from 10 deviation when you roll a hit to 50 when you roll a miss.

However I would need a formula for efficiently predicting accuracy considering cover. Right now all I can think of for Realphyzek accuracy prediction is simulation by shooting 10-1000 rays and seeing what hits each time the player/AI asks for a prediction. I don't understand the projectile math in calculateTrajectory/applyAccuracy enough to figure it out mathematically; part of that code says "don't ask" so I would really need your help.


TLDR: give me an accuracy prediction formula that considers realistic cover and I will implement realistic cover.

I have seen a graphic that shows the spread so a formula probably exists...?

Alternatively I could work on making it "not look like a force shield", but that's not what I would prefer.

101

OXCE Suggestions Rejected / Re: Light cover fork

« on: February 02, 2020, 03:24:55 am »

Hm. That will take some work to fix I guess.

Will this maybe get accepted into mainline OXCE if I fix/finish it? And even if it does, will people use it?

102

OXCE Suggestions Rejected / [Rejected] "NuCom" cover mechanics

« on: February 02, 2020, 02:26:45 am »

Rejection reason: this is beyond/outside the scope of OXCE


Hello, I have made a fork of the most recent OXCE release which should implement cover.

https://github.com/InfuriatedBrute/OpenXcom

All the code  is "done", but it is completely untested and uncompiled. But there's no harm in announcing early...? Not sure if this is the right forum either.

It works as follows:

• If no mods manually enable its features, it will not do anything.
• If a unit shoots and hits another unit, and the attacker's weapon has ignoreCover = false, and the defender has takesCover = true, then the projectile has a %chance equal to the (unused) LightCover value on the MCD of the corresponding wall adjacent to the defender to hit that wall instead. Even though it otherwise would hit the defender.
• The AI accounts for this by considering enemies against which it has cover less of a threat when deciding where to flee to, and by preferring flanking shots.
• UFOextender also accounts for this by adjusting the shown accuracy value.

Known problems are as follows:

• When cover works, it will look like the unit was hit because the projectile is adjusted at the moment it is hit. I often find it difficult to see whether a unit was hit anyways, so maybe there should be a way to display text saying whether it was hit or not?
• UFOextender accuracy always considers the cover value, even if the target cannot take cover. Arguably this is good.
• The AI will prefer cover, but that remains true even if you could easily flank it. The logic for changing this would be pretty complicated and it might be hard to tune how close should be considered a distance at  which the player could "easily flank" the AI. Also I simply forgot to do this.
• It's difficult to enable. You have to set almost every unit to takeCover and almost every weapon to not ignoreCover. Then you have to adjust all wall MCDs to their appropriate cover values.
• It does not consider elevation (z-values). Arguably good.

103

Offtopic / Re: XCOM Inspired Fantasy Game

« on: February 01, 2020, 06:46:41 pm »

Solarius, hidden information is randomness. If two players play The Prisoner's Dilemma or  something like that, optimal play for them is to do something X% of the time and another thing X% of the time. Which may not seem like a big deal but in complex games (Stratego maybe for example, though as a mainstream board game it's not great) it leads to pretty much the same randomness as true randomness. Starcraft therefore has at least a small amount of randomness just due to fog of war.

I mean obviously no one's smart enough to solve Chess so it still has diversity. And even if Soccer/Football and Starcraft/Dota were "solvable", it would depend on a person's capabilities and skills at different aspects of the game, which is pretty realistic.

However, turn-based single-player games are much better off with "true" randomness, if only AI randomness unless they are handcrafted puzzle games, but I think those get boring after a few hours.

Also, physicists tend to take positions that are helpful to them and look pretty harmless, like Schrodinger's Cat being taken as serious evidence that two impossible things are true at the same time rather than simply not being able to know which one is true, but are philosophically very impactful. Though I don't want to dig further on that in this board.

104

Suggestions / Re: Should the AI consider enemy range and partial cover?

« on: February 01, 2020, 07:29:25 am »

Really? That is interesting. Of course if the melee attacker doesn't flee, the spotter will likely turn around and see him anyways. But repeatedly backstabbing an enemy then fleeing seems, in a very rare situation, completely broken.

105

Suggestions / Re: Should the AI consider enemy range and partial cover?

« on: February 01, 2020, 06:21:59 am »

Hm, I forgot that high spotter has an effect similar to intelligence. I would still hold that spotter = 1 is what the player gets though.

Letting AI shoot the enemy who shot them is bad, but because spotting is binary, the only alternative is to not let the AI know they were hit at all.