Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Re: Absurdly small code changes[message #327225] Sun, 27 October 2013 18:02 Go to previous messageGo to next message
Strohmann is currently offline Strohmann

 
Messages:287
Registered:August 2011
Location: Division Thought Crimes
Uhm, this inclusion was asked for years and now it's in rather effortlessly? Really?

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #327226] Sun, 27 October 2013 19:49 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Don't know if it was asked for years. Parkan asked me lately and I decided to implement it because it fits.

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #327227] Sun, 27 October 2013 19:56 Go to previous messageGo to next message
smeagol is currently offline smeagol

 
Messages:2705
Registered:June 2008
Location: Bremen, Germany
Yeah, I asked for it a few times, but it somehow always was overlooked... it had never been THAT important for me to be me insisting, but nevertheless I'm very glad it's finally done.

Nice!

Report message to a moderator

Lieutenant

Re: Absurdly small code changes[message #327230] Sun, 27 October 2013 21:03 Go to previous messageGo to next message
Strohmann is currently offline Strohmann

 
Messages:287
Registered:August 2011
Location: Division Thought Crimes
But the hardcoded bonuses for regulars and elites are still in and have to be evened out with the these new modifiers (can it have negative values for this purpose)?

[Updated on: Sun, 27 October 2013 23:45] by Moderator

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #327237] Sun, 27 October 2013 22:39 Go to previous messageGo to next message
pheloncab is currently offline pheloncab

 
Messages:278
Registered:August 2004
Location: So. Cal. or texas
its new, flexible, optional and free.. Totally cool!

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #327255] Mon, 28 October 2013 09:40 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
This is what the ini says:

;-----------------------------------------------------------------------------------------------
; Enemy item quality modifiers
; These settings modify coolness value for enemy item selection. Valid values are from -5 to 10
; Default is 0
;-----------------------------------------------------------------------------------------------
ADMIN_EQUIPMENT_QUALITY_MODIFIER = 0
REGULAR_EQUIPMENT_QUALITY_MODIFIER = 0
ELITE_EQUIPMENT_QUALITY_MODIFIER = 0

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #327300] Tue, 29 October 2013 13:16 Go to previous messageGo to next message
Uriens is currently offline Uriens

 
Messages:346
Registered:July 2006
Ok, so when all values are 0 then the game acts as before and regulars and elites get same bonuses as before?
I think that militia values for:
GREEN_MILITIA_EQUIPMENT_QUALITY_MODIFIER = 0
REGULAR_MILITIA_EQUIPMENT_QUALITY_MODIFIER = 1
VETERAN_MILITIA_EQUIPMENT_QUALITY_MODIFIER = 2


have effect that mirrors enemies hardcoded values and if you set them all to 0 all militia would have same quality equipment.

If that is true, is there any chance to make both enemy and militia quality settings behave the same way? I.e. 0 values for all types would mean same quality for all types and default values would be 0, 1 and 2 like militia has now.
This way there would be less confusion on what does what and why enemy has all 0's while militia gets bonuses.

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #327313] Tue, 29 October 2013 21:48 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
I don't know who decided that militia should get a boost in item quality. Militia and soldiers use the same calculation for item quality. So with 0, 1, 2 militia always got an advantage over enemy soldiers.
I could have set the values for enemies to 0, 1, 2 too to make them equal to militia but I set them to 0, 0, 0 because that is the status quo and I didn't want to change that.

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #327345] Wed, 30 October 2013 22:55 Go to previous messageGo to next message
Uriens is currently offline Uriens

 
Messages:346
Registered:July 2006
Ok, thx for answer. I always thought that militia values are trying to keep vanilla values. Now I know what I need to do to make things even.
Thanks again. Smile

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #327483] Sat, 02 November 2013 13:41 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Revision 6553 together with GameDir 1854 make use of a new modifier in Item_Settings.ini:

;******************************************************************************************************************************
; This modifier sets the amount of camouflage on armor that applies when LBE is worn over the armor (NIV only).
; Valid values are from 0.0 to 1.0. 0.0 means no camo bonus from armor, 1.0 means full bonus even if LBE is worn over the armor.
; Default is 0.2
CAMO_LBE_OVER_ARMOR_MODIFIER = 0.2
;******************************************************************************************************************************

This let's players set a certain amount of armor vest camouflage that still applies even if the character wears LBE over the armor vest. The default is 0.2 (that's 20%) which you can take as the "sleeve camo bonus".

In the past only wood camouflage took LBE into account at all. This bug is now fixed. So no more overlapping bonuses except for the new percentage value.

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #327526] Sun, 03 November 2013 01:42 Go to previous messageGo to next message
pheloncab is currently offline pheloncab

 
Messages:278
Registered:August 2004
Location: So. Cal. or texas
silversurfer
Revision 6553 together with GameDir 1854 make use of a new modifier in Item_Settings.ini:

;******************************************************************************************************************************
; This modifier sets the amount of camouflage on armor that applies when LBE is worn over the armor (NIV only).
; Valid values are from 0.0 to 1.0. 0.0 means no camo bonus from armor, 1.0 means full bonus even if LBE is worn over the armor.
; Default is 0.2
CAMO_LBE_OVER_ARMOR_MODIFIER = 0.2
;******************************************************************************************************************************

This let's players set a certain amount of armor vest camouflage that still applies even if the character wears LBE over the armor vest. The default is 0.2 (that's 20%) which you can take as the "sleeve camo bonus".

