Home » MODDING HQ 1.13 » v1.13 Bug Reports » BUGZILLA report all bugs here!
Re: BUGZILLA report all bugs here![message #323490] Tue, 30 July 2013 21:47 Go to previous messageGo to next message
Randok

 
Messages:294
Registered:March 2004
Thank you Smile
Re: BUGZILLA report all bugs here![message #323493] Tue, 30 July 2013 22:30 Go to previous messageGo to next message
JMich

 
Messages:560
Registered:January 2011
Location: Greece
Strohmann
  • When hiring someone from M.E.R.C. the gear cost doesn't get substracted from the account. A.I.M. does work in this regard.

Intentional. M.E.R.C. doesn't get any money in advance, they take it when you settle your tab.
Re: BUGZILLA report all bugs here![message #323498] Tue, 30 July 2013 23:43 Go to previous messageGo to next message
SharkD

 
Messages:359
Registered:July 2003
Flugente
r6260 restores savegame compatibility and fixes a few code issues. It's incompatible to 6258, but few people should have that anyway.

Will 6201 savegames work with it?
Re: BUGZILLA report all bugs here![message #323499] Tue, 30 July 2013 23:46 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Flugente
Randok is fully correct. When using NCTH and not firing at a soldier, the NCTH calculation throws an error. Fixed in r6261.


Thanks for fixing that (actually my fault Embarrassed ). When I moved that agile/experienced check out of the height difference check I overlooked that little pTarget detail...


Strohmann
Items.xml: Setting PercentReloadTimeAPReduction to negative values does only work if it's present on an attachment, just on a weapon doesn't work.


Oh yes and that's not the only tag that isn't working on the gun. Fixing... <- fixed in rev 6264


edit:

Strohmann
Items.xml: In a exchange with silversurfer he said the tooltip for is wrong, positive values act as a penalty, not a bonus.


Do we fix the description or the code in this case? I have no idea how many modders use this tag.

[Updated on: Wed, 31 July 2013 23:36] by Moderator


Re: BUGZILLA report all bugs here![message #323500] Tue, 30 July 2013 23:46 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
It should, unless your 6201 exe was built with odd builddefines. Depri's SCI should be ok.


Re: BUGZILLA report all bugs here![message #323502] Wed, 31 July 2013 00:08 Go to previous messageGo to next message
Strohmann

 
Messages:288
Registered:August 2011
Location: Division Thought Crimes
Quote:
Strohmann

Items.xml: In a exchange with silversurfer he said the tooltip for is wrong, positive values act as a penalty, not a bonus.
Do we fix the description or the code in this case? I have no idea how many modders use this tag.

I vote for just the tooltip, as handling is a similar case where positive values don't mean bonuses.
Re: BUGZILLA report all bugs here![message #323503] Wed, 31 July 2013 00:24 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3744
Registered:July 2009
silversurfer
Strohmann
Items.xml: In a exchange with silversurfer he said the tooltip for is wrong, positive values act as a penalty, not a bonus.


Do we fix the description or the code in this case? I have no idea how many modders use this tag.
Per default, assume that wil uses, abuses and misuses any tag extensively.


Re: BUGZILLA report all bugs here![message #323611] Sat, 03 August 2013 23:23 Go to previous messageGo to next message
jerry18
Messages:2
Registered:July 2013
JA2+SCI_Unstable_Revision_6263_on_GameDir_1718 = the game is completely without all voices/sounds/music.

I could not use previous revision = 6258 because of savegame compatibility, so for me the last working rev. is 6239.

Changing of "WEAPON_SOUND_EFFECTS_VOLUME" parameter change nothing.


EDIT: Solved - this was problem of multiple copies of JA2 = some of them were without sound.

[Updated on: Sun, 04 August 2013 10:24] by Moderator

Re: BUGZILLA report all bugs here![message #323614] Sun, 04 August 2013 00:14 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
In the current trunk, MERC_WEBSITE_ALL_MERCS_AVAILABLE does not work correctly. I updated from an older savegame, and now mercs that were previously hirable no longer have their webpage displayed. I suspect this has something to do with the recent Speck/JA1 guide business. Please fix.


Re: BUGZILLA report all bugs here![message #323623] Sun, 04 August 2013 10:15 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Flugente
In the current trunk, MERC_WEBSITE_ALL_MERCS_AVAILABLE does not work correctly. I updated from an older savegame, and now mercs that were previously hirable no longer have their webpage displayed. I suspect this has something to do with the recent Speck/JA1 guide business. Please fix.


Do you have a savegame and Inis to test this? Unfortunately I have only current saves and these already have John and the natives.

Re: BUGZILLA report all bugs here![message #323626] Sun, 04 August 2013 12:49 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
Not really. I am playing with my mod, into which I frequently merge the trunk.


Re: BUGZILLA report all bugs here![message #323637] Sun, 04 August 2013 15:41 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Quickly looking at the code it seems that availability is initially handled in mercs.cpp function GameInitMercs(). This is fine for a new game. However, availability is also stored in the savegame and as long as a merc did not exist when creating the savegame there is no info on his availability.

SaveNewMercsToSaveGameFile( HWFILE hFile ) is the function to save the data to the savegame.
LoadNewMercsFromLoadGameFile( HWFILE hFile ) is the function to load it.

gConditionsForMercAvailability is the array which stores the data. Could be something wrong with it because John Kulba and the natives were inserted after its initialization? It contains the profile ID so every member should be unique but this array is probably the best starting point for the search.

Without a problematic savegame it is hard to debug where something goes wrong.

Re: BUGZILLA report all bugs here![message #323662] Mon, 05 August 2013 08:58 Go to previous messageGo to next message
Buggler

 
Messages:208
Registered:November 2009
Flugente
In the current trunk, MERC_WEBSITE_ALL_MERCS_AVAILABLE does not work correctly. I updated from an older savegame, and now mercs that were previously hirable no longer have their webpage displayed. I suspect this has something to do with the recent Speck/JA1 guide business. Please fix.

Use this testsave.
http://www.mediafire.com/?zdl81dfox5rcpdo

Using default Ja2_Options.ini except MERC_WEBSITE_IMMEDIATELY_AVAILABLE & MERC_WEBSITE_ALL_MERCS_AVAILABLE = TRUE.

Started game on Depri's 6239 and bugged on 6263. Last 1/3 merc pages are repeated merc profiles.
Re: BUGZILLA report all bugs here![message #323666] Mon, 05 August 2013 12:22 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Thanks Buggler. This helped to catch the problem. The bug was introduced in rev. 6258 with function GetAvailableMercIndex(UINT8 gubCurMercIndex). This function is supposed to return the uiIndex of the merc for display. Unfortunately it never hits for all the new mercs that were not present in the savegame because their availability is set FALSE, so the function returns an ID that is incorrect.

I don't know why this new function was introduced instead of using the existing GetMercIDFromMERCArray(UINT8 ubMercID) function. I'll try to figure it out and get in touch with anv.

Re: BUGZILLA report all bugs here![message #323670] Mon, 05 August 2013 15:21 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
After replacing the new GetAvailableMercIndex(UINT8 gubCurMercIndex) function with the old one I get the correct mercs displayed again. Problem is that still our availability info is incorrect in gConditionsForMercAvailability and there are mercs displayed that shouldn't be displayed.

During game initialization the parameter LaptopSaveInfo.gubLastMercIndex is set to the array index of the last available merc. In my test with MERC_WEBSITE_ALL_MERCS_AVAILABLE = TRUE this parameter was set to 40 (that's all the mercs including natives but without Speck and Kulba).

Now I loaded the old savegame from Buggler which has LaptopSaveInfo.gubLastMercIndex set to 42. So the game says "Look, we have 43 mercs available for the M.E.R.C. website! Smile " and now I'm able to see all mercs including Speck and John Kulba whom I haven't even rescued yet... Sad

Actually there is tons of more problems than that...
The game is not designed to load additional mercs while mid game and it also doesn't like switching MERC_WEBSITE_ALL_MERCS_AVAILABLE on and off mid game so don't ever do that!

This problem is a little over my head. I don't even know where to start fixing. GameInitMercs? LoadSavedGame? Merc Website Display? Handling of MERC_WEBSITE_ALL_MERCS_AVAILABLE? :hmm: :roulette:

Re: BUGZILLA report all bugs here![message #323671] Mon, 05 August 2013 15:36 Go to previous messageGo to next message
Gambigobilla

 
Messages:714
Registered:July 2008
Why not just make duplicates of Speck and John Kulba? Although that would make it possible to rescue John with himself. Maybe make an exception for John and Speck so they are excluded from MERC_WEBSITE_ALL_MERCS_AVAILABLE=TRUE
Re: BUGZILLA report all bugs here![message #323673] Mon, 05 August 2013 16:19 Go to previous messageGo to next message
Buggler

 
Messages:208
Registered:November 2009
silversurfer
Now I loaded the old savegame from Buggler which has LaptopSaveInfo.gubLastMercIndex set to 42. So the game says "Look, we have 43 mercs available for the M.E.R.C. website! Smile " and now I'm able to see all mercs including Speck and John Kulba whom I haven't even rescued yet... Sad

Uploaded savegame was started on the "pre-Speck/John" sourcecode & latest (post-Speck/John) GameData which maybe the cause. Razz

Maybe should test run with a pure "pre-Speck/John" savegame to confirm... Apologies for any unintended headaches.
Re: BUGZILLA report all bugs here![message #323676] Mon, 05 August 2013 16:35 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Well, Speck and John are not the only problem. The real problem lies somewhere else. There is two tags in MercAvailability.xml which are supposed to be used for merc availability:




Unfortunately they are not used and updated properly to form the list of mercs. If they were used correctly it wouldn't matter if you add a merc or switch MERC_WEBSITE_ALL_MERCS_AVAILABLE=TRUE mid game. The game would have valid data available and work just fine.

Re: BUGZILLA report all bugs here![message #323698] Tue, 06 August 2013 13:44 Go to previous messageGo to next message
Parkan

 
Messages:448
Registered:April 2010
Location: Russia,Sevastopol

Found strange bug.In ja2_option.ini there is an option-Enchanced close combat.If it turned on-it allows to strip out all items from enemy,and if this option turned off-it still allowed to strip down all items from enemy.Strange thing,really.using SCI with 6263 version of exe.
Re: BUGZILLA report all bugs here![message #323704] Tue, 06 August 2013 15:01 Go to previous messageGo to next message
Uriens

 
Messages:332
Registered:July 2006
JA2 exe version 6263.
JA2 svn version 1720.

When using CTRL+left arrow or right arrow keys to change merc position in a squad, merc pictures get messed up if the selected merc is in position 7 or above (need to have squads of 8 or 10 enabled for this, of course). If you try to move merc in position 6 or lower, it seems to work fine.
Re: BUGZILLA report all bugs here![message #323708] Tue, 06 August 2013 18:27 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
What exactly do you mean by "messed up"? I have a team of 10 mercs and I can move whatever merc between positions 1 to 10 just fine. Can you please explain further and maybe post a screenshot?

Re: BUGZILLA report all bugs here![message #323729] Wed, 07 August 2013 00:31 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
@silversurfer: Regarding the MERC website error... I take it the error only happens when one uses 'pre-John' savegames with 'post-John' exes... but its ok when one starts a new game now? That would make it less dramatic.

Would it perhaps be possible to add a flagmask to the merc website data entries, and add a new tag 'special availability conditions'? The way I understood was that John .and Speck have special recruitment conditions. Hardcoding stuff depending on dynamic xml entries is bad, but perhaps this could be eased? As in, the ini option for all available behaves like it used to, except for those with that special tag. Also, is there a reason new entries aren't added to the end of that xml?


Re: BUGZILLA report all bugs here![message #323743] Wed, 07 August 2013 12:32 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Now that you mention it, I have no idea why the natives have been inserted in the middle of the XML. That was a bad idea indeed. Sad

[Updated on: Wed, 07 August 2013 15:35] by Moderator


Re: BUGZILLA report all bugs here![message #323744] Wed, 07 August 2013 13:02 Go to previous messageGo to next message
Uriens

 
Messages:332
Registered:July 2006
I'd love to post a screenie, but at the moment I can't seem to be able to recreate it. It happened at the very start of the game when I dropped in Omerta and tactical combat started. I had Scully move from position 10 to the left and his picture changed to the Wolf's. My female IMP even got black picture instead of the normal one. Some other mercs also switched pictures as I was moving Scully around but only to those on 7-9 positions were affected. Positions 1-6 seemed unaffected. I had to reload game in order to get pictures back to normal.

However, right now in Drassen I tried moving people around and it seems to work fine with no pictures swap problems. I'll try that again when I get in tac combat, it may be related to that.

Edit: Nope, in tac combat seems to work fine too. I'm not sure what caused it first time. If I ran into a bug again I'll post it, but at the moment it seems to work fine.

[Updated on: Wed, 07 August 2013 13:18] by Moderator

Re: BUGZILLA report all bugs here![message #323745] Wed, 07 August 2013 14:20 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Uriens

However, right now in Drassen I tried moving people around and it seems to work fine with no pictures swap problems. I'll try that again when I get in tac combat, it may be related to that.

Edit: Nope, in tac combat seems to work fine too. I'm not sure what caused it first time. If I ran into a bug again I'll post it, but at the moment it seems to work fine.

Good to hear that. Smile


Flugente

Also, is there a reason new entries aren't added to the end of that xml?

I think I know now why the natives have been inserted in the middle of the XML. Each merc has a tag and a tag which defines when he should become available. The natives just fit in that spot. For normal mercs when conditions for (the amount of money paid to M.E.R.C) and (number of days passed) are met a new event will be added and the merc will become available.

But the whole concept of merc availability is a bit problematic. All mercs from MercAvailability.xml are loaded into the array gConditionsForMercAvailability. This feeds gubMercArray and also affects LaptopSaveInfo.gubLastMercIndex which is the index of the last merc that should be displayed on the M.E.R.C website. LaptopSaveInfo.gubLastMercIndex will be increased as new mercs become available over time. When mercs are added within the list the concept is bound to go *booom*. :bomb:

example merc list at the time the game was saved:

[0]merc1
[1]merc2
[2]merc3
[3]merc4
[4]merc5
[5]merc6

LaptopSaveInfo.gubLastMercIndex is at 5. Now somebody inserts merc7 into MercAvailability.xml. We load our savegame and get this:

[0]merc1
[1]merc2
[2]merc3
[3]merc7
[4]merc4
[5]merc5
[6]merc6

LaptopSaveInfo.gubLastMercIndex is still at 5. Sorry merc6, we will miss you. :whythis:

I have no idea how to fix this. So that also means no new reevaluate function because I simply have no data in the savegame to evaluate. The LaptopSaveInfo.gubLastMercIndex is the only thing that I could use but that doesn't tell me which mercs were available when the game was saved. :rant2:

Re: BUGZILLA report all bugs here![message #323747] Wed, 07 August 2013 15:36 Go to previous messageGo to next message
RoWa21

 
Messages:2002
Registered:October 2005
Location: Austria
silversurfer
Now that you mention it, I have no idea why the natives have been inserted in the middle of the XML. That was a bad idea indeed. Sad


If it helps, we can move the entries of John Kulba and the 3 Natives to the end of the XML file.
I don't see any reason, why anv moved them inside the xml and not to the end. So feel free to move them at the end if you need.

silversurfer

I think I know now why the natives have been inserted in the middle of the XML. Each merc has a tag and a tag which defines when he should become available. The natives just fit in that spot. For normal mercs when conditions for (the amount of money paid to M.E.R.C) and (number of days passed) are met a new event will be added and the merc will become available.


In source code revision 6258 there was a source code change by anv, regarding the unlocking of mercs from MercAvailability.xml.
I put that in the SVN history:

"Improvement: MERC mercs get unlocked according to their own availability conditions, not to their order in MercAvailability.xml"

[Updated on: Wed, 07 August 2013 15:44] by Moderator



Re: BUGZILLA report all bugs here![message #323751] Wed, 07 August 2013 17:33 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
RoWa21

If it helps, we can move the entries of John Kulba and the 3 Natives to the end of the XML file.
I don't see any reason, why anv moved them inside the xml and not to the end. So feel free to move them at the end if you need.


That won't help. Those merc arrays work like this:

Lowest index numbers are the mercs that are available from the start. Increasing index means increasing requirements for availability. LaptopSaveInfo.gubLastMercIndex points to the index in the array up to that mercs have been enabled for the M.E.R.C website.
They need to be in order.

example:
[0]merc1 day 0 money 0
[1]merc2 day 0 money 0
[2]merc3 day 2 money 100
[3]merc4 day 2 money 100
[4]merc5 day 2 money 100
[5]merc6 day 5 money 500
...

At day 0 we will have merc 1 and merc2 available and LaptopSaveInfo.gubLastMercIndex will be 1. After day 2 and 100 dollars we get three additional mercs and LaptopSaveInfo.gubLastMercIndex will be set to 4. If you move merc3, 4 and 5 below merc6 you will get this:

[0]merc1 day 0 money 0
[1]merc2 day 0 money 0
[2]merc6 day 5 money 500
[3]merc3 day 2 money 100
[4]merc4 day 2 money 100
[5]merc5 day 2 money 100

With this order on day 2 the game will increase LaptopSaveInfo.gubLastMercIndex from 1 to 4 because there are three mercs which should become available. Now what chaos do we have? Merc6 is available although he should be unlocked on day 5 and merc5 will not be available although he is supposed to be unlocked.

This is a design problem and there are only two solutions that I can think of at the moment:

1. Don't ever change MercAvailability.xml mid game and keep the correct sort order.
Well, this is not really a solution because it doesn't solve the problem with special availability options.
Just imagine that we have another merc below John Kulba that is supposed to be unlocked at day x and that day has come. LaptopSaveInfo.gubLastMercIndex is increased by one and BINGO - say "Hello" to Mr. John Kulba instead! :wave:

2. Redesign the whole merc availability handling. <- too complicated for me :dongetit:

[Updated on: Wed, 07 August 2013 17:35] by Moderator


Re: BUGZILLA report all bugs here![message #323764] Wed, 07 August 2013 21:18 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
Also related to the new mercs:

When you have any of the natives hired, one can no longer shop from shopkeepers. When opening the buy/repair/whatever menu, the game builds a list of all their 33faces. As the natives do not have such faces, the game receives an error and aborts opening the menu.

Fix will be easy: simply add those pictures.

Morale of the story: When adding new faces, add all faces, not just some.


Re: BUGZILLA report all bugs here![message #323773] Thu, 08 August 2013 04:19 Go to previous messageGo to next message
pheloncab

 
Messages:281
Registered:August 2004
Location: So. Cal. or texas
As a non programmer i'm not sure how much adjusting this array issue really will require math/formulae wise.. What I was wondering was if you could add a binary state to the array
so it would be merc day # $$ true/false

Set normal mercs to all be true, the specials are false at creation, then the special item happens it changes this flag to true.

then your merc availability would be adding a check on the flag before displaying the possible mercs for you to hire.
Re: BUGZILLA report all bugs here![message #323776] Thu, 08 August 2013 11:17 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
pheloncab
As a non programmer i'm not sure how much adjusting this array issue really will require math/formulae wise.. What I was wondering was if you could add a binary state to the array
so it would be merc day # $$ true/false

We already have this flag. It's the tag in MercAvailability.xml. When this is set the merc is available from the start. The game sets this as well when a merc becomes available over time because of days, money or (now) other circumstances (John rescued).
is part of the gConditionsForMercAvailability array which is saved in the savegame. Hey, wait a minute! One of the problems is right there!

Our gubMercArray (the list of mercs for the M.E.R.C website) is populated directly by gConditionsForMercAvailability in function GameInitMercs(). This is done before the savegame is loaded and therefore it only has the current default data which doesn't necessarily match our savegame data. :thinkerg:
So gubMercArray has a different list of mercs than gConditionsForMercAvailability that we loaded from the savegame. This would explain Flugentes problem that after 6258 (and its GameDir) there were different mercs available than before. I think that this can be fixed easily.


silversurfer
The bug was introduced in rev. 6258 with function GetAvailableMercIndex(UINT8 gubCurMercIndex). This function is supposed to return the uiIndex of the merc for display. Unfortunately it never hits for all the new mercs that were not present in the savegame because their availability is set FALSE, so the function returns an ID that is incorrect.

I don't know why this new function was introduced instead of using the existing GetMercIDFromMERCArray(UINT8 ubMercID) function. I'll try to figure it out and get in touch with anv.

Now it is also clearer why anv changed that function to select available mercs. Before it was not checked if a merc had its set TRUE. So it is actually a good thing that anv created this new function. It will probably not work correctly with savegames created before 6258 but it should work fine with newer ones.

Re: BUGZILLA report all bugs here![message #323789] Thu, 08 August 2013 21:07 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Ok, I think that I fixed part of the problems with merc availability for older savegames.

The game now takes the array gConditionsForMercAvailability from the savegame and uses this to re-populate the list of mercs for the M.E.R.C website (gubMercArray). Mercs that were unlocked (flag StartMercsAvailable == TRUE) stay unlocked.
If you happen to have a savegame where this flag was never set correctly for any of the mercs and you want to be able to recruit them there is a workaround available. If you set MERC_WEBSITE_ALL_MERCS_AVAILABLE = TRUE in Ja2_Options.ini all mercs are unlocked. This was not possible in the past but now it is.

There is one drawback with this fix. It's not possible to add or change M.E.R.C mercs mid game. Well, actually not much difference from the past (as we have learned). Very Happy
The array from the savegame always takes precedence. If someone wants to improve the new function please do so.

The new function is located here:

Laptop\mercs.cpp
void RevaluateMercArray()

It's not in the current trunk and I wonder if it should be tested a little more. Flugente, could you please test it with your broken savegame? If you like the fix you can commit it to SVN later. Of course anybody else is welcome to test it too. Smile

Here is the patch file:
*removed*
Bug is fixed in revision 6278.

Btw. I was able to fix Bugglers test savegame with the new code. It was started with MERC_WEBSITE_ALL_MERCS_AVAILABLE = TRUE and somehow had a merc counter of 43. The list and counter were fixed by the new function which left 41 mercs available like it is supposed to be. So I'm quite please with the result. Cool

[Updated on: Sat, 10 August 2013 12:24] by Moderator


Re: BUGZILLA report all bugs here![message #323798] Thu, 08 August 2013 23:00 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
Merged it into my mod, and it seems to work just fine. Will test a bit more and then commit, thank you!

For the record: will this allow randomly inserting new mercs in the middle of the array in the future, or should modders still avoid that?


Re: BUGZILLA report all bugs here![message #323799] Thu, 08 August 2013 23:26 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Flugente

For the record: will this allow randomly inserting new mercs in the middle of the array in the future, or should modders still avoid that?

The problem is that any merc that is not present in the savegame will not be made available with the new function because he is not in the gConditionsForMercAvailability array that is read from the savegame. This means that a modder could insert some merc anywhere but you will need to start a new game to be able to recruit him.

If someone could expand the new function and provide a solution to dynamically update the gConditionsForMercAvailability array from the savegame with the data from MercAvailability.xml it would be great because it would allow to add mercs mid game.

Remember what I did in function LoadSavedMercProfiles( ... ) in SaveLoadGame.cpp to add new merc profiles mid game? This is somewhat obsolete now. New merc profiles will still be imported but since their availability is not updated they won't show up on the M.E.R.C website. Would be cool if someone could change that.

Re: BUGZILLA report all bugs here![message #323804] Fri, 09 August 2013 00:06 Go to previous messageGo to next message
Flugente

 
Messages:3481
Registered:April 2009
Location: Germany
Committed in r6278.


Re: BUGZILLA report all bugs here![message #323833] Fri, 09 August 2013 18:30 Go to previous messageGo to next message
sevenfm

 
Messages:2087
Registered:December 2012
Location: Russian Federation
Using CTRL+ in tactical breaks the game ( when i try to sort mercs faces in tactical).
Latest SVN + 6279.exe
Windows 7
No mods, all default ini.


Re: BUGZILLA report all bugs here![message #323834] Fri, 09 August 2013 19:20 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
Sevenfm
Using CTRL+ in tactical breaks the game ( when i try to sort mercs faces in tactical).
Latest SVN + 6279.exe
Windows 7
No mods, all default ini.


What does "breaks the game" mean? Does it crash? Do your mercs vanish? Does Deidranna commit suicide?

The feature works fine on my machine except for one condition that I noticed a moment ago. If someone is talking when I try to do the swap the game crashes. Is your report about this issue?

I implemented a check for the talking condition now so the game will refuse to swap mercs as long as someone is talking. Until the fix is committed please refrain from swapping mercs as long as there is active dialogue/monologue.

If you are talking about a different problem please clarify so I know what I need to look for.

Re: BUGZILLA report all bugs here![message #323835] Fri, 09 August 2013 19:36 Go to previous messageGo to next message
sevenfm

 
Messages:2087
Registered:December 2012
Location: Russian Federation
silversurfer:
I tested again, and you are right - this happens only with "speaking" mercs, as you said.
Just didn't know that you are working on fixing it already Smile



Re: BUGZILLA report all bugs here![message #323836] Fri, 09 August 2013 19:43 Go to previous messageGo to next message
silversurfer

 
Messages:2632
Registered:May 2009
I wasn't working on it. Very Happy

I was just testing again because of your report and tried to swap directly after cheating in a new opponent. My merc was still in his "Enemy sighted!" speech and *crash*

I'll hand in the fix.

Re: BUGZILLA report all bugs here![message #323896] Sun, 11 August 2013 22:39 Go to previous messageGo to next message
RoWa21

 
Messages:2002
Registered:October 2005
Location: Austria
silversurfer
I wasn't working on it. Very Happy

I was just testing again because of your report and tried to swap directly after cheating in a new opponent. My merc was still in his "Enemy sighted!" speech and *crash*

I'll hand in the fix.


Thanks for the fix, which was applied in revision 6281


Re: BUGZILLA report all bugs here![message #323897] Sun, 11 August 2013 22:40 Go to previous messageGo to previous message
RoWa21

 
Messages:2002
Registered:October 2005
Location: Austria
Flugente
Also related to the new mercs:

When you have any of the natives hired, one can no longer shop from shopkeepers. When opening the buy/repair/whatever menu, the game builds a list of all their 33faces. As the natives do not have such faces, the game receives an error and aborts opening the menu.

Fix will be easy: simply add those pictures.

Morale of the story: When adding new faces, add all faces, not just some.


I currently added placeholders (John Kulba face) for the missing 3 natives 33-faces. I hope anv will do the missing 33 faces soon.


Previous Topic: 1440x900 resolution bug.
Next Topic: Mine income adjustment range
Goto Forum:
  


Current Time: Thu Feb 27 22:19:18 EET 2020

Total time taken to generate the page: 0.03554 seconds