Home » MODDING HQ 1.13 » v1.13 Bug Reports » Bugs: Unofficial releases (SCI's), unstable and DEV builds (Read the first post before posting!)
|
|
|
|
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #351998 is a reply to message #341931]
|
Fri, 12 January 2018 02:17 
|
|
Shadow |
  |
Messages:39
Registered:December 2008 Location: Argentina |
|
|
Boxing in San Mona still appears to be glitchy to some extent, as of 8508.
After the second fight of my first visit to the club, my merc exited the ring on the far side from Darren, and while he came to my guy, hopping in and out of the ring, the "scene" just ended there, without handing over the winnings. After that, I could trigger another fight, but paying again as if nothing wrong had happened.
Might be prevented staying close to Darren's side of the ring, but I'm not sure. Just thought you guys should know.
[Updated on: Fri, 12 January 2018 02:18] Report message to a moderator
|
Private 1st Class
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352079 is a reply to message #351998]
|
Fri, 19 January 2018 03:05 
|
|
koorlyvoorly |
Messages:4
Registered:January 2018 |
|
|
got a graphic glitch: while at strategic map if you unfold the merc inventory the bottom part is not visible because history window goes on top of it.
i can still blindly put items into backpacks but i cant see whats there. I m using 1024x600 resolution, of course problem goes away if you set higher resolutions, but those are too hard for my eyes.
8517 build
i'd like to know if i can fix this ...
3iff wrote on Tue, 29 August 2017 13:08V8440.
A problem occurs with 800 * 600 graphic format.
When opening the merc inventory on the strategic map, the message bar remains OVER the lower part of the merc inventory so the lower section and backpack are no longer visible. They can still be accessed but it's guesswork as to which pockets are in use/free.
i think its the same bug
Thing is, 8408 version did not have that bug, merc inventory went on top of the message window.
Maybe there s any files, or lines we can replace\edit to get rid of that?
Question: If i reinstall the game, then get 8437 version (without that bug) will it be safe for me to use my savegames?
[Updated on: Fri, 19 January 2018 12:42] Report message to a moderator
|
Civilian
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352104 is a reply to message #341931]
|
Sat, 20 January 2018 20:02 
|
|
Obsidianson |
Messages:1
Registered:January 2018 Location: Connecticut |
|
|
Using the lastest SCI 8517, I've had my game duplicate the inventory of Drassen airport continuously when attacking an enemy force on the map. After the battle there is the items dropped by the enemy and an exact duplicate of all of the item in Drassen, sometimes many times over, the Alma Military HQ had over 10,000 items, a prefect duplication of all my item in Drassen 9 times over. I'm swimming in G3A3's.
Report message to a moderator
|
Civilian
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352127 is a reply to message #341931]
|
Mon, 22 January 2018 16:57 
|
|
Shadow |
  |
Messages:39
Registered:December 2008 Location: Argentina |
|
|
About San Mona boxing again (still 8508), I've been checking daily for the past several game days, in the afternoon around 16:00, and Darren keeps saying the fighters are resting. I'm seeing them there by the ring, two Strong and one Healthy. They look fine enough to me, but perhaps that third one needs to be Strong too? Are the fighters supposed to actually heal or is the "resting" thing intended to be just a 24-hour timer?
Is this some kind of hidden cap to limit gains from the fights? I had about three non-consecutive days of three fights each before this started happening (never visiting Kingpin at his place), which isn't exactly the intended behaviour, either, as far as I know. Thought I'd have indefinite fights, but only one per day after the initial round of three.
Why is this event so problematic, especially after all these years of 1.13 development? Honest question.
[Updated on: Mon, 22 January 2018 16:58]
Shadow's Enemy ProfilesReport message to a moderator
|
Private 1st Class
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352222 is a reply to message #352140]
|
Mon, 29 January 2018 22:49 
|
|
Colt .45 Peacemaker |
  |
Messages:409
Registered:June 2016 Location: Norway |
|
|
Hello to all
Koorlyvoorly wrote on 19 January 2018
got a graphic glitch: while at strategic map if you unfold the merc inventory the bottom part is not visible because history window goes on top of it.
i can still blindly put items into backpacks but i cant see whats there. I m using 1024x600 resolution, of course problem goes away if you set higher resolutions, but those are too hard for my eyes.
8517 build
i'd like to know if i can fix this ...
3iff wrote on Tue, 29 August 2017 13:08
V8440.
A problem occurs with 800 * 600 graphic format.
When opening the merc inventory on the strategic map, the message bar remains OVER the lower part of the merc inventory so the lower section and backpack are no longer visible. They can still be accessed but it's guesswork as to which pockets are in use/free.
I am using the Unstable Revision 8468 on GameDir 2385 and i am encountering the same issue at 800 x 600 resolution. Is there a quick fix for it ? Or if it will be addressed in the near future unstable releases ? I hope that the next stable release will be playable in 800 x 600, as the 1024 x 768 resolution is kind of hard on my eyes as well. Beyond that, everything else seems to be working fine, great job as always 
[Updated on: Mon, 29 January 2018 22:52]
Nipson anomimata mi monan opsinReport message to a moderator
|
Master Sergeant
|
|
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352507 is a reply to message #352449]
|
Wed, 21 February 2018 22:19 
|
|
Flugente |
 |
Messages:3507
Registered:April 2009 Location: Germany |
|
|
@neobit: I cannot reproduce the issue with the crash when talking to the militia - a savegame would be very much appreciated.
As to the scrolling issue - I sometimes, but not reproducibly, have continuous scrolling issues after doing something in windows while the game is in windowed mode, likely some key combination, but I'm not sure which.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352508 is a reply to message #352507]
|
Wed, 21 February 2018 22:48 
|
|
Flugente |
 |
Messages:3507
Registered:April 2009 Location: Germany |
|
|
@Gopas (and likely other people who have also mentioned this):
r8524: Fix: on low resolutions, the message log blocks parts of the inventory,so deactivate the log in that case.
The bug was a result of me doing an earlier fix, as there were times were the log wasn't properly updated at all even though there was nothing blocking it. Now it should only be non-active if the inventory is open and we use a low resolution (640x480, 960x540 or 800x600).
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352536 is a reply to message #352512]
|
Sat, 24 February 2018 12:35 
|
|
Colt .45 Peacemaker |
  |
Messages:409
Registered:June 2016 Location: Norway |
|
|
Thank you for the tip Flugente, i just saw it today 
I think that i've seen an option about deactivating the log, in the INI.Options. But during combat, the messages where my mercs hear movement in specific directions, are flashing on for a fraction of a second, not enough time to read them, in which case i have to go to the strategic screen to read the log. The log is actually very useful. I may have to endure the higher resolution rather than losing the log, i can live with it, it's not a biggie. Oh and another thing i have noticed, in the vanilla game the log was mentioning everything, including speech. In the 1.13 mods the log doesn't include the speech from everyone. Is there an option to make all speech messages visible ?
[Updated on: Sat, 24 February 2018 13:04]
Nipson anomimata mi monan opsinReport message to a moderator
|
Master Sergeant
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352673 is a reply to message #352536]
|
Sun, 11 March 2018 14:41 
|
|
Flugente |
 |
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Discovered (and fixed) a very odd bug in r8544: Fix: If 'forced turn mode' is active, sometimes enemy groups already present in an enemy-occupied sector are interpreted as pending reinforcements, causing them to spawn at the sector edges instead of inside the sector.
This was somewhat tricky to find, as it only happened depending on the result of random number generation, and even then only if there were hostile civilians and enemy groups (not garrisons) present. As a result, the easiest way to get this bug was to take Tixa in autoresolve (so Warden won't be killed), retreat, let the sector be taken by a patrol (not by the group that is send to retake it), and then enter the sector.
[Updated on: Sun, 11 March 2018 14:46]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352679 is a reply to message #352673]
|
Tue, 13 March 2018 01:06 
|
|
Flugente |
 |
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Does any modder actually use the AddEmail... functions in lua? I've had a look at them, and... they are not pretty to look at. We have functions that will crash your game, no matter what arguments you enter.
I'm not even going to state how the functions work now (cleaning this up will take a bit), just.. does anybody actually use this?
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #352686 is a reply to message #352682]
|
Tue, 13 March 2018 21:53 
|
|
Flugente |
 |
Messages:3507
Registered:April 2009 Location: Germany |
|
|
You have activated my trap card! As the trade menu has been updated, the pink colour is a placeholder indicating that \Data\Laptop\shopkeeperbackground.pcx cannot be opened. It's pink in order to maximise your annoyance so that you fix that. So either the image is not there, or it can't be opened (you didn't install the game in a location your shouldn't, did you?).
Similar, the game now scans for additional battlesound files. I have no idea why it finds them and then decides it cannot open them - it seems like some issue about file permissions, perhaps?
[Updated on: Tue, 13 March 2018 21:54]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #353054 is a reply to message #352734]
|
Wed, 11 April 2018 08:05 
|
|
RunAwayScientist |
  |
Messages:84
Registered:September 2001 |
|
|
DEV BUILD - 8551
Hello everyone & Flugente,
I've tracked down the issue with mobile militia entering loaded sectors and will be submitting this to the BugFixes thread in addition to here. It took about 30 minutes of working through the MoveIndividualMilitia functions but it appears to be a missing MoveIndividualMilitiaProfiles(); func call in a if/elseif/else chain, that's all.
Corrected code below:
[[ Strategic Movement.cpp ]] { BUGGED CODE } :
Toggle Spoiler
// Flugente: if a militia group has reached its final destination, add them to the current sector
if ( pGroup && pGroup->usGroupTeam == MILITIA_TEAM )
{
// if they arrive in the sector we have currently loaded, let them join from the edge
// this will always remove them from the group - if you want them to continue moving, issue a new order
if ( pGroup->ubSectorX == gWorldSectorX && pGroup->ubSectorY == gWorldSectorY && pGroup->ubSectorZ == gbWorldSectorZ )
{
MilitiaGroupEntersCurrentSector( pGroup->ubGroupID, pGroup->ubSectorX, pGroup->ubSectorY );
if ( !fBattlePending && GroupAtFinalDestination( pGroup ) )
{
// once militia have arrived, move them from the group to the sector
DissolveMilitiaGroup( pGroup->ubGroupID );
}
}
[[ Strategic Movement.cpp ]] { CORRECTED CODE } :
Toggle Spoiler
// Flugente: if a militia group has reached its final destination, add them to the current sector
if ( pGroup && pGroup->usGroupTeam == MILITIA_TEAM )
{
// if they arrive in the sector we have currently loaded, let them join from the edge
// this will always remove them from the group - if you want them to continue moving, issue a new order
// RunAwayScientist fix on 4/10/2018: The below condition needs to have the other functions applied (MoveMilitiaEquipment, MoveMilitiaProfiles, reset)
// because the other if-else sections do NOT trigger if milita move into currently loaded sector.
// This should be done before dissolving the group.
// Currently only MoveMilitiaProfiles is needed, equipment is moved without being called from another func.
if ( pGroup->ubSectorX == gWorldSectorX && pGroup->ubSectorY == gWorldSectorY && pGroup->ubSectorZ == gbWorldSectorZ )
{
ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"CONDITION CHECKING LOADED SECTOR ACTIVATED" );
MilitiaGroupEntersCurrentSector( pGroup->ubGroupID, pGroup->ubSectorX, pGroup->ubSectorY );
// Flugente: move along individual militia data
MoveIndividualMilitiaProfiles( SECTOR( pGroup->ubPrevX, pGroup->ubPrevY ), SECTOR( pGroup->ubSectorX, pGroup->ubSectorY ), pGroup->pEnemyGroup->ubNumAdmins, pGroup->pEnemyGroup->ubNumTroops, pGroup->pEnemyGroup->ubNumElites );
if ( !fBattlePending && GroupAtFinalDestination( pGroup ) )
{
// once militia have arrived, move them from the group to the sector
DissolveMilitiaGroup( pGroup->ubGroupID );
// for safety, reset if necessary
ResetMilitia( );
}
}
(( This is optional, but I commented out the redunant 'Catch-All' feature that creates new militia profiles if none are detected in the sector. This caused more problems than it solved, and most people start new games or have updated their old game already. I highly recommend disabling the redunant 'Catch-All'.
There's a second 'Catch-All' in the FOR loop, which has only a 'return;', which may cause problems if it's ever triggered. That has also been commented out. ))
[[ Militia Individual.cpp ]] { BUGGED CODE } :
Toggle Spoiler
// search for a individual militia that is alive and not currently in use in this sector, and return its id
// if none is found, create new and return that one
UINT32 GetIdOfUnusedIndividualMilitia( UINT8 aSoldierClass, UINT8 aSector )
{
if ( !gGameExternalOptions.fIndividualMilitia )
return 0;
UINT8 militialevel = SoldierClassToMilitiaRank( aSoldierClass );
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end();
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSector && (*it).militiarank == militialevel )
{
// fitting data found - now we have to make sure this one isn't already in use
BOOLEAN found = FALSE;
SOLDIERTYPE* pSoldier;
INT32 cnt = gTacticalStatus.Team[MILITIA_TEAM].bFirstID;
INT32 lastid = gTacticalStatus.Team[MILITIA_TEAM].bLastID;
for (pSoldier = MercPtrs[cnt]; cnt < lastid; ++cnt, ++pSoldier)
{
if (pSoldier && pSoldier->bActive && (*it).id == pSoldier->usIndividualMilitiaID && IsLegalMilitiaId(pSoldier->usIndividualMilitiaID) )
{
found = TRUE;
break;
}
}
if ( !found && IndividualMilitiaInUse_AutoResolve((*it).id))
{
found = TRUE;
}
if (!found)
{
return (*it).id;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
// if ( gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in GetIdOfUnusedindividualMilitia" );
// nobody found. That shouldn't really happen, as we are supposed to create data whenever new militia is created. Create new data and use that
return CreateNewIndividualMilitia( militialevel, MO_ARULCO, aSector );
}
--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^
void MoveIndividualMilitiaProfiles( UINT8 aSourceSector, UINT8 aTargetSector, UINT8 usGreens, UINT8 usRegulars, UINT8 usElites )
{
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end( );
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
if ( !usGreens && !usRegulars && !usElites )
return;
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSourceSector )
{
if ( usGreens && ( *it ).militiarank == GREEN_MILITIA)
{
(*it).sector = aTargetSector;
--usGreens;
}
else if ( usRegulars && (*it).militiarank == REGULAR_MILITIA)
{
(*it).sector = aTargetSector;
--usRegulars;
}
else if ( usElites && (*it).militiarank == ELITE_MILITIA)
{
(*it).sector = aTargetSector;
--usElites;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
if ( (usGreens + usRegulars + usElites) && gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in MoveIndividualMilitiaProfiles" );
}
}
[[ Militia Individual.cpp ]] { CORRECTED CODE } :
Toggle Spoiler
// search for a individual militia that is alive and not currently in use in this sector, and return its id
// if none is found, create new and return that one
UINT32 GetIdOfUnusedIndividualMilitia( UINT8 aSoldierClass, UINT8 aSector )
{
if ( !gGameExternalOptions.fIndividualMilitia )
return 0;
UINT8 militialevel = SoldierClassToMilitiaRank( aSoldierClass );
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end();
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSector && (*it).militiarank == militialevel )
{
// fitting data found - now we have to make sure this one isn't already in use
BOOLEAN found = FALSE;
SOLDIERTYPE* pSoldier;
INT32 cnt = gTacticalStatus.Team[MILITIA_TEAM].bFirstID;
INT32 lastid = gTacticalStatus.Team[MILITIA_TEAM].bLastID;
for (pSoldier = MercPtrs[cnt]; cnt < lastid; ++cnt, ++pSoldier)
{
if (pSoldier && pSoldier->bActive && (*it).id == pSoldier->usIndividualMilitiaID && IsLegalMilitiaId(pSoldier->usIndividualMilitiaID) )
{
found = TRUE;
break;
}
}
if ( !found && IndividualMilitiaInUse_AutoResolve((*it).id))
{
found = TRUE;
}
if (!found)
{
return (*it).id;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
// if ( gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in GetIdOfUnusedindividualMilitia" );
// RunAwayScientist fix on 4/11/2018 - Creating new profiles when there's a bug duplicates orphaned militia that cannot be disbanded. We either need a clean-up method or the player can just move his militia back to the sector where they were orphaned to fix.
// nobody found. That shouldn't really happen, as we are supposed to create data whenever new militia is created. Create new data and use that
// return CreateNewIndividualMilitia( militialevel, MO_ARULCO, aSector );
}
--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^--^
void MoveIndividualMilitiaProfiles( UINT8 aSourceSector, UINT8 aTargetSector, UINT8 usGreens, UINT8 usRegulars, UINT8 usElites )
{
std::vector<MILITIA>::iterator itend = gIndividualMilitiaVector.end( );
for ( std::vector<MILITIA>::iterator it = gIndividualMilitiaVector.begin( ); it != itend; ++it )
{
// RunAwayScientist on 4/11/2018 - Redundant, the FOR loop should already catch end of vector. This may also cause a premature termination of the loop if 0's are fed to this function.
// if ( !usGreens && !usRegulars && !usElites )
// return;
if ( !((*it).flagmask & (MILITIAFLAG_DEAD | MILITIAFLAG_FIRED | MILITIAFLAG_DESERTION )) && (*it).sector == aSourceSector )
{
if ( usGreens && ( *it ).militiarank == GREEN_MILITIA)
{
(*it).sector = aTargetSector;
--usGreens;
}
else if ( usRegulars && (*it).militiarank == REGULAR_MILITIA)
{
(*it).sector = aTargetSector;
--usRegulars;
}
else if ( usElites && (*it).militiarank == ELITE_MILITIA)
{
(*it).sector = aTargetSector;
--usElites;
}
}
}
// if this feature is on and we get to this point, then there aren't enough individual militia. This is odd, the player should be informed
if ( (usGreens + usRegulars + usElites) && gGameExternalOptions.fIndividualMilitia )
ScreenMsg( FONT_MCOLOR_RED, MSG_INTERFACE, L"Possible error: Not enough individual militia found in MoveIndividualMilitiaProfiles" );
}
Thank you Flug or whoever who corrected the scope issues relating to recruiting militia. This combined with the above bug fixes should effectively fix 90% of mobile milita issues.
Disbanding militia seems to work just fine. So far.
There's some optional changes I'd like to recommend as well, such as disabling the 'Milita could not find gun to use, uses harsh language instead!' chat spam that happens whenever unarmed militia are moving around the map. This occurs in every sector movement, resulting in 180 messages for a stack of 60 unarmed militia over three sectors (for example).
[[ Militia Individual.cpp ]] { ORIGINAL CODE } :
Toggle Spoiler
ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
}
// we didn't find any gun at all. Now what?
else
{
si[SI_GUN].done = TRUE;
ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
[[ Militia Individual.cpp ]] { CHANGED CODE } :
Toggle Spoiler
// RunAwayScientist on 4/11/2018 - Disabled no gun messages.
// ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
}
// we didn't find any gun at all. Now what?
else
{
si[SI_GUN].done = TRUE;
// ScreenMsg( FONT_MCOLOR_LTYELLOW, MSG_INTERFACE, L"Militia found no gun to equip, uses harsh langugage instead!" );
}
One more problem remains: There is one more bug to fix and it's related to militia in a group traveling into the same sector in which mercs arrived and the sector is occupied by enemies. If this occurs, the militia DO NOT equip any inventory they had with them and will be unarmed for combat when they arrive at the sector edge. I assume this is also a very easy fix, anyone who knows what function call or method directly affects this please check it out or submit to trunk. I'd love you long time.
Original message in Flugente's subforum: http://thepit.ja-galaxy-forum.com/index.php?t=msg&th=23044&goto=353051&#msg_353051
.
Report message to a moderator
|
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #353091 is a reply to message #353073]
|
Thu, 12 April 2018 21:04 
|
|
Flugente |
 |
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Eh? Of course Vicki freaks out, she is afraid of heights. Even her bio states so, so that shouldn't come as a surprise. Sirtech simply didn't add the code that causes that behviour, so I did. This is not a bug.
Yeah, that occasionally happens because the AI wanders into that room.
A similar thing happened in the brothel, where occasionally some NPC wandered around the brothel. As the game definition of whore is 'any woman with a miniskirt' (don't tell that to today's internet!), they'd try to have sex with whoever walks in. Men. Women. Children. Cows. Tanks. They hesitate at nothing (which caused a crash, as with NPCs, Sex wasn't properly initialized). That has been fixed, I'll fix the Kingpin issue eventually. When i have time.
[Updated on: Thu, 12 April 2018 21:04]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #353096 is a reply to message #353091]
|
Thu, 12 April 2018 22:03 
|
|
Jolly_Reaper |
  |
Messages:47
Registered:August 2002 Location: The Netherlands |
|
|
Flugente wrote on Thu, 12 April 2018 20:04Eh? Of course Vicki freaks out, she is afraid of heights. Even her bio states so, so that shouldn't come as a surprise. Sirtech simply didn't add the code that causes that behviour, so I did. This is not a bug.
No man, you got it all wrong. Regarding her bio, they tease her because she's afraid to use the elevator. Elevators are not places where people with claustrophobia like to go.
She even says so: "CRAWLSPACES freak me out, mon! I hate it IN HERE." Crawlspace=low ceiling basement. And you can't be IN a roof.
This makes absolutely no sense to say when on a rooftop.
Also: Vicki insists on using the stairs no matter how tall the building.
If she was afraid of heights she wouldn't even use the stairs, she'd stay at ground level.
This should be corrected! I want my Vicki back.
Edit: Fixed it in my game, easy enough thankfully. Kudos for this mod's open configuration!
[Updated on: Thu, 12 April 2018 22:12] Report message to a moderator
|
Corporal
|
|
|
|
Re: Bugs: Unofficial releases (SCI's), unstable and DEV builds[message #353105 is a reply to message #353104]
|
Fri, 13 April 2018 02:28 
|
|
Jolly_Reaper |
  |
Messages:47
Registered:August 2002 Location: The Netherlands |
|
|
Flugente wrote on Fri, 13 April 2018 00:54Hmm. That does make a certain amount of sense with her voiceline, but not with her bio. I always read that as her being afraid of climbing rooftops and thus being afraid of heights. Considering that claustrophobia only kicks in in underground sectors, one would think that there were better ways to phrase that.
Fixed in GameDir r2419.
Do you have her German bio by any chance? Maybe it was translated incorrectly?
"Despite constant teasing, Vicki insists on using the stairs no matter how tall the building."
There's no relation to claustrophobia when someone is taking the stairs, but there is one when entering elevators. A big one.
Acrophobia (fear of heights), some people have such a bad case of it that they don't even dare to take the stairs. But Vicki prefers stairs over the elevator, since elevators are a claustrophobic nightmare.
The elevator isn't mentioned in this bio, but it is automatically assumed that this is the thing she's afraid of, ask any native English speaker if you don't believe me. 
Anyway, it did make me wonder if you/any of the other creators made any other alterations to mercs that shouldn't have happened.
Shadow, for example, doesn't gain morale anymore when in a group. Yes, he's a loner, but I don't see why this needed to change from vanilla.
His portrait, I always pictured Shadow to be someone who'd ALWAYS be in camouflage, even on the phone. It's just who he is, skulking around 24/7, he doesn't want to be found, he finds you. (Thankfully it was easy to replace his portrait.) I feel that if modders change these colourful mercs so they fit inside their own view they are in danger of destroying what the original developers envisioned.
Ehm, I didn't want to start a discussion in this bug thread, so let me just say: I hope this'll be kept in mind for future versions and I'll get more ontopic by posting another weird thing I noticed:
After a fight and if you have Ira/Dimitri/Miguel with you (possibly Carlos as well, but I can't stand the guy) they tend to repeat with subtitling whatever a merc said upon victory.
Say, Fox says: "Yeah, we did 'em all! I love that." Ira/Dimitri/Miguel would then repeat this. It's like they want to share some wisdom about the sector they're in, can't find the line they're supposed to say and just repeat the last thing that was said.
Ira/Dimitri/Miguel do tell their little story whenever they're in an applicable sector, so that's not broken.
Report message to a moderator
|
Corporal
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Feb 15 18:01:35 GMT+2 2025
Total time taken to generate the page: 0.02410 seconds
|