Home » MODDING HQ 1.13 » v1.13 Coding Talk » Code Snippets  () 1 Vote
Re: Code Snippets[message #191140] Fri, 18 July 2008 22:02 Go to previous messageGo to next message
Khor1255 is currently offline Khor1255

 
Messages:1817
Registered:August 2003
Location: Pleasantville, NJ
The miracle shot thing needs to be fixed. Autofire is already accurate enough. If you plan to increase it's accuracy please do so in an adjustable manner.

In fact, it would be nice to have all accuracy modifyers adjustable. But better than adjustable is back to the way it was in vanilla Ja2.

EDIT

Did I say that? No, of course anything adjustable is much better than not adjustable. What I meant to say is that it would be nice to 'revert' to the way the game originally made the calculation then externalise any modifying factor. This way not only could those who have a different idea about the balance could make the game the way they want it but we could also have wide differences in weapons in a project that uses both the new modifyers and weapons that are closer to the vanilla calculation.
Any diversity we can add to weaponmods gives modders more tools to work with.

But yea, fix the 1 in 100 nonsense. Perhaps some negative modifyer would be cool that is adjustable. Perhaps factoring something in to the 1-100 'roll' is possible to prevent this random exploit.

[Updated on: Fri, 18 July 2008 22:21] by Moderator

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #191145] Fri, 18 July 2008 22:25 Go to previous messageGo to next message
KEN C

 
Messages:244
Registered:May 2007
Location: Aberdeen Washington USA
Headrock,

Please check out the "hail mary thread". SpaceViking has been investigating this and several other issues.

My concern is that changes can be externalized so as to be optional rather than mandatory.

I would also like to call to your attention the idea that last winter there was a general plea from many (several) of the most skilled modders and others to create a "milestone release" ie; JA2 1.13 V1.0 possibly having an annual update so that these talented people can start, develop, and complete mods. I do believe this one thing would advance the 1.13 mod base project tremendously as it would soon generate several new mods and therefore attract new interest. Can you help with that idea?

[Updated on: Fri, 18 July 2008 22:55] by Moderator

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #191149] Fri, 18 July 2008 22:39 Go to previous messageGo to next message
Khor1255 is currently offline Khor1255

 
Messages:1817
Registered:August 2003
Location: Pleasantville, NJ
There is supposedly a SMP project that I am technically a part of. I say technically because I do not know if any developing time has been put into this.

Unfortunately, not being a coder all I can really do is offer a modders perspective on what should and should not be done.

Please look at the threads in the SMP section that Kaiden and me wrote and you may get an idea as to what he at least (being a coder) is likely to do.

Mine so far are unadressed ideas so I can only speculate as to whether any coder is even interested in what I have asked.

Hopefully there will be some progress made on that section since I am (and will continue) building my mod around the 687 exe until I see something anywhere near less hostile to modding. My greatest hope is that all of the niv code (and other recent developments) can be quarantined in the smp version or removed until each feature is thoroughly tested and does not break some of the editors.
But I don't think that is even being considered.

We will have to wait and see what the coders decide to do.

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #191150] Fri, 18 July 2008 22:54 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Externalizing this shouldn't be hard at all. In my code above you can see that I roll for 9 out of 10 (or 9 out of 9, I'm never sure about randomize functions...). So either or both values can be altered.
The formula essentially looks like this (after a small change, "<=" to "=" ):

			if ( Random( A ) > B )
			{
				iChance = MINCHANCETOHIT;
			}

			else
			{
				iChance = MINCHANCETOHIT+1;
			}


A and B can be externalized. If they're both set to the same number (preferably 1) then it functions as though nothing's been changed (1/100 bullets will hit, because the output of this clause would be MinChanceToHit+1, which equals 1 percent chance). The greater the A, the more likely it is to give a 0% CTH. Increase B alongside A to get more finely-tuned odds. Also, to make absolutely sure, we could also externalize Minchancetohit (And Maxchancetohit if we want!)

@ Khor:
It would be impossible to get anywhere near vanilla values, mainly because so much has been added already. The formula is VERY complex and includes data from several new sources. I don't even remember what vanilla was like in this resepct. But I do agree that the CTH formula is in line for a good revamp.

@ N000B:
I haven't been around so I don't know about milestone releases, nor am I responsible for such stuff. I just come up with ideas - it's up to the 1.13 team to decide whether and how those ideas could possibly fit into 1.13.


Report message to a moderator

Sergeant Major

Re: Code Snippets[message #191151] Fri, 18 July 2008 22:59 Go to previous messageGo to next message
Headrock

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

No idea about half of what you were talking about, but here's my question: It seems to me that the NIV project works fine with the program, especially because it is optional and doesn't interfere with classic playing in any way... Utopia would be adding such moddability that the game can load mods from within the program at a user's request (a-la Silent Storm), but we're not quite there yet. It did conflict with my editor though... something about pockets.xml having bad values?

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #191154] Fri, 18 July 2008 23:49 Go to previous messageGo to next message
Khor1255 is currently offline Khor1255

 
Messages:1817
Registered:August 2003
Location: Pleasantville, NJ
All I've ever done is play this version with old inventory. The changes that were made to the code somehow broke the map editor (maybe even the basic game) in such a way that sometimes even placing mercs in a hostile sector is impossible. I have tried this both with my modded maps and vanilla maps with one tiny alteration (enemy placement in any map seems to trigger it but only sometimes).

I don't know if they have fixed this yet and don't have 5 hours to waste seeing if they did for a version I am not even interested in. The niv was a great idea and I like some of what has been done with it (especially removing the stack limit - well increasing it to 255) but there are a few things I'm not at all keen on and the fact that some really insidious bugs that modders reported during it's development (I mean modder bugs and not just regular replay bugs) have obviously not been addressed because there is no communication with modders makes it a hot potato I don't really want to get burned by.

Imagine working months or years on something and having great difficulty bringing to life many ideas. Then imagine having invested at least a solid year in mapping only to find that the editor you were using corrupted the map files so bad that you need to do the all over again.

This was not my problem (I always keep backups from something like the 302 version where I do most of my mapping) and I don't really even know if the maps that were corrupted were irreversible (I just reloaded an old map).

In short (because this is a really long and in my case bitter story) this latest version has shaken my confidence in the moddability of the 1.13 so badly that I have returned to the 687 and at this rate will likely continue to mod from that version until I finish. You see, there are already enough potential glitches tobe made during modding. If I continue to use a version that has so obviously ignored the at times pleas from modders it is my own fault when I release something that only works in one software environment and even there is an annoying bug fest.

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #191155] Sat, 19 July 2008 00:06 Go to previous messageGo to next message
KEN C

 
Messages:244
Registered:May 2007
Location: Aberdeen Washington USA
@Headrock, Sorry to step on your toes, but after reading your postings this morning I mistakenly assumed that you were part of the development team. But from your postings, I am very glad you are back as "good help is hard to find".

Report message to a moderator

Sergeant 1st Class
Re: Code Snippets[message #191158] Sat, 19 July 2008 01:08 Go to previous messageGo to next message
Headrock

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

So basically what you're saying is that build 687 is the last "stable modding platform" and that everything after build 687 is in fact an official mod which is not conducive to further modding? If that's the case, it begs the question of why the team decided to add the new inventory to the main build... You'll have to excuse me, last time I was actually around was just as NIV went beta...

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #191163] Sat, 19 July 2008 02:09 Go to previous messageGo to next message
Khor1255 is currently offline Khor1255

 
Messages:1817
Registered:August 2003
Location: Pleasantville, NJ
I'm sure they had every intention of making a version that was moddable it's just that they did not coordinate with modders and when some who were testing reported bugs and warned that these may be game/mod breakers these people were not taken seriously.

It is difficult to anticipate any condition especially if you have never experienced anything like it. Sometimes a faulty install or an incorrect xml ini setting can be responsible for a 'bug' that noone who did not make that change ever has.

Personally I did not do any testing for the niv. There are many reasons for this not the least of which is the fact that rl has been full time this year. I am lucky to get 2 hrs a week to even post here let alone have the luxury of having consecutive hours to work through an experimental install and find and accurately report a bug. I always get interrupted these days.

The thing that really annoyed the hell out of me is that I heard a lot of experienced modders reporting very disturbing new bugs and posting warnings about merging the new code until these bugs were at least quantified. They were given lip service just like I was when I asked if the niv code would be isolated from the main code in at least a version so that any catastrophic bugs it brought could be dealt with without stopping modders from having a better version of the 1080 release. I was pretty much told yes, don't worry about it which we know now was not true.

I think rather than a blatant lie that was just someone who assumed that I was being overly cautious and would be satisfied once I saw the shiny new bells and whistles. I'm not trying to be combative here but this is one of the things that absolutely floored me once I realized the new version was nowhere near isolated to a setting.
I understand why it is far easier to make one version with a simple 'switch' than isolate some experimental code and offer this version and that bug hunting might even be slowed down by having to address two versions but all of that is worth it to prevent the train wreck this latest full release has been for modders.
Something that breaks the map editor not being even noticed is a prime example of the sea change this project has seen since the days when externalizations and mod usage were top (or at least near top) priorities.

Add to all of this the fact that those of us who have reported bugs lately and expressed concerns were all but censored (in one thread scorpion actually was censored by the thread being locked) and I hope you will see where my opinion of this project differs greatly from what you wrote in another post.

I'm glad to see you back. You seem to get through to them so maybe with your help some progress might be made toward resolving this almost hopeless situation (for those of us who want to be able to make alternate gameworlds that is). You may want to join the smp and see if we can get a version modders will start to have confidence in because these days that confidence is all but non existent.

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #191172] Sat, 19 July 2008 02:56 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
Thanks. I don't know if I could be of much help though. If you recall, it took a massive effort for us to get the NIV project going - for about a year or so we were told that it was impossible and would take many indirectly-related changes to the code that were low on the priority list, and we didn't get any better answers or explanations at all - if you remember, the project eventually kicked off simply because someone (Bartek) suddenly discovered how easy it was to add new and useable pockets... And even when the project did kick start we had to rely on at-that-time newcomers to make most of the modifications.

But that's not to say I blamed the core team because this is still a volunteer project and because I agree that the top priority of 1.13 is to add moddability. What annoyed me back then was that moddability was at a peak at that time (as evidence, you're using the build that directly preceded the NIV project) so it made no sense to me at the time why coders were still busting their heads on more complex moddability projects when just a little help on the NIV would've brought that project to completion much earlier, freeing all of us to aid the moddability effort...

Frankly, had I known it would cause issues to moddability, I'd have leaned more towards making the NIV a standalone mod. In hindsight it would make much more sense to take all the improvements to 1.13 and turn them into a downloadable "collection" mod - that means mobile militia, autofire, heck even the 1000+ item list - leaving behind a vanilla JA2 that serves as a modding platform for everything else. Unfortunately, as the code looks today, that would take nearly as many years of work as it did to make 1.13 what it is today, so it's not feasible. The better solution would probably be to repair whatever is wrong with today's version, set that as a modding platform, and branch the project in two, as you said is being discussed now. I think that coders here would have no problem splitting the work between them, as some coders are inherently more interested in externalization, and others in adding new gameplay perks. And of course many would probably want to work on both projects. I agree that bug hunting is harder with two versions going parallel, but if it helps solve crises like this, it's worth the trouble.

Then again I'm not a coder, I'm just a designer. What I can do with code is basically find the places where a change needs to occur, though I seldom know how to change it properly. So I probably wouldn't be of much help with this. The stable platform needs, and has always had, the best coders in the team. I think your problem however comes from the fact that they have little time nowadays to give the code the attention it deserves. That's the problem with volunteer projects, but that's what we'll have to live with. I think the main issue would be to get people interested in working on the stable platform, but I can't help you there, because as I said - my brain works towards gameplay...

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #191174] Sat, 19 July 2008 03:02 Go to previous messageGo to next message
the scorpion

 
Messages:1834
Registered:September 2004
Location: CH
Headrock
Frankly, had I known it would cause issues to moddability, I'd have leaned more towards making the NIV a standalone mod. In hindsight it would make much more sense to take all the improvements to 1.13 and turn them into a downloadable "collection" mod - that means mobile militia, autofire, heck even the 1000+ item list - leaving behind a vanilla JA2 that serves as a modding platform for everything else.


don't ever think that wasn't discussed like 753 times in the past years. Again and again.

nobody wanted to do it then, nobody would do it now, except for some smp alibi exercises at the border to ridiculousness. :wave:

that in a hindsight, a big bunch of people would agree didn't help me much years ago. Fools. just 2 years faster thinking. Planning ahead. Or simply reading what those that did wrote.

fools.

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #191176] Sat, 19 July 2008 03:15 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
*Looks sideways at Scorpion* Hey, I missed you too hehehe. Like I said though, we had a terribly rough time getting the NIV project going - there was a year of complete inaction while waiting for something to happen, until such time when work on the project started without any help from the core team. The stable platform project doesn't seem as far-fetched to me as you make it sound though. I think 1.13 has been from the start a moddability project because that's what the most serious enthusiasts were and are after. So I'm not worried because enthusiasts don't let things die so easily. My point is, despite 753 discussions, don't lose heart. These things tend to snowball simply because they're in demand.

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #191187] Sat, 19 July 2008 07:46 Go to previous messageGo to next message
Khor1255 is currently offline Khor1255

 
Messages:1817
Registered:August 2003
Location: Pleasantville, NJ
The problem I see with the way things are now is that so many features have added so many lines of code that it is now very difficult to even get back to the state some things were in the vanilla game. You might have been the one who actually said today (in regards to the aiming system) that it is now impossible (or highly unlikely) to even get this core aspect of Ja2 back to where it was in the vanilla game to try to make an alternate version that works.
The aiming system today is full of exploits. These used to be attributed to xml adjustments but many of the weapons in my mod have minimum or zero bonuses and such and they still do not behave like they did in the vanilla game - for the worse.

I don't want to discuss the old system vs. new system (that was a maddening sidetrack a month ago I do not want to repeat) but just to illustrate how far from even having the vanilla code to reference this project has become. So in essence, something was broken but rather than return it to the way it was before the code that broke it was introduced it was decided to keep adding things to (I'm guessing) balance the new broken system. I'm not blaming anyone. I was one of the ones who kept suggesting new 'fixes' instead of simply reverting to something that worked better (vanilla way) then trying something else.

I understand that once an artist (that's what these coders are whether they know it or not) produces something in his chosen medium there is often an almost parental type ownership that can very easily cloud any criticism of his 'baby'. You tend to think that if you only tweak something a little this way or that you will come out with something way better than what was done before. But somewhere someone must be there to say 'this feature is causing too much grief. Take it out and give it some more testing before committing it to the main branch for the good of the entire project's future.'

I felt this way first about whatever code made it so you had to include a lot of sti files you weren't even using in your mod just to get the game to run correctly. I felt it again when a semi functional xml editor made it necessary to change the structure of xml files so they could no longer be read by a simple fast program like notepad (not to mention the dreadful decision to remove the explanatory headers from the xmls which used to provide very quick and convenient referencing) and when I heard some of the very serious bugs the niv testers were experiencing I voiced my concerns as loudly as I could. I asked that this code not be added to the main branch or at least some alternate version be developed. I was told...well I already said what I was told and it doesn't need to be flogged to death.

I realize how much you have invested in the niv but see it as a boatload of new code to sort out to get to the bottom of why the new version sucks for moddability. I already know why it breaks the IMP Editor and it is telling that just because some in the niv project don't care for that editor it was sacrificed for.... I guess I've said enough except to remind you that the 1080 came out before the niv as far as major releases go. I just wanted a less buggy version with the 1080s mapping xmls.

It is still all I'm really interested in. But if they can truly make all of the nivs additions switchable that would be even better. I think scrapping the niv and trying again with a fresh approach is a much better idea though.

Report message to a moderator

Sergeant Major
Re: Code Snippets[message #195661] Tue, 02 September 2008 00:54 Go to previous messageGo to next message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
I've just made a change that allows Options.INI control of mine income. It's a flat percentage bonus/penalty which is applied to all mine income. Increase to 100 to get twice as much money, or -100 to get nothing from mines (Play only with IMP and selling gear? Very Happy ).

http://img.photobucket.com/albums/v726/Headrock/Jagged%20Alliance%202/MineIncome300Percent.gif

See how mine income changes halfway? That's due to raising the values. It can be done mid-campaign as it affects the results of several functions directly, using the values read from Options.INI. I should theoretically add a new function that does this, to save some headaches. But apparently I've fixed all of the required functions to do this, as the correct amount displays anywhere where mine income is written, and the money goes into your account correctly too.

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #195685] Tue, 02 September 2008 09:40 Go to previous messageGo to next message
lockie is currently offline lockie

 
Messages:3721
Registered:February 2006
Location: Scotland
Shit , now I've gotta become an accountant ........ Very Happy

Report message to a moderator

Captain

Re: Code Snippets[message #208810] Sat, 14 February 2009 15:54 Go to previous messageGo to next message
2Points is currently offline 2Points

 
Messages:10
Registered:February 2009
Might as well give it a go and post something I've recently completed here. This snipped implements dynamic repair priorities based on item type, placement and durability. Idea behind it was that my repair dudes basically always started to repair minorly broken items in their own inventory instead of items on other mercs that might need repair much more urgently, wasting a lot of time until they finally got to the item in question. Most noticable when giving a broken weapon to a merc that doesn't have the ability to repair items - it takes ages until the repair merc finally gets to this item when there are a few other items to repair around.

So instead of looking through pockets in a linear fashion, all items that need repairing are collected and assigned priorites. The item with the highest priority will be repaired first.

Currently, the following repair order is used:
1. Jammed weapons
2. Equipped weapons
3. Equipped armor
4. Weapons in inventory
5. Armor in inventory
6. Other items
7. Bags

When two items share the same priority, the item with less durability will be favored.

A patch against the curent SVN trunk can be found here: http://files.sector-5.net/ja/dynamic-repair.patch
Test executable here: http://files.sector-5.net/ja/ja2_dynamic_repair_en.zip
Compiled with VS2008, so the executable might or might not have additional VS DLL dependencies.

[Updated on: Sat, 14 February 2009 21:44] by Moderator

Report message to a moderator

Private
Re: Code Snippets[message #208852] Sun, 15 February 2009 13:52 Go to previous messageGo to next message
orko_oskar is currently offline orko_oskar

 
Messages:72
Registered:April 2007
Location: Sweden
Ooohhh, looks really usefull.
Any chance we can get repair on NVG/sunglasses before armour in inventory?

Report message to a moderator

Corporal
Re: Code Snippets[message #208857] Sun, 15 February 2009 16:24 Go to previous messageGo to next message
2Points is currently offline 2Points

 
Messages:10
Registered:February 2009
Sure, I added some code to the previous post. This unfortunately includes gas masks and similar items that can be equipped in face slots for now - I'm not entirely certain how to check if items are sun googles/nvgs. Might compare the item ID, but would probaby break if someone changed the IDs or added new google types.

Report message to a moderator

Private
Sector inventory sorting[message #209173] Sun, 22 February 2009 14:08 Go to previous messageGo to next message
2Points is currently offline 2Points

 
Messages:10
Registered:February 2009
Inspired by this thread, a simple way to customize how a sector's inventory gets sorted. Probably most useful for `Drop all items'-games with tons of items after each battle.

The sort options aren't particularly extensive for now, since I've only added SHORTNAME, LONGNAME, CATRGORY, AMOUNT, QUALITY, RANGE, DAMAGE and ACCURACY. Implementing new options is pretty straight-forward though, simply inherit a new class from WorldItemComparator and overwrite its compareItemsInternal() method. Add a name for the option in GetComparatorForString() and you're done. (WorldItem Comparison.h/.cpp)

Also add this to your ja2_options.ini under Game options:
;******************************************************************************************************************************
; Customize sector inventory sort order.
; Possible sort criteria include: SHORTNAME, LONGNAME, CATRGORY, AMOUNT, QUALITY, RANGE, DAMAGE, ACCURACY
; Seperate values with comma. To specify sort order, prefix the criteria with either + for ascending order
; or - for descending order. If omitted, ascending order is used.
; Example for the `classic' sort order: CATEGORY,LONGNAME,-AMOUNT,-QUALITY
;******************************************************************************************************************************
SECTOR_INV_SORT_ORDER = CATEGORY,-RANGE,-DAMAGE,-ACCURACY,SHORTNAME,-AMOUNT,-QUALITY


Customize as you see fit.

Patch against SVN trunk is here: http://files.sector-5.net/ja/custom-sectorinv-sort.patch
Test executable: http://files.sector-5.net/ja/ja2_invsort_en.zip

Report message to a moderator

Private
Re: Sector inventory sorting[message #209183] Sun, 22 February 2009 15:55 Go to previous messageGo to next message
wanne (aka RoWa21) is currently offline wanne (aka RoWa21)

 
Messages:1961
Registered:October 2005
Location: Austria
@2points: Nice work, I posted a comment in the other thread an a suggestion for dynamically sorting instead of INI entry. Take a look here:

http://www.ja-galaxy-forum.com/board/ubbthreads.php?ubb=showflat&Number=209182&Main=14500#Post209182

Report message to a moderator

Sergeant Major

Stock Multiplier[message #242964] Mon, 01 February 2010 00:12 Go to previous messageGo to next message
Faithless is currently offline Faithless

 
Messages:439
Registered:October 2009
Location: The safe end of the barre...
I've made a little modification because I wasn't happy with the current bobby ray's selection setting.
I made it so that the BR selection setting no longer affects the item stock.
Instead I made another ini option that lets you multiply the BR stock by any number between 1 and 10 (1 being default of course :crazy: )
This mod may have implications for the MP part, because the stock might not be multiplied any more. Should be an easy fix but I don't know how MP works Smile

I used SVN version 3111, if it matters. At the lowest 2 code fields I've added some surrounding code for easier reference. Code is working on my own compiled exe at least Smile
So, lets get to the code:

Defining the new value
- GameSettings.h near line 285 (well not that it matters much where..)
//WarmSteel multiplier for BR stock
INT32	iBRStockMultiplier; 


Reading from the ini file.
- GameSettings.cpp near line 944
	//multiplier for BR stock - WarmSteel
gGameExternalOptions.iBRStockMultiplier					= iniReader.ReadInteger("JA2 Gameplay Settings","BR_STOCK_MULTIPLIER",1, 1, 10);


Just replaced gGameOptions.ubBobbyRay with gGameExternalOptions.iBRStockMultiplier, this determines whether a restock is needed.
- BobbyR.cpp near line 718
//if the item isn't already on order
if( LaptopSaveInfo.BobbyRayInventory[ i ].ubQtyOnOrder == 0 || gGameOptions.ubBobbyRay == BR_AWESOME )
{
DebugMsg(TOPIC_JA2, DBG_LEVEL_3,String("DailyUpdateOfBobbyRaysNewInventory: item = %d, qty on hand = %d, half desired amount = %d",usItemIndex,LaptopSaveInfo.BobbyRayInventory[ i ].ubQtyOnHand,(StoreInventory[ usItemIndex ][ BOBBY_RAY_NEW ] * gGameExternalOptions.iBRStockMultiplier )/2));
//if the qty on hand is half the desired amount or fewer
if( LaptopSaveInfo.BobbyRayInventory[ i ].ubQtyOnHand <= (StoreInventory[ usItemIndex ][ BOBBY_RAY_NEW ] * gGameExternalOptions.iBRStockMultiplier )/2 )
{


Again just replaced gGameOptions.ubBobbyRay with gGameExternalOptions.iBRStockMultiplier.
This part now multiplies the amount of items restocked by BR by iBRStockMultiplier.
- BobbyR.cpp near line 830
// decide if he can get stock for this item (items are reordered an entire batch at a time)
if (ItemTransactionOccurs( -1, usItemIndex, DEALER_BUYING, ubBobbyRayNewUsed ))
{
if (ubBobbyRayNewUsed == BOBBY_RAY_NEW)
{
	ubItemsOrdered = HowManyItemsToReorder(StoreInventory[ usItemIndex ][ ubBobbyRayNewUsed ] * gGameExternalOptions.iBRStockMultiplier, ubCurrentlyOnHand);
}


And the actual added ini option in the Gameplay Settings section (I put it near "TONY_USES_BR_SETTING")
;******************************************************************************************************************************
; The BR's new items stock is multiplied by this value. Values between 1 and 10
;******************************************************************************************************************************
BR_STOCK_MULTIPLIER = 4


So anyone willing to implement this ? Smile

Edit: I just noticed a nice patch function on turtoiseSVN, I could just post the patch file? =)

[Updated on: Mon, 01 February 2010 01:45] by Moderator

Report message to a moderator

Master Sergeant
Code Snippets[message #257165] Thu, 22 July 2010 16:47 Go to previous messageGo to next message
tais

 
Messages:656
Registered:February 2008
Location: NL
Hi guys

I made a little addition to the code that enables/disables mercs being on assignment when you start the game, this option can be enabled/disabled with a simple ini setting...

based on Beta SVN revision 3558 source

- Tactical/Soldier Profile.cpp
- line 859
if (Random(100) < uiChance)

changed in
// tais: added ini option to disable mercs being on assignment at the start
if (Random(100) < uiChance && gGameExternalOptions.fMercsOnAssignmentAtStart)


i added an ini setting in the code
- ja2/GameSettings.h
- line 227
underneath
BOOLEAN fAllMercsAvailable;


i added
BOOLEAN fMercsOnAssignmentAtStart;



- ja2/GameSettings.cpp
- line 661
underneath
gGameExternalOptions.fAllMercsAvailable	= iniReader.ReadBoolean("Recruitment Settings","MERC_WEBSITE_ALL_MERCS_AVAILABLE",FALSE);


i added
//tais: normal behaviour if true, all mercs available at start of game if false
gGameExternalOptions.fMercsOnAssignmentAtStart = iniReader.ReadBoolean("Recruitment Settings","MERCS_CAN_BE_ON_ASSIGNMENT",TRUE);



in JA2_Options.ini the following needs to be added underneath
[Recruitment Settings]
added
;Mercs can be on assignment at the start of the game?
MERCS_CAN_BE_ON_ASSIGNMENT = TRUE



TRUE = normal behaviour
FALSE = no mercs on assignment at start of the game

Voila, no more mercs on assignment when you need them at start ^^

Report message to a moderator

First Sergeant

Re: Code Snippets[message #257249] Fri, 23 July 2010 12:23 Go to previous messageGo to next message
wanne (aka RoWa21) is currently offline wanne (aka RoWa21)

 
Messages:1961
Registered:October 2005
Location: Austria
@Tais: Nice little externalization. Will add that to official 1.13 source. Thanks.

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #257280] Fri, 23 July 2010 18:18 Go to previous messageGo to next message
cdudau
Isn't this standard when playing on Insane difficulty?

Nevermind.... :wb:

[Updated on: Fri, 23 July 2010 18:20]

Report message to a moderator

Re: Code Snippets[message #258432] Wed, 04 August 2010 23:16 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
No more talking when spotting mines!

This one was requested so I decided to code it.

What does it do?
Until now when spotting a mine your merc says a quote. If you clear a mine field and have to listen to the same quote over and over again it can become quite boring. This is especially true for the large mine fields on WF maps. With this mod you can disable the quotes in Ja2_Options.ini.


What did I change?

new setting in Ja2_Options.ini:
[Tactical Interface Settings]
MINES_SPOTTED_NO_TALK = TRUE

If this is "TRUE" your merc won't says anything when spotting a mine. He will just place a blue flag if the setting "AUTOMATICALLY_FLAG_MINES_WHEN_SPOTTED = TRUE" otherwise you will be asked if you want to place a blue flag. If "MINES_SPOTTED_NO_TALK" is "FALSE" (the default value) the merc will say his quote like it was before.


GameSettings.h added line 821 and 822:
// silversurfer: don't play quote when merc spots a mine? TRUE = shut up! FALSE = tell me that you found a mine!
BOOLEAN fMineSpottedNoTalk;


GameSettings.cpp added line 763 and 764:
// silversurfer: don't play quote when mine spotted?
gGameExternalOptions.fMineSpottedNoTalk					= iniReader.ReadBoolean("Tactical Interface Settings","MINES_SPOTTED_NO_TALK", FALSE);


Tactical\Overhead.cpp inserted at line 2202
// silversurfer: if TRUE the merc won't comment that he found a mine, otherwise old behaviour
if (gGameExternalOptions.fMineSpottedNoTalk )
	MineSpottedDialogueCallBack ();
else
{
	SetStopTimeQuoteCallback( MineSpottedDialogueCallBack );
	TacticalCharacterDialogue( pSoldier, QUOTE_SUSPICIOUS_GROUND );
}

and again at line 2818
// silversurfer: if TRUE the merc won't comment that he found a mine, otherwise old behaviour
if (gGameExternalOptions.fMineSpottedNoTalk )
	MineSpottedDialogueCallBack ();
else
{
	SetStopTimeQuoteCallback( MineSpottedDialogueCallBack );
	TacticalCharacterDialogue( pSoldier, QUOTE_SUSPICIOUS_GROUND );
}


INIEditorJA2Options.xml
        
          If set to TRUE, when a character finds a mine they will not say anything and only put a blue flag there or ask if they should do so. 
(depends on the setting of "AUTOMATICALLY_FLAG_MINES_WHEN_SPOTTED") 
If set to FALSE, when a character finds a mine they will tell you with a comment (the "classic" behavior).
          Setzen Sie diesen Wert auf TRUE, damit S

Report message to a moderator

Lieutenant
Re: Code Snippets[message #258492] Thu, 05 August 2010 17:56 Go to previous messageGo to next message
wanne (aka RoWa21) is currently offline wanne (aka RoWa21)

 
Messages:1961
Registered:October 2005
Location: Austria
Thanks silversurfer, the patch is applied to the SVN development source.

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #273080] Wed, 09 February 2011 18:20 Go to previous messageGo to next message
JMich is currently offline JMich

 
Messages:546
Registered:January 2011
Location: Greece
Externalizing DIFF_FACTOR_PLAYER_PROGRESS, DIFF_FACTOR_PALACE_DISTANCE and DIFF_FACTOR_GAME_DIFFICULTY

Files Modified
  • GameSettings.h
  • GameSettings.cpp
  • Soldier Create.cpp
  • Ja2_Options.ini
Ja2_Options.ini
In the [Strategic Progress Settings] Section, we add
;------------------------------------------------------------------------------------------------------------------------------
; Game difficulty weights
;
; Determine what factors influence the game's difficulty.
; Range: 0-100%
; Warning! The sum of all 3 variables must be 100, or the variables will be reset to defaults
;------------------------------------------------------------------------------------------------------------------------------
; Weight of Progress %			Default 50%
DIFF_FACTOR_PLAYER_PROGRESS = 50
; Weight of Distance from Palace	Default 30%
DIFF_FACTOR_PALACE_DISTANCE = 30
; Weight of Game Difficulty		Default 20%
DIFF_FACTOR_GAME_DIFFICULTY = 20



GameSettings.h
After the section
//WDS - Progress settings
we add the following
	// JMich - Difficulty Factor Settings
	UINT32 ubDiffFactorPlayerProgress;
	UINT32 ubDiffFactorPalaceDistance;
	UINT32 ubDiffFactorGameDifficulty;
This declares the 3 Difficulty Factors as external game options.


GameSettings.cpp
In the huge LoadGameExternalOptions() function, under "Strategic Progress Settings"
		//JMich - Difficulty Settings

		gGameExternalOptions.ubDiffFactorPlayerProgress		= iniReader.ReadInteger("Strategic Progress Settings","DIFF_FACTOR_PLAYER_PROGRESS", 50, 0, 100);
		gGameExternalOptions.ubDiffFactorPalaceDistance		= iniReader.ReadInteger("Strategic Progress Settings","DIFF_FACTOR_PALACE_DISTANCE", 30, 0, 100);
		gGameExternalOptions.ubDiffFactorGameDifficulty		= iniReader.ReadInteger("Strategic Progress Settings","DIFF_FACTOR_GAME_DIFFICULTY", 20, 0, 100);
	
		// Any way to warn on this?
		if (gGameExternalOptions.ubDiffFactorPlayerProgress + 
		gGameExternalOptions.ubDiffFactorPalaceDistance + 
		gGameExternalOptions.ubDiffFactorGameDifficulty != 100) 
	{
		gGameExternalOptions.ubDiffFactorPlayerProgress =	50; 
		gGameExternalOptions.ubDiffFactorPalaceDistance =	30;
		gGameExternalOptions.ubDiffFactorGameDifficulty =	20;

		// Yes, there is!
		std::stringstream errMessage;
		errMessage << "The values of the three ''DIFF_FACTOR'' INI settings do not add up to 100! Using default values instead...";
		iniErrorMessages.push(errMessage.str());
	}

If I've done it correctly, this reads the 3 settings from the Ja2_Options.ini, with default values of 50, 30, 20 (original values), minimum value of 0 and maximum value of 100. If the 3 values don't add exactly to 100, then it replaces them with the default and mentions it.


Soldier Create.cpp
Most of the work was done here, code snippets and comments galore

// THESE 3 DIFFICULTY FACTORS MUST ALWAYS ADD UP TO 100% EXACTLY!!!
#define DIFF_FACTOR_PLAYER_PROGRESS			50
#define DIFF_FACTOR_PALACE_DISTANCE			30
#define DIFF_FACTOR_GAME_DIFFICULTY			20
is changed to
// THESE 3 DIFFICULTY FACTORS MUST ALWAYS ADD UP TO 100% EXACTLY!!!
#define DIFF_FACTOR_PLAYER_PROGRESS			gGameExternalOptions.ubDiffFactorPlayerProgress
#define DIFF_FACTOR_PALACE_DISTANCE			gGameExternalOptions.ubDiffFactorPalaceDistance
#define DIFF_FACTOR_GAME_DIFFICULTY			gGameExternalOptions.ubDiffFactorGameDifficulty


Function UINT8 GetLocationModifier( UINT8 ubSoldierClass ), after the "Switch(bTownID)" block we replace
		// adjust for distance from Queen's palace (P3) (0 to +30)
		ubLocationModifier = ( ( MAX_PALACE_DISTANCE - ubPalaceDistance ) * DIFF_FACTOR_PALACE_DISTANCE ) / MAX_PALACE_DISTANCE;
with
	//JMich Modified Distance Factor
	if (DIFF_FACTOR_PALACE_DISTANCE != 0)
	{
		// adjust for distance from Queen's palace (P3) (0 to DIFF_FACTOR_PALACE_DISTANCE)
		ubLocationModifier = ( ( MAX_PALACE_DISTANCE - ubPalaceDistance ) * DIFF_FACTOR_PALACE_DISTANCE ) / MAX_PALACE_DISTANCE;
	}
	else
	{
		switch( gGameOptions.ubDifficultyLevel )
		{
		case DIF_LEVEL_EASY:
			// all battles as far away as possible
			ubLocationModifier = 0;
			break;
		case DIF_LEVEL_MEDIUM:
			// all battles in middle distance
			ubLocationModifier = 10;
			break;
		case DIF_LEVEL_HARD:
		case DIF_LEVEL_INSANE:
			// all battles in the palace
			ubLocationModifier = 20;
			break;
		}
	}
If we have a distance of 0, I've added a little difference to be used in CalcDifficultyModifier() function later on.



Function RandomizeRelativeLevel( INT8 *pbRelLevel, UINT8 ubSoldierClass ), after variables declaration, we replace
	// this returns 0 to DIFF_FACTOR_PALACE_DISTANCE (0 to +30)
	ubLocationModifier = GetLocationModifier( ubSoldierClass );

	// convert to 0 to 10 (divide by 3), the subtract 5 to get a range of -5 to +5
	bRollModifier = ( INT8 ) ( ubLocationModifier / ( DIFF_FACTOR_PALACE_DISTANCE / 10 ) ) - 5;
with
	//JMich Modified Distance Factor
	if (DIFF_FACTOR_PALACE_DISTANCE==0) 
	{
	switch( gGameOptions.ubDifficultyLevel )
		{
		case DIF_LEVEL_EASY:
			// all battles as far away as possible
			bRollModifier = -5;
			break;
		case DIF_LEVEL_MEDIUM:
			// all battles in middle distance
			bRollModifier = 0;
			break;
		case DIF_LEVEL_HARD:		
		case DIF_LEVEL_INSANE:
			// all battles in the palace
			bRollModifier = 5;
			break;
		}
	}
	else
	{
	// this returns 0 to DIFF_FACTOR_PALACE_DISTANCE 
	ubLocationModifier = GetLocationModifier( ubSoldierClass );

	// convert to 0 to 10 (divide by DIFF_FACTOR_PALACE_DISTANCE/10), then subtract 5 to get a range of -5 to +5
	bRollModifier = ( INT8 ) ( ubLocationModifier / ( DIFF_FACTOR_PALACE_DISTANCE / 10 ) ) - 5;
	}
Again, if we don't have a distance factor to our calculation, adjust it according to difficulty level.

Finally, we change the function INT8 CalcDifficultyModifier( UINT8 ubSoldierClass ) as follows
INT8 CalcDifficultyModifier( UINT8 ubSoldierClass )
{

	UINT8 ubDiffModifier = 0;	//JMich converted to unsigned due to 127 cap of signed, added u to start of variable name
	UINT8 ubProgress;
	UINT8 ubProgressModifier;
	INT8 USED_DIFF_FACTOR_GAME_DIFFICULTY = 20;	//JMich unsure if DIFF_FACTOR_GAME_DIFFICULTY would be changed by if check below, decided to use temp variable

	DebugMsg(TOPIC_JA2,DBG_LEVEL_3,String("CalcDifficultyModifier"));

	if( gfEditMode )
	{
		// return an average rating for editor purposes
		return( 50 );
	}


	// THESE 3 DIFFICULTY FACTORS MUST ALWAYS ADD UP TO 100% EXACTLY!!!
	Assert( ( DIFF_FACTOR_PLAYER_PROGRESS	+ DIFF_FACTOR_PALACE_DISTANCE	+ DIFF_FACTOR_GAME_DIFFICULTY ) == 100 );


	// adjust for game difficulty level
	if (DIFF_FACTOR_GAME_DIFFICULTY >= 10)	//JMich if GAME_DIFFICULTY too low, increase it
	{
		USED_DIFF_FACTOR_GAME_DIFFICULTY = DIFF_FACTOR_GAME_DIFFICULTY;
	}
	else
	{
		USED_DIFF_FACTOR_GAME_DIFFICULTY = 20;
	}	

	switch( gGameOptions.ubDifficultyLevel )	//JMich This will give us a ubDiffModifier of 0 to 150 (INSANE at max Difficulty Level Factor for enemies)
	{
		case DIF_LEVEL_EASY:
			// very strong militia, very weak enemies/cratures/bloodcats
			if ( SOLDIER_CLASS_MILITIA( ubSoldierClass ) )
			{
				// +20
				ubDiffModifier += USED_DIFF_FACTOR_GAME_DIFFICULTY;
			}
			break;

		case DIF_LEVEL_MEDIUM:
			// equally strong militia, enemies, creatures, bloodcats (+10)
			ubDiffModifier += ( USED_DIFF_FACTOR_GAME_DIFFICULTY / 2 );
			break;

		case DIF_LEVEL_HARD:
			// equally stronger militia/enemies/creatures/bloodcats (+20)
			ubDiffModifier += USED_DIFF_FACTOR_GAME_DIFFICULTY;
			break;
		case DIF_LEVEL_INSANE:
			// equally stronger enemies/creatures/bloodcats (+40)
			if ( SOLDIER_CLASS_MILITIA( ubSoldierClass ) )
			{
				// militia only +20
				ubDiffModifier += USED_DIFF_FACTOR_GAME_DIFFICULTY;
			}
			else
			{
				ubDiffModifier += (INT8)(USED_DIFF_FACTOR_GAME_DIFFICULTY * 1.5);
			}
			break;
	}

	// the progress returned ranges from 0 to 100
	ubProgress = HighestPlayerProgressPercentage();


	// bump it a bit once we've accomplished something (killed some enemies or taken an important sector)
	if ( ubProgress > 0 )
	{
		// +5
		ubDiffModifier += DIFF_MODIFIER_SOME_PROGRESS;
	}




	// adjust for progress level (0 to DIFF_FACTOR_PLAYER_PROGRESS )	//JMich Modifier of 0 to 100
	ubProgressModifier = ( ubProgress * DIFF_FACTOR_PLAYER_PROGRESS ) / 100;
	ubDiffModifier += ubProgressModifier;


	// adjust for map location
	ubDiffModifier += GetLocationModifier( ubSoldierClass );	//JMich Modifier of 0 to 100


	// drop it down a bit if we still don't have any mine income
	//JMich moved it to the end so we can have it unsigned, since if signed it caps at 127

		if ( PredictIncomeFromPlayerMines(TRUE) == 0 )
	{
		// -5
		if (ubDiffModifier > abs(DIFF_MODIFIER_NO_INCOME * -1))		//JMich Check if we can subtract from the difficulty, since unsigned 0 - 5 = 251
		{
		ubDiffModifier -= abs(DIFF_MODIFIER_NO_INCOME * -1);	//JMich Subtracting a positive or adding a negative, if 0 mine income then difficulty decreases
		}
		else
		{
			ubDiffModifier = 0;		//JMich If our current difficulty is lower than the modifier, set difficulty to 0
		}
	}

	// should be no way to go over 100, although it's possible to go below 0 when just starting on easy
	// JMich modified, checks added (hopefully)
	// Assert( bDiffModifier <= 100 );

	// limit the range of the combined factors to between 0 and 100
	ubDiffModifier = __max(	0, ubDiffModifier );
	ubDiffModifier = __min( 100, ubDiffModifier );
	

	// DON'T change this function without carefully considering the impact on GenerateRandomEquipment(),
	// CreateDetailedPlacementGivenBasicPlacementInfo(), and SoldierDifficultyLevel().
	DebugMsg(TOPIC_JA2,DBG_LEVEL_3,String("CalcDifficultyModifier done"));

	return(ubDiffModifier);
}


If I have done this change correctly, it means that we can have a mod where the EnemyItemChoice and EnemyGunChoice can depend on any combination of these 3 factors, like what BAG-Pro was supposed to be when it was first implemented (Progress 90%+, Location < 10%, Difficulty < 10%), or maybe even a mod with a few items, but independant of progress, for example a Wild West mod (grand total of 10? 15 weapons?) where the closer you are to P3, the greater the enemies choices will be.

There will also be a change to the enemies attributes if game difficulty is greater than Experienced, and they'll propably be a bit tougher, but I haven't really tried it that much.

P.S. Would it be possible to make these 3 variables to be in the EnemyItemChoices.xml so a mod maker can trully define his/her mod?

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273175] Thu, 10 February 2011 12:46 Go to previous messageGo to next message
Buns is currently offline Buns

 
Messages:655
Registered:September 2010
That's brilliant!

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273192] Thu, 10 February 2011 16:33 Go to previous messageGo to next message
SpaceViking is currently offline SpaceViking

 
Messages:751
Registered:January 2004
Location: Rochester, Minnesota, USA
Cool! It sounds like we could use this to solve the "guys with G3A3s in Chitzena" issue.

Report message to a moderator

First Sergeant

Re: Code Snippets[message #273193] Thu, 10 February 2011 16:44 Go to previous messageGo to next message
Buns is currently offline Buns

 
Messages:655
Registered:September 2010
SpaceViking
Cool! It sounds like we could use this to solve the "guys with G3A3s in Chitzena" issue.
I don't think so: Now Chitzena has a rather low level, I guess 2 or 3. When you encounter someone with a G3 in Chitzena it means the G3 is made a valid weapon in level 2 or 3 (or this one was pre-placed).

With the new system that ties this to game progress you would still run into a guy with a G3 in Chitzena if that weapon is level 2, unless Chitzena realy is your first town. When Chitzena is your first town certainly the blackshirts that make the counter-attack will wield G3s, latest the first Trooper in the next town you attack have them.

[Updated on: Thu, 10 February 2011 16:45] by Moderator

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273195] Thu, 10 February 2011 17:24 Go to previous messageGo to next message
SpaceViking is currently offline SpaceViking

 
Messages:751
Registered:January 2004
Location: Rochester, Minnesota, USA
I saw it in my initial attack there when I played my first 2011 beta test game. It was the first town I attacked and only the 3rd or 4th combat.

Report message to a moderator

First Sergeant

Re: Code Snippets[message #273199] Thu, 10 February 2011 17:40 Go to previous messageGo to next message
Buns is currently offline Buns

 
Messages:655
Registered:September 2010
Could you please check what's the earlyest appearence of the G3 in the EnemyGunChoices in question.

Chitzena should be level 2 or maximum 3. Given that you did not controll any sectors and did not have any mine income at that moment we would even have a "minus" in level calculation (unless the guy was a blackshirt and slow progression was turned off). This would mean you should have been facing weapons of, may be, level 0 to 2.

When we have 11 levels to assign weapons, I think it is obvious that a G3 should not appear at anything prior to level 6 - unless we have laser-rifles implemented as well.

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273210] Thu, 10 February 2011 18:36 Go to previous messageGo to next message
SpaceViking is currently offline SpaceViking

 
Messages:751
Registered:January 2004
Location: Rochester, Minnesota, USA
I was using whatever was in the 2011 beta. Expert difficulty.

Report message to a moderator

First Sergeant

Re: Code Snippets[message #273231] Thu, 10 February 2011 21:17 Go to previous messageGo to next message
JMich is currently offline JMich

 
Messages:546
Registered:January 2011
Location: Greece
@SpaceViking

I run the numbers for Chitzena using the default (current) system (50% progress, 30% location, 20% difficulty), a 80/10/10 which is the most balanced location independant, and the harder than 100% 100/0/0 which is difficulty dependant.
After the number crunching, these are the final possible choices
Default       = 0 to 5, or 2 to 7 for elites.
80/10/10            = 0 to 4, or 1 to 6 for elites.
100/0/0 expert      = 4 to 8, or 6 to 10 for elites.
100/0/0 experienced = 2 to 7 or 4 to 9 for elites.
100/0/0 novice      = 0 to 4 or 2 to 6 for elites.

Calculations by Headrock's How-to Part 11 (plus adding progress modifier), assuming a progress of 8 and no mine income.
HKG3A3 is at choice level 4, so while still possible for an 80/10/10 game, it should be about 1% chance (both random(10) rolls rolling 10s).
If you do play at 100/0/0 expert though, G3A3 at Chitzena will be the lowest part of the gun choices, because my proposed code assumes that all battles take place in the palace for expert level with a location modifier of 0.
Number crunching following in the spoiler (my rough draft in notepad)
Numbers

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273330] Fri, 11 February 2011 16:16 Go to previous messageGo to next message
Buns is currently offline Buns

 
Messages:655
Registered:September 2010
SpaceViking
I was using whatever was in the 2011 beta. Expert difficulty.
I don't know that EGC. But regardless of difficulty, the enemy should not be wielding weapons of that kind in the first town, because a weapon used by the enemy in this battle is a weapon used by the player in the next battle.

Thinking further about it, enemy gun selection shouldn't be influenced by difficulty at all:

- On Novice difficulty the enemy at Drassen airport had only been dropping .38er
- On Expert they had been dropping SMGs
- On Insane they had been dropping G3s

On which setting would the next battle be easyer? Yes, exactly.

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273331] Fri, 11 February 2011 16:19 Go to previous messageGo to next message
SpaceViking is currently offline SpaceViking

 
Messages:751
Registered:January 2004
Location: Rochester, Minnesota, USA
Buns
SpaceViking
I was using whatever was in the 2011 beta. Expert difficulty.
I don't know that EGC. But regardless of difficulty, the enemy should not be wielding weapons of that kind in the first town, because a weapon used by the enemy in this battle is a weapon used by the player in the next battle.

Thinking further about it, enemy gun selection shouldn't be influenced by difficulty at all:

- On Novice difficulty the enemy at Drassen airport had only been dropping .38er
- On Expert they had been dropping SMGs
- On Insane they had been dropping G3s

On which setting would the next battle be easyer? Yes, exactly.


Somewhere I read a quote from one of the original designers where they mentioned this very same problem. The game was actually *easier* on harder difficulty levels because you got better equipment sooner.

Report message to a moderator

First Sergeant

Re: Code Snippets[message #273332] Fri, 11 February 2011 16:27 Go to previous messageGo to next message
Buns is currently offline Buns

 
Messages:655
Registered:September 2010
SpaceViking
Somewhere I read a quote from one of the original designers where they mentioned this very same problem. The game was actually *easier* on harder difficulty levels because you got better equipment sooner.
Not only that: higher difficulty level means more fights with more and better enemies, means more leveling up for the player's characters. In fact, Novice can be quite tough in the late game when your level 3(!) IMP comes across the first blackshirts.

[Updated on: Fri, 11 February 2011 16:28] by Moderator

Report message to a moderator

First Sergeant
Re: Code Snippets[message #273337] Fri, 11 February 2011 16:47 Go to previous messageGo to next message
usrbid is currently offline usrbid

 
Messages:1506
Registered:December 2008
I totally agree, try to play on Novice with lowest BR, all you have after Omerta are 38 Specials, probably most difficult (and boring) game I played. Well, at least the fights are over quickly and the queen doesn't bother you much. The game becomes more of a strategic management exercise. Most of the game is determined by preplaced enemy gear. In Vanilla you spend a lot of time trying to steal as a result.

Report message to a moderator

Sergeant Major

Re: Code Snippets[message #273338] Fri, 11 February 2011 17:02 Go to previous messageGo to next message
SpaceViking is currently offline SpaceViking

 
Messages:751
Registered:January 2004
Location: Rochester, Minnesota, USA
The BR setting REALLY screws things up, though. The default is now something like awesome and in my beta test game I was able to buy M16s, G3s, and etc. right off the bat from Tony and BR. The only thing limiting me from total overequipping my team is a lack of funds and my boredom with waiting for the funds to accumulate.

I think we should move the BR setting from the startup screen to the .ini at least because it so overwhelmingly affects the difficulty.

[Updated on: Fri, 11 February 2011 17:02] by Moderator

Report message to a moderator

First Sergeant

Re: Code Snippets[message #273340] Fri, 11 February 2011 17:14 Go to previous messageGo to previous message
Buns is currently offline Buns

 
Messages:655
Registered:September 2010
SpaceViking
I think we should move the BR setting from the startup screen to the .ini at least because it so overwhelmingly affects the difficulty.
Not sure if that would realy help it, though. Problem with BR is that it turned from an in-game online shop to provide the player with "this and that" to the most complete weapon exhibition worldwide. With AIM I wouldn't be able to think of any other way to half-way usefull implement about 75% of the weapons than to make them buyable via BR.

So when anyone desperatly wishes to equip his team with Indian assault-rifles in highly exotical calibers, I wouldn't know where else to offer them to the player at any stage of the game than by adding them to BR and allow for setting it to awesome (default settings indeed is another question).

Report message to a moderator

First Sergeant
Previous Topic: New Attachment System Beta
Goto Forum:
  


Current Time: Tue Mar 19 08:54:19 GMT+2 2024

Total time taken to generate the page: 0.02169 seconds