Would anyone know how to change the TUs needed to work the psi-amp? I don't see anything in OBDATA (all its TU fields are set to 0). It would be helpful to psi testing. NKF? ---MikeTheRed 16:29, 7 September 2006 (PDT)
- In case someone is still interested, I located these pieces of code that may be related to psi attacks (note that 25 = 0x19) :
.text:0041F163 8B 15 88 3E 4A 00 mov edx, currentUnit_pUnitRef .text:0041F169 80 7A 0C 19 cmp byte ptr [edx+0Ch], 25 ; current TUs .text:0041F16D 0F 82 94 01 00 00 jb loc_41F307
.text:0041F230 A1 88 3E 4A 00 mov eax, currentUnit_pUnitRef .text:0041F235 80 40 0C E7 add byte ptr [eax+0Ch], -25 ; consume TUs
- (-25 = 0xE7).
- You may want to change the values I hilighted and see what happens when you try to panic a unit ;-)
- Same for mind control:
.text:0041EE89 80 7A 0C 19 cmp byte ptr [edx+0Ch], 19h
.text:0041EF55 80 40 0C E7 add byte ptr [eax+0Ch], 0E7h
Have fun! Seb76 14:39, 28 April 2008 (PDT)
IT WORKS. Seb76, you're a genius. TUs for MControl and MPanic, tested. Just one glitch, the pop-up menus show the old values. Could you please tell us what more should be changed? --Kyrub 16:44, 30 August 2008 (PDT)
Unfortunately obdata doesn't store all weapon stats. Unique actions like the costs for priming grenades, throwing stuff, mind probe, psi amp, etc are tucked away in tactical.exe. Hmm, I'm positive that they can be located, but there are so many iterations of similar values that it could take a long while to discover them.
What could make thi worse is the possibility that these in-built actions (perhaps even the in-built alien melee attacks) will not be clustered together near each other.
Arg. Well it's not a real big deal. The psi equations are now known quite well; it'll be posted shortly. Reducing psi-amp TUs would make it easier to ultra-tune the psi equations, but it wouldn't make any difference to players. Don't knock yourself out, but if you can find it, that'd be nice! Thanks for the reply ---MikeTheRed 18:40, 8 September 2006 (PDT)
It occurs to me that I have no idea what it is that allows the laser weapons to fire without a clip. At first I thought simply giving them a base power rating (something other weapons don't have) was the key, but apparently giving a clip a power of 0 doesn't render it useless...
Can someone provide some details on this?
-Bomb Bloke 03:32, 4 October 2007 (PDT)
Just a quick gaze at obdata, it seems that the laser's three clip types appear to be set to 255 (or -1 if we think in terms of signed values) to mark that they're not used and the item has a power rating. Apart from that, I can't see anything terribly out of the ordinary. - NKF
To make a weapon clip-less and ammo-less you must set the clip references all to 255 like NKF mentioned. Make sure to set a power rating in  (if you want the weapon to do damage that is, this field is not a requirement for a laser-type weapon) and don't forget to switch the damage type in  from 255 to a valid number. That combination should create a laser-type weapon without ammo or clips. Hope that's what you were looking for. --Zombie 20:02, 4 October 2007 (PDT)
That sounds about right. Thanks guys. :)
- Bomb Bloke 20:10, 4 October 2007 (PDT)
For clipless weapons, it might be enough just to set the first clip type to xff/255 - the game then doesn't look for the 2nd and 3rd clip type. I think. I did that by accident and I didn't check it terribly rigorously. Spike 19:39, 22 November 2008 (CST)
Damage Type Hacking
A lot of the damage type behaviour seems to be hardcoded. For example here was some of my experience. (Maybe I made some mistakes, please check for yourselves.)
- If you hack a ranged weapon's damage type to Stun, it automatically becomes a Stun Explosion (area effect), like the Small Launcher Stun Bomb. (Tested 4 weapons)
- (To implement a non-area ranged stun weapon, give it weapon power 5 so it will never affect outside its target square. Give it high ammo and low %TUs - fire continuously!)
- If you hack a non-IN weapon to IN, it doesn't create a fire effect. (Tested AutoCannon - but as a laser-style clipless weapons as per previous section)
- If you hack a Grenade to Stun, it still does normal damage (no Stun) and it still destroys objects on the ground
This is a shame because I wanted to implement a Flamethrower or Tank/Flamethrower - an Incendiary weapon with a weapon power of about 10 IN, but %TUs/shot of 1% and infinite ammo. Oh well! I guess I can still do it using AC-IN and giving it low %TUs, high ammo capacity.
On the other hand, these things work as expected:
- Hacking a non-IN ammo type to IN seems to work. So I could hack AC-AP, AC-HE to IN. Both started IN-type fires. The hacked AC-HE did not damage objects.
- I could hack AC-IN to AP and it did not retain any area affect (or fire effect).
- I could hack all HC- ammo types to Stun and they did not produce fire, nor damage to objects, nor permanent health damage.
So maybe only ammo types (not weapon types) are allowed to generate area effects? (apart from Stun, as discussed immediately above).
Spike 19:39, 22 November 2008 (CST)
- It would be real fun if the blaster bomb could be turned into a huge area-of-effect stun bomb. :) -MikeTheRed 13:22, 24 November 2008 (CST)
Fields 29 and 30
They were mixed up with each other. Actually only value of field_29 matter, I haven't found any references for field_30 in the game code. And I don't know why field 30 was declared as "used". Alien corpse objects have different fields 29 and 30,and field30 always seems to be 0x0F or 0x0E which are rifle clip and grenade objects... . --Volutar 13:01, 5 April 2011 (EDT)
Field 0x2D (45)
This field used by AI for "Worth to take" estimation (function at address .text:004043E0). This value meant to be max_distance+5.
worthtotake = obdata_addr->field_2D; ... return (worthtotake - xc_BF_Get_Distance(v_Selected_Unit_Xpos, v_Selected_Unit_Ypos, a_ObPos_DAT[obj_num]->x, a_ObPos_DAT[obj_num]->y)) > 5;
I've patched ObData.Dat file (replaced all field_2d values of 0x01 with 0x10) and observed AI picking up dropped items. I don't know why this field was disabled, though I can presume it could be heavily used as "bait" like cheat because this estimation function cannot "skip" items if AI unit already has attacking weapons and clips (maybe this "taking" function ain't even called if unit is fully equiped - I didn't check that). Probably it wasn't finished... Which is weird. --Volutar 08:07, 26 March 2011 (EDT)
Firstly it fills some buffer (maximum length is 50 elements) with items, having flag field (+0x0c) with bit1 set (& 0x02). Then it calculates most worthy item as maximum of worthToTake/(distance+1). And only after that it will try to pick this item up if distance is less than worthToTake-5. So this value is matter when AI choosing object to pickup. And of course when AI sees some attacking options, it chooses most effective. When estimating grenade efectiveness it thinks that 1 friendly unit equal 2 enemy. So if there will be 1 friend with 2 enemies at very close distance, AI won't even try to blow them up.--Volutar 12:55, 1 April 2011 (EDT)
- This is really good news that you found this function for aliens to pick things up . Finding a way to activate it could eliminate the silly problem of unarmed aliens who won't pick up weapons. You are right there is a risk of a "item bait" tactic being used. The trick would be to make sure that item pickup is only used by aliens who are unarmed or (better) for aliens who lack a weapon that is effective against X-Com, to pick up a weapon that is effective. Spike 17:28, 28 March 2011 (EDT)
As far as I tested it, this pickup function ain't used when alien have some attacking weapon. So there are no ways to use it as bait cheat. And actual code doesn't require any patching, only "obdata.dat" does. I wish to know the reasons why they made insufficient this "AI combat value" for attacking objects, because I don't see any. --Volutar 21:59, 28 March 2011 (EDT)
- So if I understand correctly, if you set this worthtotake field to any value above 5, the alien will move to pick it up, if the alien is unarmed, and the (worthtotake of object - distance to object) is greater than 5? Excellent. Spike 15:19, 29 March 2011 (EDT)
If you set this field 10, maximum worth distance will be 5 (10-5), value of 20 will become 15 tiles (very valuable weapon, like blasterlauncher). Value of 5 will be ignored and 6 mean, alien willtake item only if he stands over it (occasionaly, or just dropped due to panic)... The only presumable reason of disabling this AI feature is - it makes "panic unit" a bit obsolete, because there are small chances they won't take dropped weapon back... Apart from this "worth distance" AI has another conditions for taking weapon from ground, so if you set this field to 200, they won't be ALWAYS running all over for weapon if they haven't one. When I set this field 10, about 70% of aliens were taken dropped weapons back at first turn, and about 90% at second...
- So two questions that come up are, 1, Who will do this mod?, and 2, what values to set?
- Seb76 has said that he "doesn't do" data file fixes in his Loader, which is a shame. That means that we would want to prevail on BladeFireLight, the new maintainer of XComUtil, to incorporate this fix into a release of XCU. I do think it's fair to consider this a bug fix, though fixing it also doubtless "makes the game harder" (another category for XCU mods). At the moment, a Panicked alien is almost your ideal result in combat, at least against weapon-only aliens, because they are permanently disarmed and harmless. You can then use them for target practice, capture them, do what you like with no risk.
- In my research on alien weapon preferences, when their main weapon is missing or out of ammo, they select weapons out of their inventory more or less in priority of the base damage of the weapon (highest first). So it would be consistent, and simple, just to copy the base damage value into this field 24. Question: if there are multiple weapons out in the open, does the Alien go for the nearest one, regardless of the field 24 value, or will it go for a more distant weapon, if the 0x24 value is significantly higher? If there's no difference in behaviour, then it makes no difference, you might as well just set all the value to 0x10, as in your tests. If it does make a difference, then it might be best to set the 0x24 value to something like the Firepower Factor of the weapon, to help the Alien make the 'right' choice of weapon. Most of the time, the weapon with the highest base damage IS the best weapon to use against XCom, especially as XCom is often heavily armoured. It's not clear if the AI recognises that auto weapons and HE weapons are more effective than their base damage alone suggests. So you could tweak the 0x24 values to reflect that. Spike 06:15, 1 April 2011 (EDT)
- If we can agree on the details of the fix, I can try to splice it into my Python-based editor suite. Zaimoni 00:02, 2 April 2011 (CDT)
- OK, well my initial suggestion would be use the standard damage, field 0x16 (decimal 22) of the weapon (or of the clip loaded into the weapon). These values would work well given that the ranking of 'most worthy' is done by dividing by range+1. That means the unarmed alien will go a little further to pick up a Blaster Launcher.
- Valutar, does the code check whether the weapon is loaded or empty? If not, that might be one of the reasons the developers abandoned this code. Also, can you tell if the AI uses any modifiers in selecting a weapon to attack with from out of the alien's current inventory? Does it add some % for HE weapons, subtract some % for Stun weapons, add some % for Auto weapons? If the AI uses any rule like that for selecting a weapon to attack with out of its inventory, we should use the same rule for selecting a weapon to pick up off the ground. Spike 15:24, 2 April 2011 (EDT)
- So this needs balancing. At least the formula is known, so an educated guess can be made before testing, but I'm not sure how to do a reasonable test. [Ideally we'd use a borg, but the effort required to write one would be awesome.] Zaimoni 00:33, 3 April 2011 (CDT)
- Code does check 1) if ground weapon has ammo loaded, or 2) if alien already has ammo for empty ground weapon, or 3) if ground clip fits to weapon he already has (to take extra clips for weapon with depleted ammo), and this is ONLY if he has free inventory slots to pick it up. And I don't know if alien will take weapon AND all clips for it if he stands over dead body with "full set"... Probably he will.--Volutar 02:11, 3 April 2011 (EDT)
- That covers the worst cases where this could be exploited by the human. As long as only unarmed aliens will walk toward dropped weapons, and as long as the dropped weapons are actually viable to attack with, I think this is balanced and makes the game more realistic, and makes it harder, not easier. One more question - do we know if an alien that has built-in weapons, or active Psi, will attempt to pick up a weapon? This would be bad. Another question - will an alien pick up a weapon or clip if the alien has a weapon, but the weapon is empty and the alien has no spare ammunition in its inventory? If the answers to these questions are not known then I guess they could be discovered through testing. By the way, I think this patch would be a very good candidate for "Standard X-Com". Spike 13:36, 3 April 2011 (EDT)
- Only Sectoids, Snakemans, Ethereals, Mutons and Floaters are capable of taking weapon from the ground. Another answer is already given: "3) if ground clip fits to weapon he already has (to take extra clips for weapon with depleted ammo)"--Volutar 14:07, 3 April 2011 (EDT)
- (Reset indent level). Sorry I missed that answer about completely depleted ammo. Your answer about which races will pick up weapons means there is the possibility that an alien with strong Psi capability would get killed by coming out into the open to collect a weapon that it doesn't really need. That would be a backward step. Maybe we could test for that. Spike 14:21, 3 April 2011 (EDT)
- Another thing discovered, which could make you slightly happy. This "picking up" scanning function takes only objects in account, appeared on ground when it wasn't XCOM turn. It means player cannot force aliens to take them as bait. If alien killed some XCOM he could pick up his weapon as trophy. So, this is not the subject to concern about. By the way, when discovering this I found that ObjPos flagfield_10 was treated wrong: bit 0 flags those objects, which were dropped on player's move and bit 1 means aliens were the reason of objects appeared on the ground. --Volutar 13:37, 5 April 2011 (EDT)
- Just did a light test of this (setting the AI worthiness of weapons to their damage). Note that weapons carried by aliens stunned during X-COM's turn are ignored even if there are no agents covering the alien on recovering, so it's very likely the flaky field settings were not testably different than the designed behavior. --Zaimoni 13:37, 13 October 2012 (CDT)
- This is maybe not a bad thing. Otherwise an XCOM sniper with a Stun Launcher (or a brave soldier with a Stun Rod) could potentially set up and stake out a perpetual killing ground. Spike 22:23, 13 October 2012 (EDT)
- Remember, the object chase code should only apply to disarmed aliens -- no perpetual killing ground without end-game psionics (at which point there are so many abuses it isn't funny). As I see it, the problem is that the AI can't have much mental state in the DOS version because of the memory model (64K per byte-addressable segment max). It wouldn't have been practical to calculate the patrol paths, etc. based on the map. --Zaimoni 8:30, 14 October 2012 (CDT)
- That is: I don't think that an alien that just wakes up after being shot badly, should run away from the weapons it dropped because it was shot. It should pick them up immediately, at least if picking up items costs TUs (this doesn't use energy so it should not trigger reaction shots). The tactic seems to work well in Extender's Alien Pets mode. --Zaimoni 8:39, 14 October 2012 (CDT)
- You are right. So it should be treated as a bug. By the way the source code of UFOExtender shows it has a 'get' attribute for OBDATA.DAT which is this 'value to get' data. I'm not sure if it's working but if it is that's useful. Spike 22:44, 14 October 2012 (EDT)