Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes
( ) 1 Vote
|
|
|
|
| Re: Absurdly small code changes[message #349241 is a reply to message #348765]
|
Sat, 11 March 2017 21:01  
|
|
| Flugente |
 |
Messages:3507
Registered:April 2009
Location: Germany |
|
|
While not a bug in the pure sense, a very annoying (and for some reason never fixed) oddity is that if troops spawn at the very northern edge of a sector, we often barely see them, and cannot target their head or torso. To stop that from happening, I've altered the code a bit in r8395 - we simply do not spawn there.
@Torres: If it is turned on, pressing [Tab] + [Ctrl] while clicking on an item will mark it as 'do not move via GET_ITEM assignment'.
[Updated on: Sat, 11 March 2017 21:07]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
| Re: Absurdly small code changes[message #350141 is a reply to message #349241]
|
Wed, 21 June 2017 10:50
|
|
| Deleted. |
 |
Messages:2657
Registered:December 2012
Location: Russian Federation |
|
|
New option ENEMY_JAMS in [Tactical Gameplay Settings] allows enemy gun jams.
;------------------------------------------------------------------------------------------------------------------------------
; Enemy gun jams
;------------------------------------------------------------------------------------------------------------------------------
ENEMY_JAMS = TRUE
Added in r8409.
Also AI_BETTER_COVER option is improved:
- use AI knowledge for enemy location when testing for LOS
- check 2xDay_Vision_Range to take into account possible scopes
- prefer positions behind structures
- less aggressive behavior when soldier has some cover and there are more recently seen enemies than friends nearby
[Updated on: Wed, 21 June 2017 10:50]
Left this community.Report message to a moderator
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #350386 is a reply to message #350143]
|
Tue, 25 July 2017 20:13
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
As the 2017 convention at smeag's place is now over and was officially fun and successful, it's time to push the results to the trunk. In that regard, I begin with something small, simple but nevertheless useful:
Cannibalization. The issue is the following: quite often, especially in early-to-mid gamestages, you find guns that are better than what you are currently using. But these guns are often in a dreadful state, making them to unreliable to use. For example, let's say our girls want to use the SIGs they've found here:
Now, you could repair them, but that would take hours - time you often don't have or don't want to wait, especially in the middle of taking a city.
This feature solves that. You can merge a gun with an identical gun (so same item number).
This will increase the status and repair threshold of gun A, but lower status and repair threshold of gun B a lot more.
As a result, assuming gun B wasn't already scrap to begin with, gun A will now be useable. Not in perfect condition, but definitely useable. Gun B will be in a lot worse condition though. Think of it as the merc replacing everything broken in A with parts from B if feasible.
- A gun can be improved by this up to 90% status. The merge won't work over that.
- The gun 'used' up needs to have at least 20% status, and it's status won't be lowered below that. The merge won't work under that.
- The higher the status of the used gun, the more status can be improved.
- For every point status increased, 2 points status are used up on the other gun.
- These values are hardcoded, and won't be moved to the ini unless someone can give me a very good reason to. I've just about had it with this anal fixation on moving every stupid number to the ini and then complaining that there are so many options.
- There is no tag that determines whether this works on an item or not. This will work with every gun and launcher. This obviously will stop anyone from attaching a gun on itself, but nobody at the con could think of any reason that would ever be useful, so no loss here.
This has been added to the trunk in r8426.
[Updated on: Tue, 25 July 2017 20:14]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #350388 is a reply to message #350387]
|
Tue, 25 July 2017 21:27
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
As of r8428 & GameDir r2378, the Ambidextrous trait property PENALTY_TO_SHOOT_DOUBLE_GUNS_REDUCTION reduces cth penalty for having any item in offhand, not just if it is a handgun.
Considering that dual-wielding guns is stupid in RL anyway, it never made sense that one could aim better down 2 different sights than 1 sight while the other hand grabs something.
Additionally, this change will also be useful in a feature to be committed very soon 
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #350391 is a reply to message #350390]
|
Tue, 25 July 2017 22:36
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
I want this feature to be as easy to use as possible, so no to that.
As we have no way to determine which guns are similar, we'd need several new tags to determine which guns are similar to what other guns.
Besides, I know this community. Someone is going to have a violent heart attack if I would dare to say that M16 variant #123 could easily be repaired with M16 variant #47 because they're just copies of the same thing with trivial differences 
[Updated on: Tue, 25 July 2017 22:36]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #350393 is a reply to message #350392]
|
Tue, 25 July 2017 23:06
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
If we tie this to merc skills, then one always has to select the best fitting merc, or move a fitting merc to the sector etc.. Which is just tedious.
90% seemed like a good value. As far as I remember from the last time playing, quite a few guns are already hideously unreliable at 80%. Besides, we also all but destroy the merged guns this way, so this isn't exactly free.
[Updated on: Tue, 25 July 2017 23:06]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #350400 is a reply to message #350399]
|
Wed, 26 July 2017 16:49
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
Another result of this year's convention is a new skill for our mercs: Focus.
This basic idea is that during a firefight, mercs with sufficient training can focus all of their attention on a specific area when they are already aiming down their sights. Like, say, a sniper expecting someone to step out of a doorway.
As a result, such a merc would get a huge interrupt modifier bonus. The downside would be that they cannot pay as much attention to the rest of the battlefield - they receive a huge interrupt modifier penalty outside of that area.
This skill can simply be activated via the skill menu [$] in tactical:
This skill is available to any merc that possesses a gun-related trait (Auto Weapons, Heavy Weapons, Sniper, Ranger or Gunslinger).
As seen, the skill also requires that the merc is aiming down the sights of their gun, and only works while looking in the direction of the area targetted. Changing direction or lowering the gun deactivates the skill.
The radius of the area depends on the range of the merc to the center of the area - the further away, the bigger it gets. You can actually see it shrinking if you walk towards it in a straight line with your gun raised.
The blue circle marks the area. For performance reasons and in order not be needlessly confusing, it is only drawn if the merc using focus is currently selected.
A merc with this skill active also has a small icon on their face. Because we already had that in our .sti libraries and I find it slightly amusing, I decided that the Mark of Khorne now denotes this skill. It's not like any of you corpse god worshipers will ever draw a replacement anyway
The base radius (FOCUS_SKILL_RADIUS) and interrupt bonus (FOCUS_SKILL_INTERRUPT_BONUS) are set in Skills_Settings.ini under the [Sniper section]. The values are the same for all traits though, but I needed to put them somewhere.
The penalty outside of the area is 2 * FOCUS_SKILL_INTERRUPT_BONUS.
This is savegame compatible.
This has been added to the trunk in r8432 & GameDir r2380.
[Updated on: Wed, 26 July 2017 17:35]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #350774 is a reply to message #350418]
|
Tue, 29 August 2017 01:15
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
When stacking items, like via the buttons in strategic inventory, we often merge ammo and kits. This often leaves one item on the stack only partially full, unfortunately the last one. As the player only sees the status of the first item in a stack, this means that we might be in for a bad surprise later (like when we drop 2 mags into our inventory, only to later find out one of them only has 1 bullet).
As of r8463, when stacking ammo or kits, the partially full object will be the first instead of last on the stack. At least for most ways of stacking things, we do that quite often all over the code, not always with the same functions.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
| Re: Absurdly small code changes[message #351107 is a reply to message #350774]
|
Sun, 24 September 2017 18:49
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
Squadleaders boost the level of lower-levelled mercs near them (EFFECTIVE_LEVEL_OF_OTHERS_IN_RADIUS in Skills_Settings.ini). This is all well in tactical. However this bonus to level is also used in strategic for all matter of assignments. This leads to the odd effect that one can, for example, raise Buns militia training points from 58 to 63 by just placing Len near hear. Similar, Vicki will be worse at, say, doctoring if we left her on a roof the last time we were in tactical.
As these boni were meant to apply in tactical only, they now no longer use the above behaviour as of r8479. This might be somewhat controversial - some on the Discord channel argued that the bonus should apply in strategic without even checking for physical proximity, but I disagree.
[Updated on: Sun, 24 September 2017 18:50]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #351135 is a reply to message #351108]
|
Fri, 29 September 2017 23:03
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
Well, in any case, I think there is at least a concensus that the status up to now (squadleader bonus secretly works in strategic, but requires to reposition mercs in tactical) was the worst of the solutions.
Anyway, good news for dying people! I applied changes from sevenfm in r8485 & GameDir r2391:
- Dying mercs are no longer attacked by the AI.
- If REDUCED_INSTANT_DEATH is set to TRUE (default is FALSE), damage from guns/knives that would normally instantly kill non-comatose player-controlled mercs is lowered so that they instead fall into a coma (and can be saved by other mercs).
Note that this does not apply if the attack caused a special death animation to play - no, you cannot survive your head exploding. This can also be circumvented if the damage is stupid high (taking a 7.62 NATO Glaser burst to the face is still kinda final). I also said guns, not bullets, so frags should not be affected by this.
As to the motivation for this addition, I'll just quote DepressivesBrot, as he summed it up very well:
DepressivesBrot
it is and interesting question. on one hand, it goes against the whole 'hardcore' aura we've got going, on the other ... something that reduces insta-alt+l and leads to those awesome "and then I threw down a smokescreen and grizzly rushed in to drag that guy out and spider got her gloves on and buzz was just ripping through belts suppressing everyone ..." stories instead sounds worthwhile to me
Also, before anyone gets any ideas here: I am not currently merging sevenfm's changes into the trunk, as I don't see that as my job.
[Updated on: Sat, 30 September 2017 14:10]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
| Re: Absurdly small code changes[message #351407 is a reply to message #351135]
|
Wed, 01 November 2017 01:01
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
As of r8504, additional battlesounds (the small soundbits that play whena merc confirms orders, picks something up etc.) can be added to the BattleSNDS folder. To be precise, up to 2^16 per sound and merc. Simply add a file with the same name as the first file and number them at the end.
Due to legacy reasons, file number 1 can also have no number (so both 212_HUMM.wav and 212_HUMM1.wav are allowed). To be clear, numbers have to be ascending. If you have file xxx3, it will only be used if xxx2 is also present.
I deem this feature rather useful, in case someone has spent the last week ripping soundfiles from a RPG and is now sitting on over 300 MB of potentially useful .wav files per merc  . I have 30+ files for just the 'OK' command, you can bet your ass I'm gonna use more than 2 
This is not optional, because why the hell would it. It won't be of much use for existing mercs, but more for new ones. The same trick won't work with normal dialogue, as that also requires accompanying text in .edt files. Need to create something trickier there.
I also recently changed a few enums, this should make it easier to understand what a sound file does, and to search for all buddy/hated dialogues.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #352503 is a reply to message #351415]
|
Wed, 21 February 2018 20:56
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
I haven't posted in here for a while, due do me not coding for a while, so here are a few things from the past:
- r8512: Fix: during hiring, AIM mercs only complained about their hated ones if these were already in the country, thus ignoring other mercs in transit.
- r8521: If PRINTOUTTILESET is TRUE, also print out the room number when pressing 'f'. This is very useful in case you are a modder who, say, wants to add room-based content to a script.
- r8523: If ENHANCED_CLOSE_COMBAT_SYSTEM is on, stealing multiple items from an enemy is possible if he is not on alert. Previously this was not possible unless the other guy was collapsed. I'm not sure why this was the case in the first place, and Sandro isn't around... so this is likely a good compromise.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
| Re: Absurdly small code changes[message #352514 is a reply to message #352503]
|
Thu, 22 February 2018 20:59
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
In my personal opinion, the <bEvolution>-tag in MercProfiles.xml is one of the most stupid, infuriating things in this game. In case you do not know, <bEvolution> affects how fast we gain stats, in addition to the regular stat gain code:
- 0 - we gain stats normally
- 1 - we do not gain stats at all
- 2 - we loose stats when we would normally gain them (apart from training, which does nothing for us).
- 3 - we gain stats at 75% of the normal speed
- 4 - we gain stats at 50% of the normal speed
- 5 - we gain stats at 25% of the normal speed
The bizarre settings 1 or 2 are mostly set to old mercs. But don't affect all old mercs. Unless you scan MercProfiles.xml for this specific tag, you have no clue about this. The bios don't tell you. Nothing tells you. This gets a lot more frustrating when you consider that anyone who isn't extremely familair will have no clue such a thing even exists. What tops the bullshit is that MercProfiles.xml is read into a savegame at the start of the game. Changing that xml will not affect an ongoing campaing (for code-related reasons that are somewhat justified and not the issue here).
If I recall I wanted to change that some years ago, and someone else said 'better not, it's a vanilla code, don't delete a feature' or something like that, don't remember exactly. That doesn't change the fact that explaining to a enthusiastic newbie that
- yes, that merc you hired won't learn anything
- no, that's not a bug. It's a feature!
- well, you can change that, but you have to restart the entire campaign
is not exactly a fulfilling approach.
As deleting that tag is apparently a no-no, I've decided on a compromise: as of r8525 & GameDir r2405, if DISABLE_EVOLUTION in JA2_Options.ini is now set to TRUE (it's default value, because I say so), this tag will be ignored. No more half-learning, or not learning, or negative learning. Any newbie not knowing that mechanic (which is, well, everybody really) won't experience that frustrating tidbit. Any hardcore classic gamer can simply alter that option and experience it as always.
[Updated on: Thu, 22 February 2018 21:01]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #353156 is a reply to message #352618]
|
Sun, 15 April 2018 17:49
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
Among other things in r8554, I fixed a bug during autoresolve. Melee damage calculations assume that one is in tactical, which can be exploited in autoresolve:
- if we melee a prone target, we deal +30% damage. A target's stance otherwise is not regarded in autoresolve.
- if we attack in spinkick animation (which happens theoretically if we leave the sector on the right frame), we deal +50% damage.
- if our target does not see us, we deal +50% damage. Sight depends on sight line, so if your target did not see us when we left tactical, that always applies.
As a result, it was possible to deal huge amounts of damage in autoresolve, which one finds out when dealing with melee-only type of enemies :-)
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
| Re: Absurdly small code changes[message #353257 is a reply to message #353156]
|
Sat, 21 April 2018 11:33
|
|
 Jolly_Reaper |
 |
Messages:47
Registered:August 2002
Location: The Netherlands |
|
|
So I've been going through the .xml files, doing my best to remove spelling errors and so on.
Unfortunately, I have greatly underestimated the amount of work this is going to take, since I feel that a lot of things not only need error correction, but complete rewriting.
There are texts that simply do not make sense, expressions that are used incorrectly, and texts that could be made a lot more compact by removing redundant words, or through reformatting.
Right now, I can't commit the time that it would take to do all this. It would likely take me months. Seeing as I am not a native English-speaker myself, I'd need to double-check everything I change as well. And, well, I don't know if there's a real interest in this.
So I basically went through all the .xml files right now, and I made a lot of changes (especially in items.xml, which was a slog to get through), but I feel work has only started.
I'll provide a link to what I've done, in case you want to use it, but in all honesty, to me it feels like I'm providing something that's simply unfinished, something that's barely even started.
Decide for yourself if you want to use this: https://avatar.home.xs4all.nl/TableData_8548.rar
I hope that the future will allow me more time to perhaps overhaul everything. Boy, you don't even know how many items 1.13 really has, until you go through the descriptions of every last one of them. 
Report message to a moderator
|
Corporal
|
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #353514 is a reply to message #353263]
|
Wed, 16 May 2018 02:19
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
In my ongoing series stupid code that doesn't make any friggin' sense, episode #2073:
Inside a function calculating the damage of a weapon (luckily it is only used for display uses)(nope, is indeed used all over the place):
UINT8 GetDamage ( OBJECTTYPE *pObj )
{
...
ubDamage = (UINT8)GetModifiedGunDamage( Weapon[ pObj->usItem ].ubImpact );
// modify by ini values
if ( Item[pObj->usItem].usItemClass == IC_GUN )
ubDamage *= gItemSettings.fDamageModifierGun[ Weapon[ pObj->usItem ].ubWeaponType ];
// WTF? Why do only small weapons get their damage bonus?!
if (FitsInSmallPocket(pObj) == true)
{
ubDamage += GetDamageBonus(pObj);
}
...
}
I have no bloody clue as to why we we'd apply attachment boni only if the weapon fits into small pockets. Removed in r8561.
[Updated on: Wed, 16 May 2018 02:42]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
| Re: Absurdly small code changes[message #353533 is a reply to message #353514]
|
Thu, 17 May 2018 00:15
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
When we use buckshot or similar ammo that fires several projectiles at once, we have no clue (apart from looking at the xml) how many bullets we fire, and what their (normally reduced) damage will be. Thus as of r8562, the damage of guns using multi-pellet ammunition will be stated in the damage per bulletXnumber of bullets format (why yes, I do play Borderlands).
Buckshot
Flechette
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Absurdly small code changes[message #353657 is a reply to message #353656]
|
Sat, 02 June 2018 04:23
|
|
| Flugente |
|
Messages:3507
Registered:April 2009
Location: Germany |
|
|
While I'm creating a new RPC, I stumbled upon the fact that it was impossible to satisfy any .npc script condition with an opinion threshold > 0. The reason is an ancient bug. I'm not sure how ancient, the svn history of the source file only goes back to February 2010 and I'm not that interested in learning more (it's not my fault, which is the most importantl fact ).
When talking to an NPC, we not only take into account our leadership, opinion, approach factor, personality and zodiac sign, but also the NPCs approachability. These values used to be in the old internal merc profile structure, which was read from Prof.dat. At some point, the MercProfiles.xml was introduced. At some point, these values were no longer read from the xml. Not sure when, doesn't matter.
A smart person might say "Now hold on there, Flugente. I've set READ_PROFILE_DATA_FROM_XML to TRUE, and can still pass NPC opinion checks if I talk to them with sufficient leadership, so you are wrong!".
HA! I laugh at your naivety. HA!
The ini says:
; If TRUE, reads "MercProfiles.XML" and "MercOpinions.XML" for profile data.
; If FALSE, reads profile data from PROF.DAT.
READ_PROFILE_DATA_FROM_XML = TRUE
In fact, that is not entirely true. We always read from Prof.dat. If READ_PROFILE_DATA_FROM_XML is true, we simply overwrite parts of that with the xml (this really isn't simple at all, as we read that xml again and again and do... stuff... but that's not relevant to the point).
As a result, the old Prof.dat approachability values were always read and used. But as we only read Prof.dat values up to profile 170, profiles > 170 will not have those, and can't get them from the xml. Which you only notice if you create an NPC with an opinion check and profile > 170.
As I don't intend to add 16 new tags to the xml, I've simply added dummy values for all profiles > 170 in r8566.
To be precise, ubApproachVal is now 50 and ubApproachMod is 100 for all approaches, with the calculated approch val thus equaling to the merc's effective leadership (if you are not reading the code, this will likely be confusing).
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
Goto Forum:
Current Time: Fri Dec 13 17:39:56 GMT+2 2024
Total time taken to generate the page: 0.03179 seconds
|
Blog
Search
Help
Members
Register
Login
Home
