Messages

76

Tactics / Re: What are PHALANX supposed to be? I.D.I.O.T.S.?

« on: July 24, 2010, 10:22:43 pm »

Seriously what happened here?

We have an "elite" unit assembled by the earth governments to fight the aliens because the army couldn't do anything (wish i saw the army, can they even hold the rifle?).

You're actually sort of second-line, last resort folks, I gather -- basically the regular forces *lost*, so a previously decommissioned is being reconstituted under your leadership.

[quote
as alway i first start on very easy. expecting it to be more of a walk in the park. but my soldiers can't hit an alien unless they are basically point blank to them. while aliens can hit me from very far away. reaction fire is rubish. even if soldier kneels and doesn't move the alien keeps popping out shoot him and then goes back. what is this supposed to represent? what does this say about soldiers?[/quote]

RF triggering, at least judging from 2.4-dev code, depends upon (among other factors, such as visibility and having ammo, of course)
- the number of TUs that the target's action requires
- likelihood of hitting friendlies (under normal conditions, no more than 5% is acceptable, with freaked-out humans accepting a higher likelihood; but an insane alien will completely ignore the possibility of hitting other aliens; I've even seen one kill the alien standing right next to him)
- likelihood of hitting enemies (min. 30%)
- having a faster weapon (in terms of TU cost to fire) for the 'outdraw' test

The TU tests make it more difficult to RF against a fast shooter, e.g an alien with a plasma pistol.  Laser rifles are fairly useful for RF; they're pretty fast firing, are quite accurate (so more likely to pass the likelihood checks), and have good range and OK damage.

If you don't have laser rifles yet, you should probably consider making heavy use of IR goggles and the grenade launcher / rockets so you don't need good LOS, and also the flamethrower -- if you can get reasonably close with 12 TUs left, an Inferno blast is extremely lethal (one blast is modeled as  about 60 shots; each shot does modest damage, but...).  Very good for taking down individual aliens in modest-size rooms or hallways.

I move my best sniper guy to an average room length (using cover as much as i can). he is crouched, aimed shot- chance of hitting is 9%. move him a bit closer. ah now chance increases to 22%. seriously ? 22%?!? Sniper "expert", from Earth's best (on VERY EASY difficulty level)? I understand the need to make the game interesting. and the option to upgrade the soldiers. but if the soldiers are crapy so should be the aliens. i9nstead they can easilly hit my soldiers from across the whole map. 

I haven't really seen the aliens be crack shots.   With heavy lasers, laser rifles, sniper rifles and the nanocomposite armor I currently prefer to engage them at long range; the alien plasma weapons are pretty damaging but have significantly worse spread than the human weapons at that tech level.  The needlers and particle beam weapons seen a bit later are pretty nasty, but medikits make a huge difference between 'wounded' (which impacts accuracy, incidentally) and 'dead' so long as there's a little cover to hide behind. 

The odds computation is quite the approximation, and (presumably for reasons of computational cost) doesn't do something like, say, fire 50 imaginary shots using the actual firing code and see how many would hit.  It's dodgy where complex-shaped cover is around.  Move the camera view if you aren't sure.

some tips on how to proceed and if anyone knows if there is a way to fix the numbers in some file or something. because i got stuck on very easy on 3rd mission (&first terror site) with primary aliens (the orange suited guys). they just wiped out my whole squad (from their edge of the map and).

Don't rely very much on RF, at least initially.  It's better to take a shot and then duck behind some cover where they won't be able to see you without burning a lot of TUs (typically corners, or the same wall with the window/doorway).  RF isn't exactly spectacular from the aliens' perspective, either.

You also have access to IR goggles, grenades and rockets without any research -- scan with IR goggles to see through walls (to a degree), use the grenade launcher etc to hit enemies through windows and around corners.   They can see *you* through walls, and will tend to fixate on the closest one -- even if the closest soldier is on the other side of a windowless, door-less wall and there's an opening on the opposite wall.  Also, grenades in the belt or holster can be moved to the left hand with very little TU cost.

Medkits should also be standard equipment -- one soldier can provide very substantial healing on another for 20 TUs cost, and as noted earlier, injured soldiers aren't as effective shots anyway.

Research-wise, you should probably prioritize the laser weapons (very precise, good firing speed, good range, somewhat decent hitting power), and the upgraded armor (once you recover a suit of alien medium armor; you'll be much more survivable with it, so much more likely to be able to attain decent skills).

The .pk3 files in the 'base' directory appear to be Zip archives.  Within the '0ufos.pk3' are many of the data files that affect these things, such as how many TUs each weapon takes to fire in various modes or what their spread is (i.e. imprecision).  You could make your weapons faster-firing (reduce the time values) or make the plasma pistol less accurate (increase the spread value), for instance.

77

Coding / Re: the AI discussion

« on: July 24, 2010, 09:07:51 pm »

http://sourceforge.net/tracker/?func=detail&aid=3033378&group_id=157793&atid=805244

'k.  This includes a patch which is a pretty incremental change.

Known assumptions and limitations retained:

- Only destinations in the same plane are considered.   This was present in the replaced code.

- The shortest path to another point in the same plane is fully within the plane, and includes tiles which are closer by Manhattan distance.  This is both new and incorrect in some cases (maps making heavy use of stairways et al could provide shorter paths in terms of TU); where it is wrong, the increasing-ring approximation is more likely to be wrong.

Facets changed:

- Average path length taken should be reduced, since locations are considered in order of Manhattan distance to alien.

- Bias towards y=0 should be reduced for the same reason; bias occurs, but within the expanding diamonds, so one hiding spot would be preferred to another with a lower y if the Manhattan distance is less.



Now, with respect to 3D -- because of falls et al, it seems possible that it might be faster to descend further sometimes (unless height changes cost TU even when caused by gravity) -- have not checked this.  With this in mind it seems like a BFS or A* traversal of node to node might be much preferred to iterating over grid patterns.   e.g. something with a signature ala

triplet_list_node_t ** bfs(int maxTUs, byte x, byte y, byte z, some_map_object_type_I_dont_remember_right_now_t * foo);

where the return value is an array of length maxTUs (if we ignore 0-cost moves, which don't exist right now AFAIK), whose contents are pointers to linked list nodes (or, alternately, a structure type with an array pointer and a length field) w/ X-Y-Z triplets with a shortest-path cost of exactly the corresponding TU.  This would codify a bias towards shortest paths, which might be absurdly bad (like a civvie's "escape" route passing next to a visible alien with a Kerrblade),  but it might be useful in quite a few functions.    This would also better facilitate hypothetical silliness like a hypothetical April Fools' map in which everybody moves like knights in chess (or more seriously, maps with teleporters, varying gravity for locally different movement costs, et al).

I haven't yet looked at the map / routing code to see how readily it'd be implementable.  For something like the above, what would need to exist would probably be something like "from this spot, where can I get to in 2..max(min(number of TUs required to actually make a move))".   Doors are another consideration; if the code that computed movement cost ignored the possibility of opening doors, that'd need to be handled separately; if it did, then that TU range for the search would need to consider cost of door opening + cost of moving through that door.

78

Linux / Re: Observations from Gentoo 2.3 ebuild

« on: July 23, 2010, 11:48:34 pm »

Oh, the text files were -available- (i.e. the ebuild does build and install them); it's just that until I explicitly picked a language in the game's setup menu, it showed me the variable names rather than either defaulting to a language or e.g. popping up a dialog box to tell me that I should choose a language.  Once I noticed that option and used it, text displayed fine.

79

Tactics / Re: What's your favorite weapon?

« on: July 23, 2010, 07:48:40 am »

Bolters might get some more love if laser damage were attenuated from smoke or the like as mentioned in the laser descriptions; judging from g_combat.c, their damage is currently not affected by this (unless the "throughWall" flag actually is being used for this purpose).

80

Coding / Re: the AI discussion

« on: July 23, 2010, 02:57:29 am »

Hm, 'k.  Will see about getting my build environment set up.  Haven't attempted to build the tree, just been meandering through the code w/ Emacs. 

81

Coding / Re: the AI discussion

« on: July 22, 2010, 12:44:39 pm »

Oh, was mostly musing whether it'd be possible to incrementally consider interesting states (e.g. compute what one can do with 2 TUs of movement, then 3 TUs based on those, then 4 TUs based on the prev. TUs) but that'll only be useful in a highly constrained environment (e.g. interiors) where much of what's in a large cube won't actually be reachable.   Precomputation of pathing presumably makes this moot, anyway.

Speaking of heuristics, a quick look at AI_FindHidingLocation suggests to me that the loops there will return immediately when it finds the first spot within a grid that meets the reachability lack-of-visibility criteria -- and that the search operates in a row-by-row (or column-by-column, one of these) ways. 

Seems that this would bias towards a particular direction (towards wherever pos[1] is smallest, I think), and perhaps towards using more TUs  than necessary (and leaving fewer for reaction fire)?   A search organized ala concentric squares of increasing radius around the actor's location would be slightly more complicated but might result in a shorter move leaving more TUs for RF, crouching, reloading et al; while trying to bias direction towards or away from the nearest enemy (depending on weapon range vs current distance, or health?)  might be more tactically interesting.

82

Coding / Re: the AI discussion

« on: July 20, 2010, 09:59:23 pm »

/* evaluate moving to every possible location in the search area,
    * including combat considerations */
   for (to[2] = 0; to[2] < PATHFINDING_HEIGHT; to[2]++)
      for (to[1] = yl; to[1] < yh; to[1]++)
         for (to[0] = xl; to[0] < xh; to[0]++) {
            const pos_t move = gi.MoveLength(gi.pathingMap, to, crouchingState, qtrue);
                                if (move != ROUTING_NOT_REACHABLE && move <= ent->TU) {

Glancing at that snippet, it strikes me that if you're willing to (1) store movement costs and/or paths, (2) ignore movements that aren't from one adjacent tile to another (which would presumably exclude aliens leaping from a ledge to a multi-step drop), and (3) stipulate that aliens use a single consistent heuristic during movement (either maximizing safety, or maximizing speed) -- that you might be able to save some computation by caching.

Under those assumptions, the 'best' movement from one tile to another will likely be the 'best' movement from the source tile to an adjacent tile, plus another movement.  This is false if you aren't willing to assume (3) -- e.g. it might be 'worth it' to walk standing to one location IF that leaves TUs to reach a safer location, while if that intermediate destination were actually the endpoint you'd crouch.    But if you can cache, you might save some computation by more quickly excluding impossibilities (because they're not adjacent to any possible shorter-path tile), and depending on whether the moveLength caches.  If THAT caches, then the above stuff I wrote can mostly be ignored -- I'm basing this just on the loop structure and that it's pathfinding, not on a deep examination of the code base.

83

Discussion / Re: I want more bases and installations, but how to do it?

« on: July 20, 2010, 09:39:53 pm »

Complete answer:  You don't.

84

Linux / Re: Save Game Bug -> any Workaround ?

« on: July 20, 2010, 06:59:11 pm »

That makes no sense unless that was how you started running it...

'sudo chown -R yourusername .ufo'

to restore ownership...

85

Discussion / Re: I want more bases and installations, but how to do it?

« on: July 20, 2010, 08:58:15 am »

*Source code*, not data files.  For instance, there's a MAX_BASES constant that's set to 8.   You'd have to change the source and recompile.

And you'd also have to make sure that the UI matched.  On screens with a 4x2 base-selection widget, for instance, you'd probably want to add scrollbars or pagination or the like if the code didn't automatically do that for you.

And I'm not sure why you'd bother (with the bases, anyway), because it seems unlikely that you could actually afford to have more than eight unless you have so few buildings and employees in them that you could actually make do with eight.

86

Tactics / Re: Snipers vs Medium-armored aliens

« on: July 20, 2010, 08:34:28 am »

Coilgun's "Aimed Shot" mode does use the sniper skill.  Looking at the data files in the SVN trunk, it has significantly higher per-hit damage and marginally better range, and the same TU usages as the sniper rifle.  The Needlers that you need to recover before researching this also appear to have sniper modes with much longer range, but larger spread values and less damage per shot vs. the coilgun.

87

Discussion / Re: Feedback 2.3

« on: July 20, 2010, 06:57:01 am »

Filed https://sourceforge.net/tracker/?func=detail&aid=3031933&group_id=157793&atid=805242 -- my suspicion is that the 10 TU "throw" mode is what's fooling the UI code into thinking that the goggles are still usable with 10 TUs. 

Also added
https://sourceforge.net/tracker/?func=detail&aid=3031936&group_id=157793&atid=805242
for the blinking textures.

Double-checked medikit, cannot reproduce so not filing an issue there.

88

Discussion / Re: Feedback 2.3

« on: July 20, 2010, 04:48:43 am »

'k, will do after some testing.

Was a bit wrong on the goggle usage -- there IS a bug, but it's not based on reaction fire (that was coincidental), but what's happening is that the code that is used when deciding whether or not the button should be lit thinks that the TU cost is 10, but it actually costs 12 to scan -- hence the disconnect.  Tested this by crouching up/down (3 TUs ea) or passing grenade from belt to hand (2 TUs it seems).  Scan stops working at 11, lights out at 9.  Will file but need to head out now.

89

Discussion / Re: Feedback 2.3

« on: July 19, 2010, 08:51:21 pm »

'Bomb' also has no description in the 2.3 release, IIRC.  Would be reluctant to use it without knowing how it's triggered, or whether it has a large blast radius. 

Main bug I've run into has been the (already known and tracked) bugged Tropical Harvester map -- can't reach second floor, some doorways can be fired through but not walked through, mega-super-tough-and-brainless Ortnoks walking up and down the stairs with plasma blasters not firing at all while getting roasted and electrolased repeatedly.

Other main bug is some blinking ground textures (usually underneath ships or the like), but seeing as I'm running a Gentoo build w/ 2.6.34 + DRI + X.org drivers + Mesa + w/ a Mobility Radeon X1400, and there have been new ebuilds lately for multiple parts of that stack, some graphical weirdness is probably to be expected.

Minor issues I've noticed include the ability to waste TUs by using a medkit on oneself (appears to never help, probably should say 0% instead of 100%, whereas somebody else using a medkit on you appears to be 100% min(20, maxHP - minHP); and the 'use goggles' button not turning off when (current TUs) >= TUs-to-use-goggles > (TUs - reserved TUs).

90

Tactics / Re: Tip of the Day

« on: July 19, 2010, 01:38:28 am »

Tip of the Day mentioning flashbangs still exists in the 2.3 release; yet I can't seem to build them or buy them (seem to recall them available from start in final version of 2.2), and I've researched enough that the current research items going on relate to Starchasers and plasma grenades.  Unless they've got some wacky research prerequisites, the tip seems no longer applicable.