Gijs-Jan
-
Posts
330 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Events
Downloads
Posts posted by Gijs-Jan
-
-
The AI is about the only thing that needs changing at this point for me, the game feels really fantastic.
This is on the latest experimental branch? And it is primarily passivity?
-
It was a LONG time ago (1991). We were writing in Turbo Pascal 6. At the time, none of us knew anything about "MersenneTwister" or anything else like. We just knew the Turbo Pascal random function wasn't working right. There was no internet to do research and none of us had a math background. It's so much easier to find solutions these days!
Ah, fair enough!
Forget I said anything :-)
-
We actually encountered this problem on a game we did. The RNG tended to "roll" low numbers far too often if the RNG spread was multiplied by 100 or more (like 4x too often.) In our game "miracle" rolls were originally very low numbers. Such as a critical hit or lucky shot at extreme range. The solution was too "flip" the required rolls to the high side, so if something was only supposed to happen 1% of the time you had to roll a 99 or higher instead of a 1 or less.
Which is what I tried to express with the transforms remark. :-)
This is due to how some RNGs manipulate the bit representation of the number; which gets distorted if you discard sections of it in the transform. Anyway, if I have some spare time somewhere I'll take a look.
Other than that, our first hunch is still (if it exists) some problem in implementation. The way to showcase this is to present some save where we from our end can see the problem happen. :-)
Btw:
If you encountered this during game development, you should've probably switched your RNG implementation.
(Previous iterations of Java's Random were notorious with skewed random results.)
IMHO; I always use MersenneTwister; making all points moot. (I need "better" RNG for most of my AI implementations, as they are academic)
-
I was reading the reports of frequent misses and was wondering about the quality of the RNG, and this confirmed my suspicions.
The default RNG that ships with most C/C++ standard libraries isn't actually all that good, and it's prone to streams of numbers that actually aren't all that random.
There are some tests you can run on a RNG to measure the quality, but I'd just suggest that you get an implementation of a Mersenne Twister and start using that. If the RNG was the source of the problem, it will just go away, and we get a more reliable death distribution for our soldiers
This is true for "heavy" (Cryptography, some AI techniques) usecases of psuedo randomness. I myself always roll my own RNG based on Mersenne Twister for any and all non-trivial use, however this really shouldn't be a problem for the accuracy calculation in Xenonauts.
If something is wrong, it will most likely be through the use or transformation of the output of the RNG.
-
I have to second this. During a "test" save I have (not on stream, so no video proof), I was clearing a cruiser. There were ZERO aliens outside of the alien craft, and the psychic alien kept spamming abilities. It wound up having one of my snipers shoot and kill the other sniper (who was in cover from the first sniper). They were both at full TUs watching the "middle" door as the rest of my squad (five and five) were sweeping the side wings.
This really shouldn't be happening, the only way the AI can use psionics on you is if you are visible by some alien, or if you don't move at all.
-
Thanks for the upload & the stream!
-
a xcom-like game with Chtulhu monsters instead of Aliens, pls Goldenbros, pls.
I'd almost work for free to make that game.
-
Drone Suppression is WAY TOO HIGH! My troops land on a terror mission. One light drone opens up on them before they are even two tiles from the Chinook. Suppresses all eight of them for the next three rounds just by firing in their general direction once per round. My troops cannot fire back at all due the reduction in TU and can barely move. They are all slaughtered before turn 4. Rage quit.
I strive to provide hours of enjoyment*.
*) suffering
But on a more realistic note, the aim should be fun. So I might tweak its behavior then.
-
I think he means Veteran is the "normal" 'cos AI accuracy is set to 1 whereas normal is only .75. Btw, G-J I love what you have done with the AI! It's really, really good. Keep up the phenomenal job!
Are you able to pull off AI using higher grounds? (I know the engine is a tough nut to crack...)Thanks, I'm probably going to spend next week on finding a solution to the matter.
-
Aaw... Teleporting civilians is a mood killer. Could it be toggleable?
I fought the alien, everything was ok but is retreated into fow. I followed it and found it inside the irrigator.
My bad, I phrased this incorrectly. Obviously civilian movement inside LOS should be visible.
-
Is this in V21 hotfix 1?
The reaper behavior should be fixed in this version.
-
Civilian movement has been turned off (For civilians outside LOS), because it saved a heck of a lot of waiting time which served little purpose.
I've witnessed the "move inside bug" as well, but thought it an issue with the map.
I'll look into it!
-
How about renaming the difficulties - very easy, easy, normal, veteran. It's the first game where on normal AI gets some negatives.
Could you explain "It's the first game where on normal AI gets some negatives." a bit? Do you mean the AI is too hard on normal?
-
Last weekend a set of fixes for the AI went in which should deal with the following:
- Better team coordination; help when under fire, etc.
- Better positioning; a bug in the pathfinding which excluded the target the AI was moving to which led to a host of issues actually.
- Aggressiveness; in approach and support. This is a bit experimental as I'll probably still have to tweak the values per race as to not make them all too aggressive.
- TU reservement; a bug in TU calculation needed to take a shot; which resulted in AI making plans where it would have exactly enough TU, then think it couldn't complete its last action.
- Better AI turn times; if AI is guaranteed to be out of sight, a lot of things will not animate anymore which decreased turn times dramastically.
-
I actually have 3 cases of it happening. All of them are during a terror attack on a city.
Thanks! I'll get right on it.
-
I'll take a look at this. I'll expose the weights through the aiconfig.xml file.
-
The passivity of the aliens should be fixed in the next release. The TU bug should be solved as well.
-
Tech. Info
v21 Experimental Build 4, balance update
Observed Behavior
Light drones are too passive, they don't fire unless right next to a target.
Desired Behavior
In line with their role as a supportive suppresion unit, they should always fire whenever possible, regardless of hit chance, and try to stay at long range
This should be fixed now.
-
Tech. Info
Xenonauts v21, experimental build 4 with balance update
Observed Behaviour
Aliens, "when anticipating the direction of possible attack", tend to face the direction where there is no cover regardless of Xenonaut placement. This tends to lead to defensive aliens facing away from door (of UFO etc.) allowing soldiers to walk up to the alien with no threat of reaction fire.
[ATTACH=CONFIG]2959[/ATTACH]
Green - direction of cover protection (and likely direction of Xenonaut attack)/ Red - alien face 90 degrees almost always regardless of situation
Such scenario occurs on open field also, where alien would be taking cover from group of Xenonauts, but instead of facing the group itself at end of turn, alien would face 90 degrees from the cover allowing Xenonauts to simply walk up to it.
Do you have a save of this behavior? As it should be already in the AI for quite some time and I was not able to reproduce it locally.
The behavior should be that a unit will look at the tile next to it nearest (through pathing) to an enemies known/estimated position.
-
Tech. Info
v21 Experimental Build 6
Observed Behavior
This is a new AI problem in the most recent version: Passive aliens defending an ufo move towards entering xenonauts into a good firing position but reserve all their TU's for reaction fire, thus beign easy targets for the player next turn. I've tested this now many times: At least both caesans and sebillians often move very close to, or adjacent to my units but don't shoot. Next turn if I don't kill them but move back and forth in front of them instead, they will reaction fire me 3-4 times, so they have indeed reserved their TU's from a clear shoot to kill situation.
This should be fixed in the next build; it was a bug in performance code which deals with storing the results of preconditions. It snuck in after the introduction of the Psionics behavior and should be fixed now.
-
The fix is in the latest beta. As always, if you find any discrepancies, please let us know!
-
The latest patch should severely reduce the turn time!
-
This should be fixed soon :-)
-
I hope you don't mind a question. Do you plan to implement AIs that always explore the map?
This was implemented under ProbabilisticSearch. However, I had to disable it as the AI was "cheating" according to some players, deducing where the player was while people thought it should be impossible to know.
I disabled it until I can deconstruct it to just a frontier-based search without the added knowledge.
Ground Combat Balance - V22 Experimental Build 1
in Xenonauts General Discussion
Posted
I've been reading through the posts, and I actually agree with both opinions.
Evidently, the more aggressive AI is being received well, it's the side effect (empty map) that's unwelcome.
I agree with kabill in the sense that the best way to solve it is to either add, or force some stragglers to remain behind.
I'll take a look at it and try to present an alternative to Chris.