Home » MODDING HQ 1.13 » v1.13 Bug Reports » BUGZILLA report all bugs here!
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #335207]
|
Fri, 29 August 2014 08:09 
|
|
darkelf1986 |
 |
Messages:22
Registered:February 2014 |
|
|
RunAwayScientist - why is there 2 links?
Why do i need Visual Studio? Nothing is said about it in a description here
P.S. well i understand now... VS is needed for exe compilation...
[Updated on: Fri, 29 August 2014 09:58] by Moderator Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #335326]
|
Sun, 31 August 2014 21:02 
|
|
Flugente |
 |
Messages:3509
Registered:April 2009 Location: Germany |
|
|
Since we now have up to 15 different difficulty levels, I wanted to try it out. However, when starting with a new difficulty, I get the following error upon starting:

Code in initunderground.lua:
...
s["P3-1"].numElites = ({ 8, 10, 14, 20 })[difficultyLevel]
+ math.random(0, ({ 2, 5, 6, 0 })[difficultyLevel])
...
If I understand the code bit right, this will always crash if difficulty level is 4 or higher. Hmm... Perhaps some scripts are missing? Or are we supposed to just fill in tons of 0s here?
Report message to a moderator
|
|
|
|
Re: BUGZILLA report all bugs here![message #335337]
|
Sun, 31 August 2014 23:11 
|
|
Realist |
 |
Messages:28
Registered:September 2005 Location: Duesseldorf, Germany |
|
|
Quote:If I understand the code bit right, this will always crash if difficulty level is 4 or higher. Hmm... Perhaps some scripts are missing?
You're right indeed that with new difficulty levels this will result in an index out of bounds. However I don't think there are any scripts missing but rather the new feature is just not compatible with the existing scripts at this point.
The proper solution would probably be to specify further array elements in accordance with new difficulty levels or change the method of calculation entirely. As a quick and dirty hack you should be able to clamp the variable like this
local difficultyLevel = math.min(gameSettings["difficultyLevel"], 4)
in the BuildUndergroundSectorList function and likewise
newDIFFICULTY_LEVEL = math.min(newDIFFICULTY_LEVEL, 4)
in InitializeMines() in initmines.lua
[Updated on: Sun, 31 August 2014 23:15] by Moderator Report message to a moderator
|
Private 1st Class
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #335349]
|
Mon, 01 September 2014 07:31 
|
|
wanne (aka RoWa21) |
 |
Messages:1961
Registered:October 2005 Location: Austria |
|
|
FlugenteSince we now have up to 15 different difficulty levels, I wanted to try it out. However, when starting with a new difficulty, I get the following error upon starting:

Code in initunderground.lua:
...
s["P3-1"].numElites = ({ 8, 10, 14, 20 })[difficultyLevel]
+ math.random(0, ({ 2, 5, 6, 0 })[difficultyLevel])
...
If I understand the code bit right, this will always crash if difficulty level is 4 or higher. Hmm... Perhaps some scripts are missing? Or are we supposed to just fill in tons of 0s here?
Exactly, to get more difficulties working, you have to make changes to the LUA scripts. I have uploaded (which JAZZ send to me) an example with additional difficulties in our Modding-Examples SVN folder:
https://ja2svn.mooo.com/source/ja2/trunk/Documents/1.13%20Modding/Modding%20Examples
Just check the file "Additional Difficulty Settings Example.zip"
And here is what JAZZ told me:
Quote:
You should add the new of the difficulty in the file initmines.ini.
look :
-- 25 - Novice, 25 - Experienced, 20 - Expert, 15 - Insane, 30 - My Example 1, 3 - My Example 2
local numProductionIncreases = ({ 25, 25, 20, 15, 30, 3 })[newDIFFICULTY_LEVEL]
and look to initunderground.lua.
Also look to the file Gameinit.ini.
There is the there new function :
-- Get starting cash from DifficultySettings.xml
SetStartingCashDifLevel(newDIFFICULTY_LEVEL)
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #335696]
|
Thu, 11 September 2014 23:22 
|
|
Flugente |
 |
Messages:3509
Registered:April 2009 Location: Germany |
|
|
If you are not a coder, ignore this post.
Just fixed a really, really annoying error Buggler found in stable in r7507/7508. Basically, what happens was that a merc's inventory is full - including the slots on the legs - and the merc then picks up an MP holster. What is supposed to happen is that the holster is worn, and the items that are in the leg slots are moved to the holster or droppped to the floor.
However, what happened was that one of items dropped was tuned into a NADA, and the holster was turned into one of the items - so you have a camo kit in the LBE slot. You can get the savegame here.
Now, the problem here was basically that during picking up the item, we told the game to 'remove' the item from the sector inventory - and after that, we put it into our inventory. This is wrong, and I would like to remind any coder who might read this as to why. If we remove a world item, we don't NULL it - we set its existence to FALSE. This allows us to still access it (which we did here), but whenever new space in the inventory is needed (say, if we drop an item to the world), this world item slot and everything in it is fair game. Which is very, VERY bad if we are still working on the thing. If you remove a world item, you can no longer rely upon its existence. So do any work that needs to be done before that, okay?
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #335830]
|
Tue, 16 September 2014 22:20 
|
|
Flugente |
 |
Messages:3509
Registered:April 2009 Location: Germany |
|
|
wolf00unstable sci 7516/2145,game dont read data from options.ini[i set my own amount money on start] .... Hey, no running away!
To quote from this very another thread:
Flugente
ramzesLOLHello,
I have a rather weird bug.
Game does not read STARTING_CASH_NOVICE, STARTING_CASH_EXPERIENCED, STARTING_CASH_EXPERT STARTING_CASH_INSANE from Ja2_Options, it takes all other options (tested with arrival time and A.I.M availability) but not starting cash :/.
Im running r.7476 with wildfire 6.07 maps.
To check that my game does not read Ja2_Options from other folders than the folder that ive instaled r.7476 i have changed starting cash in EVERY SINGLE Ja2_Options file that i colud find on my hard drive and it still uses defalut values(in game).
Re: BUGZILLA report all bugs here!
For test porpuses Ive set STARTING_CASH_NOVICE to an unacceptable value, this is the result:
http://imgur.com/6wi5RTf
It sais that game will use 2000 but guess what it STILL uses defalut value of 45000 that i cannot change :/.
Other than that game runs great. First off, this is a bug with an unstable relase, not the '14 stable, so this post and all following posts should be moved to the right place. This issue does NOT happen in the '14 stable release.
Now, to the issue at hand. You, dear sir, are right to be confused. Very recently, a separate method to define game difficulty was added. Some values that were in JA2_Options.ini were moved to TableData/Data-1.13/DifficultySettings.xml. Here you can set those values, and add more difficulty levels (although doing so will crash your game, because apparently we don't test what we commit, so just don't). The starting cash bits in the ini are just relics - the game will read them, complain if you give bad ones, but never use them anyway.
Should you feel very confused by this right now, don't worry, you have every right to. This change was not publicly announced, so you have no chance of knowing unless you read our SVN logs daily :whythis: . Just edit the DifficultySettings.xml and wonder :dontknow2:
Report message to a moderator
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #336020]
|
Mon, 22 September 2014 19:34 
|
|
silversurfer |
  |
Messages:2793
Registered:May 2009 |
|
|
Revision 7491 breaks VS2008 code generation. It's not possible to create a working release exe anymore. The game will crash before it gets to the main menu.
Debug exe still runs.
Crash happens in Init.cpp:
strcpy(fileName, directoryName);
strcat(fileName, STRUCTUREDECONSTRUCTFILENAME);
SGP_THROW_IFFALSE(ReadInStructureDeconstructStats(fileName),STRUCTUREDECONSTRUCTFILENAME);
strcpy(fileName, directoryName);
strcat(fileName, STRUCTURECONSTRUCTFILENAME);
SGP_THROW_IFFALSE(ReadInStructureConstructStats(fileName),STRUCTURECONSTRUCTFILENAME);
When I comment these lines the game starts.
edit: To be more precise - the crash happens for this call in function "ReadInStructureDeconstructStats" in "XML_StructureDeconstruct.cpp" and "ReadInStructureConstructStats" in "XML_StructureConstruct.cpp":
if(!XML_Parse(parser, lpcBuffer, uiFSize, TRUE))
[Updated on: Tue, 23 September 2014 11:55] by Moderator Report message to a moderator
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #336097]
|
Wed, 24 September 2014 17:41 
|
|
silversurfer |
  |
Messages:2793
Registered:May 2009 |
|
|
First test was to remove the contents from both XMLs and just leave this in:
Now the release exe starts fine.
Second test was to comment some more code. First thing I did was comment the deconstruction call in init.cpp. That way I only have to look at the construction part.
Then I commented some lines in "structureconstructEndElementHandle" to get the exe running with the default XMLs:
Toggle Spoiler
structureconstructEndElementHandle(void *userData, const XML_Char *name)
{
structureconstructParseData * pData = (structureconstructParseData *)userData;
if(pData->currentDepth <= pData->maxReadDepth) //we're at the end of an element that we've been reading
{
if(strcmp(name, "STRUCTURESLIST") == 0)
{
pData->curElement = ELEMENT_NONE;
}
else if(strcmp(name, "STRUCTURE") == 0)
{
pData->curElement = ELEMENT_LIST;
// we do NOT want to read the first entry -> move stuff by 1
if(structureconstructcnt < pData->maxArraySize)
{
// pData->curArray[structureconstructcnt] = pData->curFood; //write the data into the table
}
++structureconstructcnt;
}
else if(strcmp(name, "usCreationItem") == 0)
{
pData->curElement = ELEMENT;
pData->curFood.usCreationItem = (UINT16) atol(pData->szCharData);
}
else if(strcmp(name, "usItemStatusLoss") == 0)
{
pData->curElement = ELEMENT;
pData->curFood.usItemStatusLoss = (UINT8) atol(pData->szCharData);
}
else if(strcmp(name, "szTileSetName") == 0)
{
pData->curElement = ELEMENT;
strncpy(pData->curFood.szTileSetName, pData->szCharData, 20);
}
else if(strcmp(name, "northfacingtile") == 0)
{
pData->curElement = ELEMENT;
// pData->curFood.northtilevector.push_back( (UINT8) atol(pData->szCharData) );
}
else if(strcmp(name, "southfacingtile") == 0)
{
pData->curElement = ELEMENT;
// pData->curFood.southtilevector.push_back( (UINT8) atol(pData->szCharData) );
}
else if ( strcmp( name, "eastfacingtile" ) == 0 )
{
pData->curElement = ELEMENT;
// pData->curFood.easttilevector.push_back( (UINT8)atol( pData->szCharData ) );
}
else if ( strcmp( name, "westfacingtile" ) == 0 )
{
pData->curElement = ELEMENT;
// pData->curFood.westtilevector.push_back( (UINT8)atol( pData->szCharData ) );
}
pData->maxReadDepth--;
}
pData->currentDepth--;
}
Looks like the game has problems with the vectors and some array. More writing over foreign memory regions perhaps?
Report message to a moderator
|
|
|
|
Pages (42): [ 36 ] |
 |
Goto Forum:
Current Time: Thu Nov 30 19:20:57 GMT+2 2023
Total time taken to generate the page: 0.05435 seconds
|