I can confirm that attached to a weapon, the VP Scope transforms that worked several versions of HAM ago are now now causing a CTD.

As the team approaches the destination, the arrow will shift colors - first to greyish, then to yellow as you get near. IT will also move appropriately: crossing the border into the next sector. The team arrives when the arrow is fully yellow and inside the destination sector.

Comments on this will be appreciated, especially the colors used.

Bugs:
When transforming a stack of items via Sector Inventory OR in a merc's inventory, if the items are not all of the same condition, the system only uses the TOP of the stack item's condition to generate additional items.

Also, BP costs ARE charged out of battle.

adding in variable power scopes for the 7x (2x, 4x, 7x) and 10x (2, 4, 6)

Isn't that overdoing it? A 10x scope doing 2x would be very very bad balance-wise. 7x should maybe do 4x-7x, while 10x does 6x-10x or something... I'm just afraid that If they can go to 2x, they'll make sniper rifles and DMRs uber-useful again...

Headrock,
Have you ever considered making a "draw cost" as a separate weapons.xml tag? For example if there is no separate xml entry everything is calculated as it is now. If there is a separate .xml entry then the draw cost value is taken from this xml tag.

Hi Alex,

If i'm not mistaken, "AP to draw" is in weapons.xml as :

Weapon handling is used by the NCTH calculation to modify hit chances based on how cumbersome a weapon is. The idea here is that small, light weight weapons will be easier to control and 'stabilize' then large, heavy weapons.
Originally, NCTH didn't have a Handling tag. Instead, it used the ubReadyTime to determine the handling modifier. I added the Handling tag to give modders more control over weapon handling and to resolve a problem where ubReadyTime=0 weapons were getting no handling modifiers at all. I never got around to adding information for this tag to the UDB interface. I'll add that to my todo list.

While Headrock's original plan used Draw cost, the NCTH implemented by ChrisL in stock v1.13 has a separate "handling" value. Starwalker came up with those values.

Additionally Headrock did say something about eventually double checking how Handling is actually being used. There's some question as to where this value takes effect, and its overall effect on hitting things in-game.

So do I get it right that NCTH handling is being calculated from the separate tag? If so this is a great and long-waited addition. Shame I have not spotted this earlier.

Quote:

also, discussion has been tilting towards using things like "sight length" (M4 vs Tavor) in deriving the NCTH Accuracy stat

As far as I remember the initial "accuracy" purpose was to simulate weapon qualities that affect hit probability but can not be taken into account during the aiming process (for example quality of the barrel).

Initially the visible aperture size did not change if "accuracy" value was changed. However the real aperture size was adjusted on accuracy values.

In the new version, the stock doesn't even try to transform. Attempting to transform it exits the UDB instantly and no transformation occurs. If the stocks are removable, then there is no problem whatsoever.

Given that removing 'inseparable' attachments is easy, I don't find this to be a troublesome bug, but I thought it should be reported.

Happy Holidays, all ... (I like the snow, btw)

Lets take for example a gun with an internal (default inseperable) scope 2x. We define a transformation that changes from 2x to 4x. When we change the scope, this is what happens nominally:

A) The 2x Scope is erased, because it's one of the gun's default inseperable attachments.
B) Any other attachments are copied to memory.
C) All attachments are erased from the gun.
D) A new 2x Scope is attached to the gun, because it's one of the gun's default inseperable attachments.
E) All other attachments in memory are reattached.

Two comments on this. First, Alex is absolutely correct on this. Accuracy is a value entirely representing how well the weapon can put its bullets to where it is aimed, and thus should never be intermingled with snapshot/aiming performance (aperture size). Therefore Wil, I think that sight length is actually not at all a factor on accuracy.

In fact, possibly the best simulation of the effects of sight-length would be an Aiming Modifier: Does not affect snap-shooting, but does affect aiming.

What the game does is this:
A) Erase all inseperable default attachments from the gun.
B) Copy all remaining attachments to memory
C) Erase all attachments on the gun.
D) Recreate all default inseperable attachments and put them on the gun.
E) Reattach all items from the memory attachment list.

if it is the default attachment being transformed, and not the base item/weapon, why is the base item/weapon's other attachment being checked?

one of us really needs to create some kind of table to figure out when and if attachments can or should pop in and out of existence.

Something I didn't want to clutter my previous post with was potentially using the item transformation ability to "lock" attachments to a gun so that Shift-F doesn't remove them. ie. two copies of an attachment, one with the inseparable flag set, and the player could use the item transformation menu to alternate between the inseparable and removable forms while it is attached to the gun.

Quote:

Something I didn't want to clutter my previous post with was potentially using the item transformation ability to "lock" attachments to a gun so that Shift-F doesn't remove them. ie. two copies of an attachment, one with the inseparable flag set, and the player could use the item transformation menu to alternate between the inseparable and removable forms while it is attached to the gun.

Whoa... don't you think that would create a ton of new items though? There are lots of attachments...

Hrm maybe you should wait until I've created the Item Templates system. Might make the work easier, or at least tidier.