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 - Bobit

Pages: [1] 2 3 ... 7
OpenXcom Extended / Re: [Documentation] Mana
« on: Today at 07:50:35 am »
Is there a percentage-based ruleset available for stat strings?

Currently, I want to mod into my X-Com files game stat strings for agents with Readiness (the mana resource in XCF) below 50%?

No there is not. Just assume your soldiers have the highest max readiness, then you will only get false negatives.

OpenXcom Extended / Re: [Suggestion] New Modscript functionality
« on: February 26, 2020, 06:00:42 pm »
The answer is going to be no, you're asking the scripts to access too many variables like Inventory and Facing. Here are some alternatives with a similar gameplay effect:

Simply increase armor penetration on weapons that require high accuracy to be used effectively. Most games and mods do this.

A pump action weapon, that is a weapon that is easy to reload the first time but hard to reload the sixth, is implemented using a quickdraw slot. Increase inventory movement costs, then make a slot which has very low inventory costs when moving to the hand, but is only 1 row high. Then make all ammo that you want to be easy to reload the first time but hard to reload later 1 row high, and all other ammo 2 rows high. In the popular mods these tend to be weapons like Shurikens which are easy to reload the first few times, while Crossbows have a very difficult time reloading. You're surely already aware of this technique, but it can be further emphasized by increasing costs and making frequent 2-row ammo.

Suggestions / Re: Non-random RNG (Seeding)
« on: February 08, 2020, 08:22:41 pm »
In many mods it is optimal to evacuate shortly after leaving the skyranger if the enemies spawned right next to you. It's a good mechanic, not a reason to break ironman.

OpenXcom Extended / 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".

OpenXcom Extended / Re: Light cover fork
« on: February 05, 2020, 11:09:06 pm »
One line out of tens of thousands, but okay... ty for consideration...

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

OpenXcom Extended / 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.

OpenXcom Extended / 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.

OpenXcom Extended / 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.

OpenXcom Extended / 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.

OpenXcom Extended / 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.

OpenXcom Extended / 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).

OpenXcom Extended / 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.

OpenXcom Extended / 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?

OpenXcom Extended / Light cover fork
« on: February 02, 2020, 02:26:45 am »
Hello, I have made a fork of the most recent OXCE release which should implement cover.

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.

Pages: [1] 2 3 ... 7