Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Re: Absurdly small code changes[message #348587 is a reply to message #348585] Tue, 31 January 2017 00:01 Go to previous messageGo to next message
Vincent J. Claymore is currently offline Vincent J. Claymore

 
Messages:285
Registered:February 2011
So 100% now has the same effect als 100% camo had in Vanilla? Okay, thank you!

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #348765 is a reply to message #348587] Thu, 09 February 2017 03:05 Go to previous messageGo to next message
Torres is currently offline Torres

 
Messages:171
Registered:June 2010
Location: Canary Islands
I opened a thread in the weapons/combat academy forum but I should've asked here, how do you quote people here? @Flugente? I was wondering if you or anyone could help me.

The GET ITEM DISPLAY tab that shows on the top right corner of the sector inventory, what's its function? I know I'm missing something that could be very helpful.

Thanks in advance!

Report message to a moderator

Staff Sergeant
Re: Absurdly small code changes[message #349241 is a reply to message #348765] Sat, 11 March 2017 21:01 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #350141 is a reply to message #349241] Wed, 21 June 2017 10:50 Go to previous messageGo to next message
Deleted.

 
Messages:2663
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

Lieutenant

Re: Absurdly small code changes[message #350143 is a reply to message #350141] Wed, 21 June 2017 18:15 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Ah, I see you are migrating features from your experimental build to the dev trunk. Nice! thumbs up


Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #350386 is a reply to message #350143] Tue, 25 July 2017 20:13 Go to previous messageGo to next message
Flugente

 
Messages:3509
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:
http://i.imgur.com/OCt4rZF.png
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).
http://i.imgur.com/zLutkW0.png
This will increase the status and repair threshold of gun A, but lower status and repair threshold of gun B a lot more.
http://i.imgur.com/35yngua.png
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

Captain

Re: Absurdly small code changes[message #350387 is a reply to message #350386] Tue, 25 July 2017 20:31 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
A very tiny change: the total weight of equipment is now display in a small tooltip as of r8427:

http://i.imgur.com/n2CtqfU.png



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

Captain

Re: Absurdly small code changes[message #350388 is a reply to message #350387] Tue, 25 July 2017 21:27 Go to previous messageGo to next message
Flugente

 
Messages:3509
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 happy



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

Captain

Re: Absurdly small code changes[message #350389 is a reply to message #350388] Tue, 25 July 2017 22:11 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
As of r8429, the draw functions for the graphical explosion warning (TIME_BOMB_WARNING = TRUE) have been improved:
- the underlying terrain can still be seen, which makes the thing 65% less ugly
- Fix: graphical glitch while scrolling

http://i.imgur.com/YVXCpKW.png



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

Captain

Re: Absurdly small code changes[message #350390 is a reply to message #350386] Tue, 25 July 2017 22:14 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
Flugente wrote on Tue, 25 July 2017 22:13
A gun can be improved by this up to 90% status. The merge won't work over that.

Maybe make this a bit more complex: max status = 85 + bRepairEase, so AK47 will have max 89%, M16 - 85% and G11 - 81%, representing that some weapons are more suitable for 'field repair' than others.

Also, with this feature some weapons with different id's like AK-47 and AKS-47 are treated as completely different though in RL they are nearly identical mechanically and could easily exchange parts.



Left this community.

Report message to a moderator

Lieutenant

Re: Absurdly small code changes[message #350391 is a reply to message #350390] Tue, 25 July 2017 22:36 Go to previous messageGo to next message
Flugente

 
Messages:3509
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 cheeky

[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

Captain

Re: Absurdly small code changes[message #350392 is a reply to message #350391] Tue, 25 July 2017 22:49 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Interesting idea which reminds me of how weapons were repaired at some point in the Fallout series. Still, with no requirements to the merc or equipment in my opinion a max status of 90 is a bit high. I wouldn't go over 80 percent. We are talking about a quick field replacement - no repairs and no cleaning are done here.


Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #350393 is a reply to message #350392] Tue, 25 July 2017 23:06 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #350397 is a reply to message #350393] Wed, 26 July 2017 06:08 Go to previous messageGo to next message
Buggler is currently offline Buggler

 
Messages:211
Registered:November 2009
Seconded sevenfm's bRepairEase modifier. Maybe a different base value or multiplier?
Reason as sevenfm & silversurfer have stated.

Flugente wrote on Tue, 25 July 2017 20:06
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..


Like you have said, think both sevenfm & silversurfer just want some variation for the 'max cannibalization threshold' on different weapons based on ease of repair/weapon complexity, independent of merc skills.



No savegame (just before e bug occurs), no cure.

'Not everything that counts can b counted, n not everything that can b counted counts' - Albert Einstein
I may answer/reply in my old public posts & prefer PM over e former [FUDforum's PM suxx]

Report message to a moderator

Sergeant 1st Class
Re: Absurdly small code changes[message #350399 is a reply to message #350397] Wed, 26 July 2017 12:31 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
The reason why I asked about a lower max status is that now even a dumbass like Raffi can bring any gun to almost perfect condition (raising its repair threshold on the way) in an instant. The modified repair/cleaning system already allows to clean guns quickly in a shorter amount of time than required to repair-clean them with a toolkit. Cannibalizing weapons is a good idea but currently it feels a bit like cheating. In my opinion we shouldn't be able to create almost perfect weapons from crap without further requirements or activities like cleaning and repairs. Even at 80 percent a gun is useful. It will jam sometimes but what can you expect from dirty crap that you just picked up from the ground?

If you are worried about too much micromanagement or too low max status you could make the outcome or possibility of the merge dependent on the merc with the highest stats in the same sector. You could even increase the max status by x * number of Technician traits. Using repair ease on top would be a good modifier for the max threshold as well.

Example:
BaseMaxStatus = 75
StatModifier = (Mech + Dex + 10 * Exp) / 30 (stats are taken from the best merc in the same sector that fulfills the minimum Mech requirement)
TechTraitModifier = number of Technician traits * 2
RepairEaseModifier = Gun Repair Ease Value

First thing I would check is if some merc in the same sector has at least some minimum Mech stat. Only such merc is eligable for the task. We could use IMP_MIN_ATTRIBUTE for that or another hard coded value. This will leave Raffi in a bad position if he travels alone but we all know that he can be happy if he doesn't shoot himself in the foot let alone repair weapons...
If this check is passed we calculate the max status based on above values/formulas. Assuming our best mechanic has 40 Mech stat, 70 Dex, Level 2 and no Tech trait and the gun has an repair ease of 2 we would get:

BaseMaxStatus = 75
StatModifier = (40 + 70 + 10 * 2) / 30 = 130 / 30 = 4 (Integer)
TechTraitModifier = 0 * 2 = 0
RepairEaseModifier = 2

The final max status would be:
75 + 4 + 0 + 2 = 81

An engineer with perfect stats and a repair ease 4 gun could reach this:

BaseMaxStatus = 75
StatModifier = (100 + 100 + 10 * 10) / 30 = 300 / 30 = 10 (Integer)
TechTraitModifier = 2 * 2 = 4
RepairEaseModifier = 4

75 + 10 + 4 + 4 = 93

I guess we should max the value at 90 although a merc with perfect stats is quite impossible to get. ;-)

Just my 2 cents.

[Updated on: Wed, 26 July 2017 12:33]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #350400 is a reply to message #350399] Wed, 26 July 2017 16:49 Go to previous messageGo to next message
Flugente

 
Messages:3509
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:
http://i.imgur.com/Y6VlzOa.png

This skill is available to any merc that possesses a gun-related trait (Auto Weapons, Heavy Weapons, Sniper, Ranger or Gunslinger).
http://i.imgur.com/XbC5ooP.png

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.
http://i.imgur.com/7UZjqI2.png

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 cheeky

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

Captain

Re: Absurdly small code changes[message #350417 is a reply to message #348422] Sun, 30 July 2017 10:45 Go to previous messageGo to next message
GiantBasher is currently offline GiantBasher

 
Messages:41
Registered:July 2017
Excellent feature Flugente. I do like seeing the additional stats. I did notice that under the More Stats tab it reads "Friendly Approach, Direct Approach, Friendly Approach, Friendly Approach". The last 2 should instead read Threaten and Recruit.

Report message to a moderator

Corporal
Re: Absurdly small code changes[message #350418 is a reply to message #350417] Sun, 30 July 2017 12:31 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Hu. Fixed in r8435.


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

Captain

Re: Absurdly small code changes[message #350774 is a reply to message #350418] Tue, 29 August 2017 01:15 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #351107 is a reply to message #350774] Sun, 24 September 2017 18:49 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #351108 is a reply to message #351107] Sun, 24 September 2017 19:30 Go to previous messageGo to next message
edmortimer is currently offline edmortimer

 
Messages:1533
Registered:January 2015
Location: Home Free
I have to respectfully side with the dissenters because a Squadleader's job, in real life, is to maintain the efficiency and cohesiveness of the squad at all times.

Report message to a moderator

Sergeant Major
Re: Absurdly small code changes[message #351135 is a reply to message #351108] Fri, 29 September 2017 23:03 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #351407 is a reply to message #351135] Wed, 01 November 2017 01:01 Go to previous messageGo to next message
Flugente

 
Messages:3509
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.

https://i.imgur.com/LoK3L9u.png
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 You gave me a black eye. I have 30+ files for just the 'OK' command, you can bet your ass I'm gonna use more than 2 confused

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

Captain

Re: Absurdly small code changes[message #351411 is a reply to message #351407] Wed, 01 November 2017 16:12 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
You removed BATTLE_SOUND_HIT2 from battle sound enums, but in the code BATTLE_SOUND_HIT1 is often used as
this->DoMercBattleSound( (INT8)(BATTLE_SOUND_HIT1 + Random( 2 )) );

As a result, enemy soldiers will laugh at you (if you hit them).



Left this community.

Report message to a moderator

Lieutenant

Re: Absurdly small code changes[message #351415 is a reply to message #351411] Wed, 01 November 2017 18:55 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Hmpf. Technically this was already wrong, as BATTLE_SOUND_OK1, BATTLE_SOUND_HIT1 and BATTLE_SOUND_LOWMARALE_OK1 were already sometimes switched to their counterpart in InternalDoMercBattleSound(...).

Anyway, fixed in r8505.



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

Captain

Re: Absurdly small code changes[message #352503 is a reply to message #351415] Wed, 21 February 2018 20:56 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #352514 is a reply to message #352503] Thu, 22 February 2018 20:59 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #352520 is a reply to message #352514] Fri, 23 February 2018 10:14 Go to previous messageGo to next message
pheloncab is currently offline pheloncab

 
Messages:278
Registered:August 2004
Location: So. Cal. or texas
* Applause *

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #352538 is a reply to message #352520] Sat, 24 February 2018 16:00 Go to previous messageGo to next message
Uriens is currently offline Uriens

 
Messages:346
Registered:July 2006
I always hated that 'feature'. It also made me not hire certain mercs, like ever. Gus is one of those that don't learn anything IIRC.

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #352618 is a reply to message #352538] Sun, 04 March 2018 23:24 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
As I did things in r8537 & GameDir r2409, the train militia assignment is now called train new militia and is in a new sub-menu for all things militia:

https://i.imgur.com/sAQjTGd.png



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

Captain

Re: Absurdly small code changes[message #353156 is a reply to message #352618] Sun, 15 April 2018 17:49 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #353257 is a reply to message #353156] Sat, 21 April 2018 11:33 Go to previous messageGo to next message
Jolly_Reaper is currently offline 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. big grin

Report message to a moderator

Corporal
Re: Absurdly small code changes[message #353259 is a reply to message #353257] Sat, 21 April 2018 12:17 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
I'll be merging your changes. Could take some time though.


Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #353261 is a reply to message #353259] Sat, 21 April 2018 12:57 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Your fixes have been merged with GameDir 2422. Thanks for all the work. I also fixed a few spelling mistakes that I noticed.

[Updated on: Sat, 21 April 2018 12:58]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #353263 is a reply to message #353261] Sat, 21 April 2018 18:12 Go to previous messageGo to next message
Jolly_Reaper is currently offline Jolly_Reaper

 
Messages:47
Registered:August 2002
Location: The Netherlands
Great. happy I'll try to continue this whenever I can... which won't likely be anytime soon, though. Pfff. Life. not sure
I should find a job that allows me to do these kinds of things while 'working'. angel

[Updated on: Sat, 21 April 2018 18:13]

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 Go to previous messageGo to next message
Flugente

 
Messages:3509
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

Captain

Re: Absurdly small code changes[message #353533 is a reply to message #353514] Thu, 17 May 2018 00:15 Go to previous messageGo to next message
Flugente

 
Messages:3509
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).

https://i.imgur.com/xecBagY.png
Buckshot

https://i.imgur.com/SdTdE0P.png
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

Captain

Re: Absurdly small code changes[message #353534 is a reply to message #313897] Thu, 17 May 2018 01:14 Go to previous messageGo to next message
grim is currently offline grim

 
Messages:344
Registered:July 2006
Location: France
Wah, one of those absurdly small code changes that feel so obviously mandatory now that i see them. Good job !

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #353656 is a reply to message #353534] Sat, 02 June 2018 03:59 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Fixed a somewhat nasty bug in r8564: the lua function CheckMiscFlags1 did not read flagmask 1, but flagmask 2 of a profile, which is not good.


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

Captain

Re: Absurdly small code changes[message #353657 is a reply to message #353656] Sat, 02 June 2018 04:23 Go to previous messageGo to previous message
Flugente

 
Messages:3509
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 happy ).

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

Captain

Previous Topic: New feature: AI medics and officers
Next Topic: New feature: additional dialogue
Goto Forum:
  


Current Time: Fri Mar 29 07:37:13 GMT+2 2024

Total time taken to generate the page: 0.03483 seconds