Home » MODDING HQ 1.13 » v1.13 Idea Incubation Lab  » HAM 5 Alpha - You know it!!
Re: HAM 5 Alpha - You know it!![message #295388] Sun, 18 December 2011 01:16 Go to previous messageGo to next message
Slax is currently offline Slax

 
Messages:1411
Registered:July 2006
Location: People riding polar bears...
Oh Christmas HAM! oh Christmas HAM!
I want to play you so damn bad.
Oh Christmas HAM! oh Christmas HAM!
You make me smile when killing... mans.

Merry snowtime, errybody :crazy:

Report message to a moderator

Sergeant Major
Re: HAM 5 Alpha - You know it!![message #295391] Sun, 18 December 2011 02:21 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
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.


So can I, but the dreaded thing happened again: It is a bug that occurs only in Release mode. This will make it exceptionally difficult to debug - but I will try.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295394] Sun, 18 December 2011 03:54 Go to previous messageGo to next message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
Probably the largest re-balance to NCTH so far: Alrulco Folding Stock v3.60RC2 HAM5 Optimized 20111218

[Updated on: Sun, 18 December 2011 04:05] by Moderator

Report message to a moderator

Lieutenant

Re: HAM 5 Alpha - You know it!![message #295397] Sun, 18 December 2011 04:28 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
REUPLOAD

HAM 5.5a has been reuploaded. Link is in the opening post. If you're up to date, all you need is the EXE.

This version solves the very nasty issue with attached Variable Power Scopes (or other transforming attachments). Very Happy Very Happy Very Happy

It was a really tough one, which resulted from me doing something that ChrisL warned me about just prior to HAM 5.2.2. There needs to be more testing work to figure out whether it's functioning 100% properly, but I failed to crash the game after a considerable number of attempts, so it should be fine.

Let me know.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295405] Sun, 18 December 2011 13:20 Go to previous messageGo to next message
Tango is currently offline Tango

 
Messages:106
Registered:July 2006
Not sure if this is HAM related or more to do with the latest AFS 3.60RC2 but I'm getting a runtime error with the latest 5.5a version when I try to launch it:

Error:
Line 616
Loading External Map Sector (to do with coolness I think)

Along with:
Line 851

EDIT:

Not a HAM bug will report it to Wil. The crash if occurring due to a lack of a CoolnessBySector XML file in the RC2 files (the VFS setup does not read the one in the Data HAM folder.

[Updated on: Sun, 18 December 2011 13:28] by Moderator

Report message to a moderator

Sergeant
Re: HAM 5 Alpha - You know it!![message #295410] Sun, 18 December 2011 14:57 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
That makes no sense... If the file is there, and VFS is properly set up, it should look for the file in the HAM folder if it can't find it in any of the preceding folders...

[EDIT: I see the problem, it's a small oversight by Wil. I'll report it on the AFS thread.]

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295446] Mon, 19 December 2011 03:58 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
UPDATE

HAM 5.5.1 has been released. The download link is in the opening post. If you are up-to-date, you should need the EXE as well as several STIs (extract the entire INTERFACE folder as appropriate).

This version fulfills a promise I made a while ago about merc movement arrows showing how far along they are into the next sector. This is done with position and color of the arrow.

When a team has just begun to move out of the sector, the movement arrow will be inside the sector boundaries, and colored blue.

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.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295471] Mon, 19 December 2011 19:16 Go to previous messageGo to next message
reVurt is currently offline reVurt

 
Messages:61
Registered:March 2007
Location: The Great White North, eh...
Headrock
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.


Works nicely, from what I've seen so far. If anything, the effect is a little understated in 1024x768. The colours seem a touch bland to me, but I'm not sure what I'd replace them with, to be honest. In a way, the transition happens too fast to really appreciate the colour changes at the fast time compression, but I suspect if were to use a slower time compression (with multiple teams in the field that need coordinating) that this would be more helpful, but even then the grey and the yellow are a touch too similar to quickly differentiate. While the yellow blends in with the square border color nicely, it doesn't really denote the sense of urgency implied by entering a new, potentially dangerous sector.

That's my two cents, for what it's worth.

Report message to a moderator

Corporal
Re: HAM 5 Alpha - You know it!![message #295482] Mon, 19 December 2011 22:56 Go to previous messageGo to next message
Soren is currently offline Soren

 
Messages:13
Registered:December 2011
Testing Report:
Mods/Version:
Special SCI + Ham 5.5a + MAM 2.4.5 + a few custom extras

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.

Example:
I have a stack of 3 t-shirts, 90%, 82%, and 20%. If I tear them up with the 90% one on top, I get 4 90% Rags, an 82%, and a 20%. (Instead of 2 of each.) This has been a bug since the stack transformations were fixed. I would have commented earlier, but this is my first post as my account just got approved (a long post, too!)

Also, BP costs ARE charged out of battle. AND they are charged to the truck! E.G., in my extras, you can melt down steel items into chunks of steel (good ol' JA1, I use the silver nugget pic). Chunks can be turned into steel tubes and springs. Anyway, put a steel helmet into the truck, transformed it into two steel chunks in strategic map/sector inventory. All my gas disappeared Sad Not necessarily a bug, but I figured you should know.

Feature Comments:
I went through and fixed all the integral stocks and bipods, as well as adding in variable power scopes for the 7x (2x, 4x, 7x) and 10x (2, 4, 6). I didn't change the ACOG (it is a fixed power scope, see below). Also added open/close for grippod.

All in all, it works VERY well. Some weapons that were kinda weak with integral retracting/folding stocks become much more usable when you can pop the stock out and send some accurate aimed bursts downrange. Excepting for some very hard to raise weapons (shotguns, especially), if the AP cost for extension/retraction is not zero, there is little advantage to popping the stock in every time you move/reload/do something that requires re-raising the weapon and then popping it out to fire - you just keep the stock out. However, on the first use, this can save considerable APs. The main advantage is the ability to remove the penalties imposed on a lot of integral folding stock firearms that vanilla 1.13 imposes. For my money, I set the AP cost to 1, no BP cost, and I think this is relatively reasonable. It makes fiddling with SMG stocks kinda useless, but adds power back to, say, the Colt 9mm (competes well with the Steyr AUG Para again).

Bipods/grippods are a bit different. There is a considerable penalty for using them when not prone, and allowing the user to fold them up for a more reasonable penalty (it still IS a bit of metal on the weapon, so it makes handling worse) when crouched makes them much more handy. My sniper with a SL8 can use it crouched/bipod closed or prone/bipod open, as circumstances dictate.

Balance Issues:
It has been mentioned many times before, but with NCTH, coolness rebalancing of items is almost required. With MAM's increased shotgun effectiveness, these make excellent coolness 1-3 suppression weapons with buckshot (at which point you transition naturally into submachineguns, then assault rifles, then LMG/MGs). I hesitate to suggest MORE weapons, but we might want a few more really sucky SMGs and especially more sucky LMGs. Older scoped rifles (Garand/Mauser, and to lesser extent, the M1 Carbine) are not really as effective as, say, a Sterling or even in some cases the Baikal-233 - fire and maneuver is really the way to win. The AI will use suppression, but has few options in the early game (Glock 18/Scorpions are probably the most common, as well as 93Rs and the occasional SMG/shotgun). A bulky, ugly LMG is just the right thing for the enemy to use in, say, the DCA, and it makes sense too! With generally superior numbers, the AI should be using suppression to beat up my mercs, but at least on Expert, they don't.

In general, (and I speak as someone who played JA1, DG, 2 pre-1.13, vanilla 1.13 OCTH, then NCTH), I love NCTH. It does make the game different, but really, in OCTH you need about 3-5 shots per kill, and that's even more silly than Hollywood. Lugging around a ton of ammo makes no sense, and it cuts out a whole logistical subdimension of the game. Suppression also makes stealing EASIER - while one merc is firing SMG/shotgun suppression rounds, another is running closer to steal your stuff. Good times. (With MAM's price structure, stealing weapons is VERY much worth the trouble. A merc can pay for themselves with one or two swipes. And, I admit, I upped the daily cash that Tony has.)

Too many guns can accept good attachments in even vanilla 1.13 (I cut a lot of the addons that MAM made there, too). The advantage of certain weapons, especially modern ones, over others (especially older ones), is the compatibility with better attachments. (This is true of the ACOG - it can 'add' reflex sights to weapon, which is nice on, say, the Mini-14). Pistol silencers are probably the worst offenders - everything, almost, can use them, so guns with dedicated threads for suppressors lose big time (I'm looking at you, Mk 23 ...)

Items that need fixing:
The ACOG is a fixed sight, but should probably be given some other bonus to compensate. It's a good choice for assault rifles/carbines (3-4x is about your engagement range for those, I find). Maybe a night bonus?

ISM-V-IR needs serious tweaking since NAS came out - there's little need to save slots as before, and the fact that scopes are de rigeur in NCTH makes it pretty useless.

MP5N - I recommend a night bonus due to the Surefire light forestock, but a stealth penalty too (hey, what's that light?)

Further Transforming Ideas:
I am probably going to try making a 'buttstock' item - rifles/SMGs can transform into it. It represents hitting someone with the stock - a blunt weapon. I am not sure what, if anything, will happen to the attachments on said weapon, so I will report back when I overcome laziness and do it.

I also think being able to turn off flashlights/lasers (no aim bonus, but no stealth penalty) would be nice. Also, as mentioned in the MP5N, SureFire forends are on my to do list. For 0-1 AP, it makes sense to sneak up on the enemy without the laser/light on, then turn it on and let 'em have it.

Also, I am open to advice on how to model firing .38 Specials out of a .357 Magnum weapon. I am pretty sure we can't do this now (though, admittedly, I haven't tried). You SHOULD be able to, though; a simple 0 AP transform to switch between the same picture weapon, but alter the stats and ammo type.

I am finally also considering making a test system for the interchangeable MP5 family - change a barrel here, a trigger module there, and voila, your MP5N is now a MP5/40. This would mostly be to test the transforming abilities to 'take apart' weapons. Granted, I am terrible with graphics, so it won't look good, but as I am the only one looking at it, who cares?

Sorry if this came out so long ...

Report message to a moderator

Private
Re: HAM 5 Alpha - You know it!![message #295483] Mon, 19 December 2011 23:48 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
@ Soren: Thank you for your feedback, it was a very interesting read.

Quote:
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.


I still need to get around to that. I was hoping to be able to transform just ONE item in any stack, but I ran into difficulties with that. I need to make that work, and I will eventually.

Quote:
Also, BP costs ARE charged out of battle.


I intentionally did this, because IMHO they should be. But I didn't consider vehicles. I think I'm going to forbid transformations when an item is loaded into a vehicle.

Quote:
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...

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295485] Tue, 20 December 2011 00:02 Go to previous messageGo to next message
Soren is currently offline Soren

 
Messages:13
Registered:December 2011
Headrock
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...


Honestly, I have no RL experience using scopes, and (perhaps due to weak Google-fu), I couldn't really find a tremendous amount of data on what would constitute a reasonable setting on a variable power scope. (1.5x-7x isn't ... very informative.) Even with the ability to hit short range targets with a sniper rifle, the question is WHY you would do so ... for example, even a max tricked out SL8 in a Sniper's hands will get at most 2 or possibly 3 shots off (max aim, of course). In the same amount of time, a SMG can put 5 or 10 times the amount of lead downrange, and given the odds of missing (using a 90-ish DEX/90-ish MRK Sniper, a hit is not guaranteed), you are better off transitioning to another weapon or letting your mercs with short ranged weapons take the shot. With a real sniper rifle, the number of shots is worse. The 2x gives the sniper the option, in an emergency, to engage short range; the AP cost of setting down the rifle/bipod again is the counterbalance to transitioning to your backup piece. A really good pistol with scope in that range is probably a better option, even, but the SMG is the best.

Update: (figured I'd save a post)
I added a Colt Python that fires .38 Specials. Works fine, and as a bonus, HAM auto-ejects the incorrect ammo (I suspect this is part of the 'incompatible attachment' check code ...), so you can't cheat and use HPS's as stand in for AETs. Back and forth transforms work as well.

I decided to abandon the buttstock idea, as I realize you'd have to make one for each weapon (!!) otherwise there is an easy exploit (I turn my MP5 around, and I get a stock to hit you with. When I reverse it ... it is a M16 ...) if guns share buttstocks.

[Updated on: Tue, 20 December 2011 23:46] by Moderator

Report message to a moderator

Private
Re: HAM 5 Alpha - You know it!![message #295592] Thu, 22 December 2011 12:01 Go to previous messageGo to next message
ChonkE is currently offline ChonkE

 
Messages:17
Registered:January 2008
Location: Utah
What do you mean "reasonable"? It is all about what you are willing to spend. You can get a "Unicorn" scope with a true 1x power both eye open shooting capability that has even lenses and foci points (and weight) to zoom in to 12x power or a 5x-20x or whatever you are willing to pay. Light gathering, objectives, lens coatings, inert gas fillers, nitrogen purging, tactical turrets w/set zero blah blah blah blah blah. $$$$. The glass is out there. Not all of us have mineral resources to mine and sell for arms. Our heroes(?) do! Most standard DMR/close-range hunting optics which offer both eye open shooting range from 1x-4x. Many variable power hunting optics are 3x-9x, 4x-12x. Bench shooters and snipers like bigger stuff now.

As far as the night bonus on the ACOG thing; you cannot hit what you cannot see, so if you do not have proper distance, lighting, background, technological advantage or otherwise... well no bueno. The ACOG is nice for certain applications but it certainly doesn't see in the dark. It is a durable, rugged fixed power battle sight that allows for quick and rapid target acquisition and transition. In low-light/dusk that chevron is a nice advantage though.

Headrock, Snipers and DMRs should be uber-useful! Smile Just sayin'

Report message to a moderator

Private
Re: HAM 5 Alpha - You know it!![message #295671] Sat, 24 December 2011 12:09 Go to previous messageGo to next message
Randok is currently offline Randok

 
Messages:321
Registered:March 2004
I do not know. Maybe someone already posted about this but in one sector unless the snow falls. Super Smile . It could be a little thicker. Is this snow has an impact on visibility and accuracy?

Report message to a moderator

Master Sergeant
Re: HAM 5 Alpha - You know it!![message #295674] Sat, 24 December 2011 18:23 Go to previous messageGo to next message
PasHancock is currently offline PasHancock

 
Messages:720
Registered:February 2011
Location: Estonia,Tallinn
i was playing ja right now and i noticed that 3 enemies ran into flames(i threw molotov and 3 soldiers ran into it).I think this should be fixed with HAM

Report message to a moderator

First Sergeant
Re: HAM 5 Alpha - You know it!![message #295675] Sat, 24 December 2011 18:41 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
They probably thought their gas mask would protect them.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295676] Sat, 24 December 2011 18:49 Go to previous messageGo to next message
PasHancock is currently offline PasHancock

 
Messages:720
Registered:February 2011
Location: Estonia,Tallinn
thats what i mean.This should be fixed if possible

Report message to a moderator

First Sergeant
Re: HAM 5 Alpha - You know it!![message #295687] Sun, 25 December 2011 12:43 Go to previous messageGo to next message
Alex_SPB is currently offline Alex_SPB

 
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg
Headrock,

I am extremely glad that you are back. I will download and test HAM. But before this i would like to ask a question i wanted to ask while you were designing NCTH. Unfortunately you left the forum before I managed to do this Sad

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.

This will greatly enhance the flexibility of the system.

Report message to a moderator

Staff Sergeant
Re: HAM 5 Alpha - You know it!![message #295688] Sun, 25 December 2011 12:50 Go to previous messageGo to next message
PasHancock is currently offline PasHancock

 
Messages:720
Registered:February 2011
Location: Estonia,Tallinn
how to turn off snow?

Report message to a moderator

First Sergeant
Re: HAM 5 Alpha - You know it!![message #295690] Sun, 25 December 2011 13:14 Go to previous messageGo to next message
knightofni is currently offline knightofni

 
Messages:96
Registered:August 2011
Alex_SPB
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 :

Report message to a moderator

Corporal 1st Class
Re: HAM 5 Alpha - You know it!![message #295693] Sun, 25 December 2011 14:01 Go to previous messageGo to next message
Alex_SPB is currently offline Alex_SPB

 
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg
Quote:

Hi Alex,

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


Yes, it is, but this approach has several weak points. For example let us compare 2 guns: M4 and IWI Tavor TAR 21. Both guns are equipped with iron sights only. As Tavor is a bullpup and especially designed for close quarters combat, it is more easy to rise this gun than M4. This means that Tavor should have lower then M4.

Both guns have the same barrel length and quality and shoot the same round. However M4 has longer sightline (space between front and rear iron sights) then Tavor (equipped with iron sights only) and will allow to produce much better aimed shots in real life. In NCTH Tavor would allow to be better aimed then M4 (opposite to real life) as the single value is used both to estimate time to prepare weapon for shooting (raise time) and efficiency of aiming.

My real life shooting experience tells me that the assumption "lower ready time = more accurate aiming" is not 100% true.

As of now it is extremely difficult to adjust existing draw cost mechanics for the example with Tavor and M4 described above via XML. A new entry would simplify the whole process a lot.

[Updated on: Sun, 25 December 2011 14:09] by Moderator

Report message to a moderator

Staff Sergeant
Re: HAM 5 Alpha - You know it!![message #295695] Sun, 25 December 2011 15:07 Go to previous messageGo to next message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
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.

I think you may be confusing my efforts to re-balance NCTH for my projects - Draw is used to produce initial Handling values that are later manually tweaked. See: NCTH Handling Rethink Spreadsheet The values have already been implemented in my two most recent mods that are meant to demo other HAM 5 features.

AFS v3.60RC2b-HAM5 Optimized 20111219

Urban Chaos-1.13 v3.60 RC6-HAM5 20111221 This one also can be run under the latest of Tais' "Unstable" SCI.


EDIT: also, discussion has been tilting towards using things like "sight length" (M4 vs Tavor) in deriving the NCTH Accuracy stat, instead of handling, which I'm using to represent the ergonomics of operating a specific weapon. Additionally I haven't addressed the issue of built-in iron sights, beyond giving all rifles a 10 bonus to NCTH Cap, and having all scopes erase that bonus. 1st Gen Tavor-21's have integral scopes, and therefore don't express a 10 NCTH Cap bonus (the scope bonuses more than make up for this).

[Updated on: Sun, 25 December 2011 15:12] by Moderator

Report message to a moderator

Lieutenant

Re: HAM 5 Alpha - You know it!![message #295696] Sun, 25 December 2011 15:22 Go to previous messageGo to next message
Alex_SPB is currently offline Alex_SPB

 
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg
Hmm, what does the tag mean? I have not seen this before in earlier version of HAM, there only was in weapons.xml

Report message to a moderator

Staff Sergeant
Re: HAM 5 Alpha - You know it!![message #295697] Sun, 25 December 2011 15:32 Go to previous messageGo to next message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
I'm on my way out the door right now, so I'll quote ChrisL from the NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags) thread:

ChrisL
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.



Now of course, I started that thread before Headrock became active on the forum again, so now we have two perspectives on NCTH mechanics. 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.

Report message to a moderator

Lieutenant

Re: HAM 5 Alpha - You know it!![message #295698] Sun, 25 December 2011 15:34 Go to previous messageGo to next message
Alex_SPB is currently offline Alex_SPB

 
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg
@wil473:

Have not seen you post prior to writing the previous comment. 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.

[Updated on: Sun, 25 December 2011 15:37] by Moderator

Report message to a moderator

Staff Sergeant
Re: HAM 5 Alpha - You know it!![message #295712] Sun, 25 December 2011 21:52 Go to previous messageGo to next message
Soren is currently offline Soren

 
Messages:13
Registered:December 2011
One more 'feature'? Or maybe it is a bug ...

Inseparable Default Attachments are immutable.

To expand:
Initially (before I had forum access, back in like 5.1), I made integral stocks inseparable. Of course, they are default attachments, too. However, if you tried to transform them (this was before the nasty crash bug, which was recently fixed in 5.5+), they would LOOK like they switched in the UDB panel (name would change, as would the stats), but when you closed the UDB panel, the stock remained in the original state (whichever one is defined as the default attachment). You could unattach the stock (Shift+F), and then transform it, as well as reattach it, but once again if you tried to transform it, it 'stuck' in the default state.

To fix it, I simply made the integral stocks non-inseparable (that is, normal), and the problem disappeared.

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)

Report message to a moderator

Private
Re: HAM 5 Alpha - You know it!![message #295713] Sun, 25 December 2011 22:36 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
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.


From what I saw, the values in 1.13 are actually 1:1 with the Draw costs. I.E. the end result was just copying all the values from APtoReady to Handling. Maybe I'm mistaken. What I think may be true is that Starwalker added various modifiers based on internal attachments (folding stocks, primarily) to differentiate some weapons...

But I don't know this for a fact - I was not around at the time, so it's just my impression.

Quote:
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.


Yeah, I really should get to doing that. The thing is I want to finish playing the game first - I've been gone too long to work on this without some proper hands-on experience. Can't learn the code as well if you don't know how it behaves in game. So it'll probably take a little longer.

Quote:
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.


Yes, Chris spotted and fixed this almost straight away - it was something I had planned to do and left quite unfinished, so it's a good thing it wasn't left the way it was. Of course, had he not done it, I would've done it as the first HAM 5 feature... In either case, it works AND is displayed in the UDB so you can see the value for yourself. The modifiers for it appear in the ADVANCED tab, since they are stance-based.

Quote:
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).


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.

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


True and false there.

On the visible aperture size: It was originally intended to show ONLY the shooter's effect on the shot. Accuracy was not shown; as I saw it, there was no reason to show accuracy in the targeting cursor at all, because UDB already gives us the exact value (which is used as-is by the firing mechanism).

ChrisL argued that accuracy should be shown as part of the aperture cursor, and for that he introduced a little "cheat": expanding the visible aperture by the maximum deviation of the bullet, thus giving a visible effect of larger apertures for less-accurate guns. This effectively discourages things like pistol shots to sniper ranges, because the player can clearly see that he's got no chance in hell, even with the best possible scope and the best shooter.

However this is still a cheat. The reason is that system-wise, accuracy and aiming are entirely separate. There is actually no good way I can think of of showing the both of them simultaneously at all. So the expansion effect is, to some extent, misleading. Whether or not accuracy should be factored into the visible aperture size or not is therefore a tangled discussion.

So yes, initially the cursor showed only aiming, as originally intended. Right now, the cursor is adjusted based on accuracy as well, but in a misleading way. In truth, the two are utterly separate. The muzzle is aimed first, then set to a random direction, then the bullet's trajectory is set along another random direction related to the muzzle's new angle. One depends on the other, but they do not interact.

------------

Answer to Soren in the next post.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295714] Sun, 25 December 2011 22:47 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
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.


What you described about causing a change that only affects UDB (and doesn't affect the actual item) is known to me, and is something I've been grappling with. I thought I got rid of that problem though, so learning that it still occurs with some attachments is puzzling.

Fortunately I know where to look for the problem, so it shouldn't be too difficult.

Quote:

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


No, it's good that you reported it. I'll have a go at this tonight, if I can make the XMLs for it...

Quote:

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


Very Happy

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295716] Mon, 26 December 2011 00:30 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
@ Soren:

I've managed to reproduce the bug, and even discovered why it is happening. Unfortunately, the fix may be extremely difficult to implement. I'm going to need to discuss it here because it's hard figuring it out for myself to begin with.

The error occurs when checking whether the parent item (in this case, a gun) can take all of its attachments after one of them (the inseperable one) is altered.

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.

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.

Actually that's what's "supposed" to happen - but there's an extra problem that causes this EVEN WEIRDER thing to happen:

A) The 2x Scope isn't erased, because we've already changed the item into a 4x scope by this point.
B) The 4x scope and any other attachments are copies into memory.
C) All attachments are erased from the gun.
D) A new 2x Scope is attached to the gun.
E) The game fails to put the 4x Scope on the gun, and seeing that it is an inseperable attachment itself, simply deletes it!
F) All other attachments in memory are reattached.

So there are several problems to solve here - unfortunately I have no idea how. For one, the function I'm using appears to be extremely important, so I can't easily change it. Furthermore, if I did change it somehow, it's possible that any other transformation you perform would again cause the gun to have a 2x Scope.

And of course, how do I even begin to instruct the program to do this correctly? I'd need to figure out how to not create a new default attachment in the same slot as the one that was transformed, and that could be even more tricky...

So I'm going to have to put this off until I can have a long and thorough examination of this problem with Warmsteel (who wrote the function I'm using) to see if there's any decent way out. I don't know how long this will take...

Also in the event that we do fail to solve the problem, what should happen? Should default inseperable attachments be impossible to transform? If so, what happens to internal stocks in some systems?

This is very confusing...

[EDIT: BTW, I see one reasonable way out of this issue: Make two identical versions of the gun itself, but with two different default attachments set for the two versions. Transforming the gun would transform the attachment without changing anything else. Yeah, it's an ugly workaround, but it will achieve the same thing you've been trying to do - and with even fewer clicks...]

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295717] Mon, 26 December 2011 02:09 Go to previous messageGo to next message
CptMoore

 
Messages:224
Registered:March 2009
Headrock
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.


Where is the actual step where 2x becomes 4x? I'm very confused about this being the expected behaviour.

Report message to a moderator

Sergeant 1st Class
Re: HAM 5 Alpha - You know it!![message #295718] Mon, 26 December 2011 02:42 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
It happens just prior to this function being run. I can't explain in too much detail though.

The problem all stems from the fact that the function I'm using will attempt to reinstall all the default attachments on the gun BEFORE its original attachments (i.e. the ones it had prior to the transformations) are reattached to it. The function is SUPPOSED to do this, but of course for transformation purposes it's not a good idea: if we transform a default attachment, the above doesn't happen correctly and we end up with the same attachment instead of a new one.

I've talked with Warmsteel about this and he's suggested using another function which works in a different way. Unfortunately, that function is written a little cryptically (and we've already spotted at least one thing that makes absolutely no sense in it). So I have no idea what will actually happen if I tried using it instead - or (if it worked) what situations it would screw up.

This is very tricky stuff here.

[EDIT: For those of you interested, the function I'm running is ReInitMergedItem(). It runs AFTER the attachment has been changed to a new usItem. Warmsteel suggested using RemoveProhibitedAttachments() instead.]

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295730] Mon, 26 December 2011 17:12 Go to previous messageGo to next message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
Headrock
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.


Sure, and and I think I may have been thinking this when I gave all Long Arms a +10 Cap bonus.

I think my next project will be to start thinking of better representation of built-in Iron Sights (which will of course factor in sight length). The way things are setup right now, I'm thinking of doing the following:

NCTH Cap = accuracy of iron sight

AK's have their own scopes/adapters = all AK's can share a NCTH Cap value that represents specifically lower than average accuracy of the built-in sighting gear

H&K G3/MP5 have their own scopes/adapters = all G3/MP5 weapons can share a NCTH Cap value that represents the specifics of the H&K drum/diopter sight

Most AR-15's are of the flat top variety = an attachment can handle the sights for most AR-15's, must be removed for a scope to fit.

The important thing in this system is that the Iron Sight effect be nulified when a scope is attached. ie. +7 Cap bonus on AK's = -7 Cap penalty on P.O. 3.5x21P Scope, Kobra Reflex, etc...


Re: the issue with inseparable attachments. Somewhat wary about possible work there, several weapons have attachments that appear and disappear between item transformations of the base weapon. At the same time, the "bug" sounds like it may affect plans for a variable power OICW computerized sighting system (the sights are planned to be inseparable attachments, and one must be a default attachment). I've got a day off tomorrow and wanted to get some work in on this.

Report message to a moderator

Lieutenant

Re: HAM 5 Alpha - You know it!![message #295734] Mon, 26 December 2011 19:08 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Well, as I said it's possible that the only real solution to this problem would be that to change default inseparable attachments you'd need to make two copies of the same gun with different defaults.

Instead of this:
G36 with default inseperable 2x optics.
--------------------
2x can transform into 4x
4x can trasnform into 2x


You'd have this:
G36 with default inseparable 2x optics (weapon A),
G36 with default inseparable 4x optics (weapon B), not buyable
--------------------
Weapon A transforms into Weapon B
Weapon B transforms into Weapon A


Not sure there IS any other solution...

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295745] Tue, 27 December 2011 02:29 Go to previous messageGo to next message
Soren is currently offline Soren

 
Messages:13
Registered:December 2011
The question in my mind is how vitally important the problem is. Given how the code works, it seems there is no logical workaround without building a separate set of tools to handle transformation (you'd have to hold everything in memory for a bit, which is not really how JA2 seems to handle items).

In my case, I really don't think it's a big deal that I can 'remove' an integral stock or bipod. They're only valid attachments on guns that have integral stocks or bipods, and if you buy one from BR, you get one already. The value of said stock or bipod is zero, the weight is near zero, no one will buy it from me. The only reason to save an integral stock/bipod is as a replacement or if the enemy drops a gun without an integral accessory.

If you define your integral items like that, I think it is unnecessary to make them inseparable. Just make sure the gun can't take anything else at that slot either.

Report message to a moderator

Private
Re: HAM 5 Alpha - You know it!![message #295764] Tue, 27 December 2011 11:17 Go to previous messageGo to next message
JMich is currently offline JMich

 
Messages:546
Registered:January 2011
Location: Greece
Headrock
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.


Proposal, though I haven't seen the function yet, so not sure if it can work or not

A) Transform the Attachment
B) All attachments are copied to memory.
C) All attachments are erased from the gun.
D) All attachments in memory are reattached.
E) Any missing Default Attachments are attached

Wouldn't a simple change in the order of the functions solve this problem? It would require a bit more memory, since you'd have to copy all attachments to memory first, but isn't this the same procedure as with any gun that doesn't have any default attachments?

Report message to a moderator

First Sergeant
Re: HAM 5 Alpha - You know it!![message #295792] Tue, 27 December 2011 15:22 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
That's the theory, but as far as I understand it there was a reason why default attachments were being added first. Don't ask me what the reason is though - I'm having trouble understanding NAS altogether.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295800] Tue, 27 December 2011 16:46 Go to previous messageGo to next message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
Now that I'm not rushing off to work today, time to think about the whole transforming default attachment issue - and came up with a naive and probably silly question: 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?

Would it not be easier to stipulate that for transforming default/inseparable attachments, the most the game does is: 1) check that the attachment is in Attachments.XML 2) check that there is a viable (empty or the created attachment fits the same slot as the former default/inseparable attachment) NAS slot available, the transform does not happen if neither condition is met?

Now already I see a problem, with the above, what if after the default/inseparable attachment is transformed, the base item is transformed into something that has different default/inseparable attachments.

Example: Beretta ARX-160
- has folding stock
- will have a multi-mode scope (for the purpose of this discussion, a default/inseparable attachment)
- Multi-Mode Scope (MMS) has 2x and 4 x variations, both are inseparable, and the 2x also a default on the "Beretta ARX-160"

Case 1) Base item transform - How things work right now (and I'd like to keep working for base items)
- stock folds, "Beretta ARX-160" transforms into "ARX-160 Folded Stock"
- no change to the MMS 2x if it is present, otherwise the MMS 2x appears if it was missing on the original "Beretta ARX-160" was missing it due to known Map Editor issue
- This is Warmsteel's code that I've been leveraging for features and workarounds.

Case 2) Default/Inseparable Attachment Transform - The Problem, Part I (as I'm reading it)
- MMS 2x item transforms to the MMS 4x
- conceptually should not affect other attachments, as the modder is responsible for making sure the MMS 2x and MMS 4x fits the same slot properly

Case 3) Base Item Transform After Default/Inseparable Attachment has been transformed, The Problem, Part II
- start condition: "Beretta ARX-160" with a MMS 4x instead of the default MMS 2x
- stock fold: "Beretta ARX-160" item transforms to "ARX-160 Folded Stock"
- the problem is, how to handle the MMS 2x default/inseparable attachment vs the MMS 4x inseparable attachment that is attached at the time

Case3, Option 1) modders are responsible for not allowing Case 3) to occur, the ARX-160 MMS does not need to be an inseparable attachment

