|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #328581]
|
Tue, 26 November 2013 16:42
|
|
Taro_M |
|
Messages:292
Registered:November 2008 |
|
|
Quote:
r6652 should fix this problem.
It did, the attachments work on WF weapons correctly.
I found a strange bug: when I fired buckshot shell at the enemy the game just froze. I think that some taunt tried to fire up, but failed. The game froze both when I missed him and when I hit him, caused 2 critical wounds and made him fall down.
BTW: Those the eyeball/scope-with-no-number icon mean hipfire when choosing fire modes?
[Updated on: Tue, 26 November 2013 16:49] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
Re: BUGZILLA report all bugs here![message #328585]
|
Tue, 26 November 2013 17:17
|
|
Deleted. |
|
Messages:2657
Registered:December 2012 Location: Russian Federation |
|
|
RoWa21
Last patch was added in wrong place.
New lines
Toggle Spoiler // sevenfm: added flag WORLD_ITEM_ARMED_BOMB
// this fixes bug with remote explosives not being removed after activation, if they were armed in inventory and thrown afterwards
gWorldItems[ iItemIndex ].usFlags |= WORLD_ITEM_ARMED_BOMB; should be inserted after
Toggle Spoiler // Add a bomb reference if needed
// Flugente: we can arm bombs in our inventory and then throw them out, which will cause them to be added to the world. Only way to identify those items is via a check for their bDetonatorType
if (usFlags & WORLD_ITEM_ARMED_BOMB || ( (Item[pObject->usItem].usItemClass & (IC_BOMB)) && ( ( (*pObject)[0]->data.misc.bDetonatorType == BOMB_TIMED ) || ( (*pObject)[0]->data.misc.bDetonatorType == BOMB_REMOTE ) ) ) )
{
so the function should look like
Toggle Spoiler// Add a bomb reference if needed
// Flugente: we can arm bombs in our inventory and then throw them out, which will cause them to be added to the world. Only way to identify those items is via a check for their bDetonatorType
if (usFlags & WORLD_ITEM_ARMED_BOMB || ( (Item[pObject->usItem].usItemClass & (IC_BOMB)) && ( ( (*pObject)[0]->data.misc.bDetonatorType == BOMB_TIMED ) || ( (*pObject)[0]->data.misc.bDetonatorType == BOMB_REMOTE ) ) ) )
{
// sevenfm: added flag WORLD_ITEM_ARMED_BOMB
// this fixes bug with remote explosives not being removed after activation, if they were armed in inventory and thrown afterwards
gWorldItems[ iItemIndex ].usFlags |= WORLD_ITEM_ARMED_BOMB;
iReturn = AddBombToWorld( iItemIndex );
if (iReturn == -1)
{
return( -1 );
}
else
Please fix it.
fixed world items patch r6654
[Updated on: Tue, 26 November 2013 17:23] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #328603]
|
Wed, 27 November 2013 01:52
|
|
Strohmann |
|
Messages:287
Registered:August 2011 Location: Division Thought Crimes |
|
|
KriploDoubt this is mapeditor problem, something is very wrong with those random items, whatever I try get results you described [.]
Testing with the latest release of my mod (where i know random items were working) and then upwards revisionwise:
- exe 6520 on gamedir 1842: itemclass misc/save in vanilla format -> random item spawns listed items properly
- exe 6520 on gamedir 1842: itemclass random item/save in vanilla format -> random item spawns listed items properly
- exe 6520 on gamedir 1842: itemclass misc/don't save in in vanilla format -> random item spawns nothing
- exe 6534: itemclass misc/save in vanilla format -> random item doesn't even appear on the map
- exe 6534: itemclass misc/don't save in vanilla format -> random item spawns nothing
- exe 6534: itemclass random item/save in vanilla format -> random item doesn't even appear on the map
- exe 6534: itemclass random item/don't save in vanilla format -> random item spawns nothing
Changelog:
Toggle Spoiler [...]
r6530 | Kriplo | 2013-10-25 20:48:37 +0200 (Fr, 25 Okt 2013) | 17 lines
Brief: //dnl ch74
- Couple map editor fixes.
Details:
- Map loading not properly set Vanilla global variable switch.
- Loading AIMNAS maps of version 28 cause CTD due to incorrect StackedObjectData loading sizeof.
- Only in editor mode and if NAS setting is on inseparable and default attachments will be always add, but default attachments will not, so older maps should be converted from mapeditor to new version.
- Fix CTD if try to place items from tab selection which contains no items.
- There was missing part from ch4 for mouse wheel support in mapeditor.
- There was conflict between keyboard and mouse events creating problems when try to select taskbar options by mouse.
- Fix annoying message of using improper attachment during item place if item consist of default or inseparable attachments.
- Remove hints to display if loading map from editor.
- Fix CTD if have previously selected merc and loading another (smaller) map.
- Saving map as Vanilla will check if attachment is valid for 1.12, that means you will lost some stuff from NIV if save in Vanilla mode, so you should always save map in newest format if want play map in 1.13.
- Add correct weight recalculation when saving in Vanilla format using old OBJECTTYPE.
- Remove entry points check during map save as Scheinworld reported problem with basement levels and similar maps which doesn't need entry points.
- Fix displaying wrong map version in summary window because MapInfo is incorrectly saved in all previous mapeditors.
[...]
Too lazy to do more tests this late.
--
Edit: Ok, one last test^^, with exe 6567, the closest exe to the next change regarding maps (6554):
The problems are persisting, unchecking save in vanilla formats leads to no items appearing on the map at all and doing so leads to plain random items, not spawning the items on their lists.
Changelog:Toggle Spoiler[...]
r6554 | Kriplo | 2013-11-03 17:26:30 +0100 (So, 03 Nov 2013) | 12 lines
Brief: //dnl ch75
- More map editor fixes and map inventory pool performance improvement for big maps.
Details:
- Fix not showing expected messagebox on exit (ALT+x) which also throw exception and goes to improper mapeditor exit.
- Fix second annoying sticky message which shouldn't popup during map loading and performing RemoveProhibitedAttachments.
- Fix CTD when delete all enemies or civilians or all of them in map.
- Fix some std exception when reporting for missing optional xml file.
- Fix memory and map corruption in old mapeditors if loaded old map has item with invalid attachment and we try to attach something else.
- As years ago pInventoryPoolList had migrated from WORLDITEM* array to std::vector it was time to do that with gWorldItems too, all necessary functions which need to be adopted to gWorldItems std::vector type are also changed.
- Resize code for gWorldItems is changed hoping will lead into less corruption problems as now could occur in mapeditor and game when code automatically doing attachment changes.
- Change code for handling map inventory which now should be fast enough to support AIMNAS project which will probably deal with thousands of items per map.
[...]
[Updated on: Wed, 27 November 2013 02:39] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
Re: BUGZILLA report all bugs here![message #328614]
|
Wed, 27 November 2013 13:38
|
|
Deleted. |
|
Messages:2657
Registered:December 2012 Location: Russian Federation |
|
|
Taroexe: 6655
gamedir:1882
Game freezes with automatic flagging on and off. What is weird is that character dosent say thing about trap when standing or walking next to that trap. The game freezes only when you try to walk on top of the trapped square.
Please try using this r6655 exe with latest fixes
I tested it with stock 1.13 and WF6.07, and was able to complete san mona angel's quest without any problems.
Toggle SpoilerIn WF6.07 there were 4 traps behind the door, Barry was able to find them only with metal detector
Report message to a moderator
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #328628]
|
Wed, 27 November 2013 15:45
|
|
wanne (aka RoWa21) |
|
Messages:1961
Registered:October 2005 Location: Austria |
|
|
@Kriplo:
We have no "Data\TableData\SpreadPatterns.xml" file for the Vanilla ("Data") folder. This is OK.
If the file cannot be found, the default spread pattern values are taken from the source code.
There is a comment in line 203 (Init.cpp)
//zilpin: pellet spread patterns externalized in XML
//If file not found, or error, then the old hard-coded defaults are used by LOS.cpp
//This needs to be loaded before AmmoTypes and Items because SpreadPatterns can be referenced by name or index.
strcpy(fileName, directoryName);
strcat(fileName, SPREADPATTERNSFILENAME);
DebugMsg (TOPIC_JA2,DBG_LEVEL_3,String("LoadExternalGameplayData, fileName = %s", fileName));
ReadInSpreadPatterns(fileName);
[Updated on: Wed, 27 November 2013 15:46] by Moderator Report message to a moderator
|
|
|
|
Re: BUGZILLA report all bugs here![message #328630]
|
Wed, 27 November 2013 15:57
|
|
Kriplo |
|
Messages:256
Registered:February 2008 Location: Zagreb - Croatia |
|
|
@RoWa21
Ok, but then we need to put FileExist condition in ReadInSpreadPatterns function or better before calling ReadInSpreadPatterns to avoid VFS throwing unnecessary std exception.
[Updated on: Wed, 27 November 2013 16:15] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #328699]
|
Fri, 29 November 2013 20:09
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
SevenfmTwo issues regarding suppression calculation:
1) overhead.cpp CalcSuppressionTolerance()
bTolerance += pSoldier->GetSuppressionResistanceBonus(); is calculated after applying minimum and maximum suppresion tolerance values
bTolerance = __max(bTolerance, gGameExternalOptions.ubSuppressionToleranceMin);
bTolerance = __min(bTolerance, gGameExternalOptions.ubSuppressionToleranceMax);
This could lead to incorrect suppression tolerance values.
Changed this to
// Flugente: add personal bonus to suppresion tolerance
bTolerance += pSoldier->GetSuppressionResistanceBonus();
bTolerance = __max(bTolerance, gGameExternalOptions.ubSuppressionToleranceMin);
bTolerance = __min(bTolerance, gGameExternalOptions.ubSuppressionToleranceMax); overhead.cpp patch r6663
2) values in backgrounds.xml are probably too excessive. Adding or deducting 10 or 20 from suppression tolerance (min 1, max 18) makes all other calculations rather meaningless.
So i suggest reducing this to appropriate values, as backgrounds are supposed to make very small changes to other systems.
I changed them to 1/5 of original values, so now Barry has -2 penalty to suppression tolerance instead of -10, because of his graduate background.
backgrounds.xml patch gamedir 1885
This change is subject to discussion. Maybe original values were supposed to be % penalties? 1. Committed in r6664
2. Yep, should have been percentage. As a few other background values are also way too high for my liking, I will fix this today.
Report message to a moderator
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #328703]
|
Fri, 29 November 2013 21:19
|
|
Deleted. |
|
Messages:2657
Registered:December 2012 Location: Russian Federation |
|
|
Another two points regarding suppression
1) There is a code block in HandleSuppressionFire function which is doubled for some reason.
// INI-Controlled intensity. SuppressionEffectiveness acts as a percentage applied to the number of lost APs.
// To turn off the entire Suppression system, simply set the INI value to 0. (0% AP Loss)
// The default is obviously 100%. You can increase or decrease it, at will.
// PLEASE NOTE that AP loss governs ALL OTHER SUPPRESSION EFFECTS.
ubPointsLost = ( ubPointsLost * sFinalSuppressionEffectiveness ) / 100;
// This is an upper cap for the number of APs we can lose per attack.
if (usLimitSuppressionAPsLostPerAttack > 0)
{
if (ubPointsLost > usLimitSuppressionAPsLostPerAttack)
{
// Flugente: eh.. wouldn't this _always_ be 255? I suspect this should be __min
//ubPointsLost = __max(255,(UINT8)usLimitSuppressionAPsLostPerAttack);
ubPointsLost = __min(255,(UINT8)usLimitSuppressionAPsLostPerAttack);
}
} As a result, ubPointsLost are twice multiplied by sFinalSuppressionEffectiveness. Probably some kind of mistake?
2) I also suggest moving code block with applying AP loss limits from one attack and whole turn to the point after shock and morale calculation, but before stance change.
Reason: in the original code, if we limit AP loss to some small values (10 points for examples), there will be nearly no shock from suppression.
With this change, we can have high shock and morale effects from suppression, but still have some ap's left to be able to change position.
overhead.cpp patch r6663
Report message to a moderator
|
|
|
|
|
|
|
|
|
|