In the past only wood camouflage took LBE into account at all. This bug is now fixed. So no more overlapping bonuses except for the new percentage value.



Does this affect Leg Rigs and Armor Leggings as well?
packs?

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #327530] Sun, 03 November 2013 03:04 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
No, just vests. Didn't want to change functionality here, just fix the bugs and provide a modifier for the old fixed 0 percent.

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #328086] Wed, 13 November 2013 17:16 Go to previous messageGo to next message
Buggler is currently offline Buggler

 
Messages:211
Registered:November 2009
[color:#3366FF]131112 r6584/1870[/color]
--------------------------------
Mine Names & Type Externalization [color:#3366FF]by Jazz[/color]
--------------------------------

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

Are we heading towards 4X games?
It's more catered for modders to create a better game immersion on their specific story theme. Smile
--------------------------------
Required modding files:
...TableData\Map\Minerals.xml &
...Scripts\initmines.lua


Edit:
http://i.imgur.com/0VBRvgT.png
Son, one by one is how we do it. Smile

[Updated on: Thu, 14 November 2013 09:57] by Moderator

Report message to a moderator

Sergeant 1st Class
Re: Absurdly small code changes[message #328095] Wed, 13 November 2013 18:49 Go to previous messageGo to next message
tais

 
Messages:656
Registered:February 2008
Location: NL
Ore type nuclear?!!

LOL

must be Uranium or something similar right...

Report message to a moderator

First Sergeant

Re: Absurdly small code changes[message #328113] Thu, 14 November 2013 01:04 Go to previous messageGo to next message
Gambigobilla

 
Messages:693
Registered:July 2008
Last time i checked marijuana was a mineral, maybe we can get us some weed fields and smuggle narcotics.

Report message to a moderator

First Sergeant
Re: Absurdly small code changes[message #328237] Sat, 16 November 2013 19:18 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Exe revision 6613 changes/fixes some things about NCTH recoil handling. To use this exe you need at least GameDir 1873 because of the new icon 62 in ItemInfoAdvancedIcons.sti!

  • Weapons.xml tags and are now FLOAT type values. This allows to differentiate weapons by smaller steps.
  • Items.xml tags and are now FLOAT types as well.
  • Items.xml tag will now be displayed in UDB advanced tab.
  • Item_Settings.ini has new modifiers for gun type specific and . This allows modders to quickly adjust recoil values for any gun type.
  • fixed UDB description for and
  • All recoil calculations now use FLOAT values for more precision.
edit: New modifiers in Item_Settings.ini:
Toggle Spoiler

[Updated on: Sat, 16 November 2013 19:21] by Moderator

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #328258] Sun, 17 November 2013 07:30 Go to previous messageGo to next message
Buggler is currently offline Buggler

 
Messages:211
Registered:November 2009
[color:#CC6600]131116 r6611 [/color]
--------------------------------
More Elusive Hidden Towns & Sam Sites
--------------------------------
http://i.imgur.com/PM9CeWi.png

Pack your bags and pick up your partner, Elenoa Fishie.

The tab? ...Till then.

Nite, it's time for some uncharty.

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

Report message to a moderator

Sergeant 1st Class
Re: Absurdly small code changes[message #329204] Sun, 22 December 2013 23:41 Go to previous messageGo to next message
krux is currently offline krux

 
Messages:62
Registered:June 2011
I have a small feature request I would like to propose. Excuse me if it's possible to tweak in some way already, or hard to implement. It would be neat to have a JAM_FREQUENCY for each weapon type in item_settings.ini that simply modifies the general probability of jamming.

Report message to a moderator

Corporal
Re: Absurdly small code changes[message #331116] Sat, 08 March 2014 00:48 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Whenever you finish a militia training session, the entire training progress is set back to 0%. As a consequence, exceeding training points are wasted. Thus having 4 trainers on a sector with 99% training progress is a huge waste. As of r7033 and GameDir r1975, you can set MILITIA_TRAINING_CARRYOVER_PROGRESS in the ini to TRUE. This causes excess points to be carried over to the next session, thus trainers don't waste their training anymore.

It is ensured that you don't train multiple squads in one hour by this, and you still have to pay for every training session.

This is off by default, as it's existence will surely annoy someone out there Wink

Report message to a moderator

Captain

Re: Absurdly small code changes[message #332055] Thu, 01 May 2014 21:17 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
As of r7179, when a mercenary with opened inventory looks at a sectors' inventory in strategic, [Ctrl] + [Shift] + [e] will fill up his inventory with items from the sector. This is useful for 'vulture squads', who just loot a sector, as this fills them up rather fast.

It might bee possible that a similar key combination already existed, but who knows that, really?

Report message to a moderator

Captain

Re: Absurdly small code changes[message #332430] Sun, 11 May 2014 14:33 Go to previous messageGo to next message
Thor is currently offline Thor

 
Messages:423
Registered:February 2007
Location: Belgium
Cool! Smile

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #332435] Sun, 11 May 2014 14:56 Go to previous messageGo to next message
rummtata is currently offline rummtata

 
Messages:103
Registered:April 2011
Location: Germany
Another boon for drop-all junkies. Thanks =)

Report message to a moderator

Sergeant
Re: Absurdly small code changes[message #332752] Sat, 17 May 2014 22:28 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
As of r7208 and GameDir r2035, the base chance for gun degradation is now externalised to Item_Settings.ini (it was 15 until now).

Gun degradation works like this:
// Flugente: Added a malus to reliability for overheated guns
// HEADROCK HAM 5: Variable NCTH base change
if ( UsingNewCTHSystem() == true)
{
	UINT16 usBaseChance = gGameCTHConstants.BASIC_RELIABILITY_ODDS;
	FLOAT dReliabilityRatio = 3.0f * ((FLOAT)usBaseChance / (FLOAT)gItemSettings.usBasicDeprecateChance); // Compare original odds to new odds.
	uiDepreciateTest = usBaseChance + (INT16)( dReliabilityRatio * GetReliability( &(pSoldier->inv[pSoldier->ubAttackingHand]) ) - iOverheatReliabilityMalus);
	uiDepreciateTest = max(0, uiDepreciateTest);
}
else
{
	uiDepreciateTest = max( gItemSettings.usBasicDeprecateChance + 3 * GetReliability( pObjAttHand ) - iOverheatReliabilityMalus, 0 );
}

if ( !PreRandom( uiDepreciateTest ) && ( (*pObjAttHand)[0]->data.objectStatus > 1) )
{
	(*pObjAttHand)[0]->data.objectStatus--;

	// Flugente: reduce repair threshold
	if ( Random(100) < Item[pObjAttHand->usItem].usDamageChance )
	{
		(*pObjAttHand)[0]->data.sRepairThreshold--;
	}
}
In OCTH, not regarding overheating and a gun's reliability, the chance for a gun to lose 1% status was 1/15. NCTh is slightly more complicated.

Higher values lower the chance of status loss, lower values increase it. Valid values from 0 to 10000.

This will be useful if you play OCTH and tend to go auto a lot. Currently some MGs will be rendered useless after firing less than 2 belts, which is annoying (especially if you play with internal damage thresholds).

Report message to a moderator

Captain

Re: Absurdly small code changes[message #332795] Sun, 18 May 2014 19:11 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
As of r7214, there can now be up to 30 heli refuel sites (increased from 2).

Report message to a moderator

Captain

Re: Absurdly small code changes[message #332852] Mon, 19 May 2014 23:48 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
As of r7221 and GameDir r2040, if the new ini setting KNOWN_NPCS_DIFFERENT_MAPCOLOUR is TRUE, friendly NPCs known to the player are displayed in dark blue instead of white. This might make it easier to spot them among huge crowds, in case you play with an exe that allows for a lot more civilains.

Report message to a moderator

Captain

Re: Absurdly small code changes[message #334235] Mon, 14 July 2014 23:59 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Apparently, at an unspecified time in the last 15 years, throwing knifes lost the property to get bloody when they hit a person. Not codewise, the requried tag was simply removed. I've been testing with it, and it works just fine.

To get a throwing knife become bloody, you need the normal version of it (example: item #38) and the bloody version it should turn into (example: item #62). Set 62 on item #38 an you're done. It doesn't get any easier. GameDir r2071.

And because 'why not?', we can now also do that with melee blades, as of r7337. If someone simply adds bloody pics of these items, we can go all gore-y now. :wave:

Report message to a moderator

Captain

Re: Absurdly small code changes[message #334257] Tue, 15 July 2014 21:18 Go to previous messageGo to next message
Gambigobilla

 
Messages:693
Registered:July 2008
When will we get ourselves a brand new bloodied chainsword?

Report message to a moderator

First Sergeant
Re: Absurdly small code changes[message #334259] Tue, 15 July 2014 23:55 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
When we recolour the pic, which is easy.

Better question is: When will we get an animation worthy of a chainsword?

Report message to a moderator

Captain

Re: Absurdly small code changes[message #334806] Wed, 06 August 2014 07:31 Go to previous messageGo to next message
Buggler is currently offline Buggler

 
Messages:211
Registered:November 2009
[color:#CC6600]140806 r7374[/color]
--------------------------------
Custom Resolution
--------------------------------
Distraction at its finest

http://i.imgur.com/mWeqw7F.jpg

1 good gripe about Win8, as compared to its predecessors, is that it can run 16bit color programs in compatibility mode while retaining 32bit color desktop.

Quote:
Movie playing is bugged in Win8 though due to the current hacked-together smacker library. Stracciatella has a working platform-independent solution, using the opensource libsmacker. Smile

libsmacker:
http://libsmacker.sourceforge.net/

Stracciatella Commit:
https://bitbucket.org/gennady/ja2-stracciatella/commits/72f3da9c6c1d6f09cbf6044d2e78f1744250cc2c

P.S. For those with 4k monitors/TVs, please test to report if there's any issues running at 4k(especially in tactical screen), other than everything concerning the nano size. They don't scale to your level.

Edit: On 4K, normal maps bugged due to view area bigger than the maps; no issue when playing in big maps.

[Updated on: Thu, 07 August 2014 11:57] by Moderator

Report message to a moderator

Sergeant 1st Class
Re: Absurdly small code changes[message #335103] Thu, 21 August 2014 03:20 Go to previous messageGo to next message
Buggler is currently offline Buggler

 
Messages:211
Registered:November 2009
[color:#3366FF]140821 r7402/2104[/color]
--------------------------------
History Log Externalization [color:#3366FF]by Jazz[/color]
--------------------------------


  
	
	0
	
  
  
	
	1
	%s was hired from A.I.M.
  
	.
	.
	.
  
	
	5
	Accepted Assignment From Enrico Chivaldori
  

In as well for 2014 stable release.

Carry on, Modders.
--------------------------------
Required modding files:
...TableData\History.xml

Report message to a moderator

Sergeant 1st Class
Re: Absurdly small code changes[message #335182] Thu, 28 August 2014 17:43 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Singleshot rocket launcher explosions were always hardcoded C1-explosions, regardless of Weapon settings. No more of that! Thanks to DepressivesBrot, the buddyitem tag can now (r7453) be used to specify the exploding item on the launcher. If you want your LAW to create a fiery inferno, just set 979, and your LAW will create a molotov cocktail (#979) explosion.

We leave exploring what happens if you then link the molotov to some other explosive to you Wink

Report message to a moderator

Captain

Re: Absurdly small code changes[message #335410] Tue, 02 September 2014 23:18 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Apparently light sources never decay in turnbased combat, unlike smoke effects. This makes them an even bigger pita then they should be, as in nighttime battles, any region hit by a light source is effectively a death zone for the duration of combat. I am wondering... did this obvious bug never occur to anyone? In all these years?

The reason is that, well, in turnbased time does not progress, so we never decide to decay light effects. Digging in code leads me to believe this is a vanilla oversight. Therefor I am fixing it now (r7482).

Also, break lights and trip flares had their duration set to 35 (!) turns, which is friggin' long in realtime. I've set that to 10 now (GameDir r2139). I don't care wether those were 'vanilla' values, because they were objectively bull****.

Report message to a moderator

Captain

Re: Absurdly small code changes[message #335467] Thu, 04 September 2014 20:30 Go to previous messageGo to next message
Uriens is currently offline Uriens

 
Messages:346
Registered:July 2006
So break lights will now expire during turn based combat? That's great. I always thought it was like that for some obscure coding reason.

Report message to a moderator

Master Sergeant
Re: Absurdly small code changes[message #335468] Thu, 04 September 2014 20:35 Go to previous messageGo to next message
Deleted.

 
Messages:2663
Registered:December 2012
Location: Russian Federation
Agree with Uriens, that endless lights were very strange =)

BTW, is it possible to make lights with different colors?
For example there are chemical breaklight in RL in red or yellow colors, also a light from fire (molotovs) could look better.

Another issue with light system is that you can see them (as bright light) even during bright day if you throw a breaklight, it's not realistic at all and doesn't look good.
Is there a way to check if the tile is already has light (greater than added) and in that case do not display the light from added source?

Report message to a moderator

Lieutenant

Re: Absurdly small code changes[message #335487] Fri, 05 September 2014 01:01 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
Break lights do work at day. They are, in fact, brighter than daylight - thus if you stand in a break light during the day, you can be seen from farther away than if you weren't. You can easily observe that with mortar illumination rounds - this way, they are even useful during the day. Altering would, well, require some coding, but shouldn't be hard. Considering that the lighting system is essentially untouched since vanilla, I assume there'll still be some juicy bugs and oddities.

As to colour: Atm there is only one colour. Comments by the original developers however indicate that they planned to have multiple light colours at some point - blue night lines were planned. Have to test.

Report message to a moderator

Captain

Re: Absurdly small code changes[message #335502] Fri, 05 September 2014 15:15 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Since you are on a coding spree at the moment how about something more important than different light colours (at least in my opinion)? I would like to have different visible gas cloud effects on one tile. So for example one could throw a mustard gas grenade, some tear gas and a molotov cocktail and have all cloud effects display on the same tile so the player can actually see that there is several gases on that tile. What do you think?

At the moment only the first effect is displayed.

[Updated on: Fri, 05 September 2014 15:16] by Moderator

Report message to a moderator

Lieutenant
Re: Absurdly small code changes[message #335640] Mon, 08 September 2014 21:45 Go to previous messageGo to next message
Flugente

 
Messages:3509
Registered:April 2009
Location: Germany
https://www.youtube.com/watch?v=DLdU_gx0h3k&feature=youtu.be[/video]
I can now alter light colours. Only did a quick hack here, not sure wether changing it on key press is doable or advisable - the shading is initiated upon entering a sector. Reforcing that will likely call all sorts of issues.

Hmm. Not sure what to do with this, but it's good to know that it works.

Report message to a moderator

Captain

Re: Absurdly small code changes[message #335641] Mon, 08 September 2014 22:19 Go to previous messageGo to next message
Sargeno is currently offline Sargeno

 
Messages:69
Registered:December 2001
Location: Oregon, USA
Uh yeah, looks great but maybe ease up on the shrooms :placard:

Report message to a moderator

Corporal
Re: Absurdly small code changes[message #335642] Mon, 08 September 2014 22:40 Go to previous messageGo to next message
Slax is currently offline Slax

 
Messages:1411
Registered:July 2006
Location: People riding polar bears...
Ooooo, applicable goodness.
Always did like the cave lighting. (Brownish red. Maybe I'm misremembering.) Now I can't help but imagine nights with blue tint and fun stuff like that.

Some overall light tint settings could very well be a worthwhile ini addition. Well, depending on how flexible those colors are. To allow for experimentation.

Report message to a moderator

Sergeant Major
Re: Absurdly small code changes[message #335647] Mon, 08 September 2014 23:32 Go to previous messageGo to previous message
smeagol is currently offline smeagol

 
Messages:2705
Registered:June 2008
Location: Bremen, Germany
Slax
Ooooo, applicable goodness.
Always did like the cave lighting. (Brownish red. Maybe I'm misremembering.) Now I can't help but imagine nights with blue tint and fun stuff like that.

Some overall light tint settings could very well be a worthwhile ini addition. Well, depending on how flexible those colors are. To allow for experimentation.


Ambient lights (like the brown red in caves) are easily done with the map editor btw.

Report message to a moderator

Lieutenant

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


Current Time: Fri Apr 19 00:32:37 GMT+3 2024

Total time taken to generate the page: 0.02587 seconds