Case3, Option 2) present inseparable attachments take precedence, any inseparable/default attachments defined in Items.XML that cannot find a NAS slot to fit into are simply not added to the created base item
- "Beretta ARX-160" item transforms into "ARX-160 Folded Stock," the MMS 4x stays put, no MMS 2x is created despite it being a default/inseparable attachment for the "ARX-160 Folded Stock"

Case4, Option 3) Items.XML default/inseparable attachments take precedence, all inseparable attachments that cannot find a find free NAS slot after the base item transforms are simply discarded from the game (not dropped)
- "Beretta ARX-160" item transforms into "ARX-160 Folded Stock," the MMS 2x appears, the MMS 4x dissappears

Report message to a moderator

Lieutenant

Re: HAM 5 Alpha - You know it!![message #295808] Tue, 27 December 2011 19:22 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
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?


I'm not much in favor of leaving this up to modders to figure out, unless I find no other option. The game has to check whether the new attachment fits in the same slot it occupied previously, and if not, move to any other slot it can occupy, and if not, be dropped to the inventory after transformation.

This is what Warmsteel's function does, and it should do this. The primary reason, I imagine, is that NAS slots can change for all sorts of reasons. So until we transform the attachment, we don't actually know what slots the weapon will have after the transformation.

Example:
Attachment A unlocks three new slots. All three are filled with other attachments.
Attachment A transforms into Attachment B.
Attachment B only unlocks two new slots. One existing attachment must be removed or moved to another slot.
This means we need to run through all attachments and check their validity. And move them to appropriate slots or to the inventory, if they aren't valid.

So in theory, I could modify the function -- or create a copy thereof -- so that only transformation or merger of the gun itself will trigger recreation of its inseparable default attachments. However, in the above example this may cause all sorts of weird shit...

Of course in practice I have no idea how the attachment slot system works to begin with... it's very complicated stuff and I don't have the time or strength of will to study it. But I do understand that this revalidation of the attachments after a merger (or in this case transformation, same thing) is required to avoid issues.

In addition, there could be all sorts of combinations we cannot even begin to anticipate. What if the transformed item is NOT inseperable, for instance? Or if the gun has default attachments that are seperable, like (I think) the SVD?

This is very confusing stuff.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295809] Tue, 27 December 2011 19:40 Go to previous messageGo to next message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
Default attachments that are not inseparable should never be created from mergers or item transformations due to the exploit potential. ie. unlimited supply of scopes EDIT: 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.

[Updated on: Tue, 27 December 2011 19:42] by Moderator

Report message to a moderator

Lieutenant

Re: HAM 5 Alpha - You know it!![message #295814] Tue, 27 December 2011 20:49 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Quote:
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.


... Well you're the table guy Wink . I'm just the guy who's supposed to make the desired results work Very Happy

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.

Report message to a moderator

Sergeant Major

Re: HAM 5 Alpha - You know it!![message #295815] Tue, 27 December 2011 21:16 Go to previous messageGo to previous message
Wil473

 
Messages:2815
Registered:September 2004
Location: Canada
Guess I did volunteer for the work. Either we're all thinking about this too hard, or we will end up with a mess...


Headrock
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.


Sorry, forgot to specify that I was only planning on using this for "Optional-but-Necessary" attachments such as AR-15 stocks (of which my projects only have three). Basically gun components that we're using attachments to portray. The attachments bug notwithstanding, I was planning on doing this as a quick workaround to Shift-F stripping off the AR-15 stocks after I re-enabled it in AFS v3.60RC HAM5. Thought this would be better than earlier discussions on adding a tag that controlled whether an attachment was removed by Shift-F, or that duplicate default attachment system that the now missing Cell/Monade was suggesting.


EDIT: I think all I managed to do was come up with a wish list of how item conversion (same system for both mergers and HAM 5 Item Transformation) should handle attachments under NAS. The term "Valid" simply means the attachment is on the base items attachments list. Please advise if I'm missing any scenarios: Merger/Item Transformation Attachment Handling Cases

[Updated on: Tue, 27 December 2011 22:05] by Moderator

Report message to a moderator

Lieutenant

Previous Topic: New: Alternative IMP Backgrounds Selection
Next Topic: New Animations
Goto Forum:
  


Current Time: Mon Jun 17 01:58:21 GMT+3 2024

Total time taken to generate the page: 0.02797 seconds