29 replies to this topic

[troubadour]

I think a pcall encapsulation to TerrainAnalyzer:HasThreatOnPath() could do the trick because it would prevent in game crash. Of course you will not know which map is a problem but do you really need this piece of info if the game does not crash ?

If there is an error raised during pcal() then the old code is used, Moreover it will work fine wiht ALL the maps..

Well just my 2 cents , here is a piece of code with in bold lines i added, i have slightly edited cpuManager:HasThreatOnPath() to perform a 1st call to TerrainAnalyzer:HasThreatOnPath() if no error is raised then we return the result else we keep running the old code


function CpuManager:HasThreatOnPath(vPos1, vPos2, iRange)

dbAssert(vPos1 ~= nil)
dbAssert(vPos2 ~= nil)
dbAssert(iRange ~= nil)

-- Check if high speed AI setting is activated
if (CpuManager.AISettings.bHighSpeedAI == true) then
return false
end

function CheckThreat(pos1, pos2, range)
return cpu_manager.terrain_analyzer:HasThreatOnPath(pos1, pos2, range)
end

local noError, hasThreat = pcall(CheckThreat, vPos1, vPos2, iRange)
if noError then
return hasThreat
end

-- Calculate airline vector
local vAirline = Vector3f()
vAirline.x = vPos2.x - vPos1.x
vAirline.y = 0
vAirline.z = vPos2.z - vPos1.z

.......

end

Edited by troubadour, 08 April 2009 - 07:00 AM.

[ArkhanTheBlack]

@Troubadour
Well, good idea! However, I've already tried that a long time ago and unfortunately it doesn't work. It can't avoid a crash :-(. At that time I really had hight hopes in that possible solution too.

[troubadour]

Doh ! i had high hopes too, thx for your input Arkhan

[thudo]

I've been testing Larkin's mapdb code for 4+ days now. Absolutely ZERO issues on multiple maps in multiple scenarios. Right now, no need for the PCALL code as I have yet to experience a CTD.

I've been debating where to put the mapdb files to so I put them under profiles because its not used much. I would rather stay away from creating new dirs in the game's root folder as much as possible by diverting the map db files to a largely unused area of the game.

[LarkinVB]

I'd prefer logfiles more than profiles. Didn't we have a crash happy map/race combo once upon a time ? I'd like to encounter a crash.

[thudo]

I'd prefer logfiles also but I need to know what happens on a default install of SS if/when the logfiles folder gets created. If it gets created when user first runs the game then cool but if its created only when -dev is used then we have a prob. Gonna quickly check for this.

Update -- Woop! Its gonna be \logfiles.. just did a basic install of Soulstorm in a VM session and yep the \logfiles folder gets created on first install. We'll use \logfiles from now on for map db dumps.

[ArkhanTheBlack]

I'll try to get something together next week when I'm back from visiting my parents (~Tuesday).

[thudo]

Fantastic, A-man.. Gather there are now some new possibilities with this Larkin breakthrough -- I've have yet to have a crash with it enabled.

[LarkinVB]

I wonder if we could reactivate the distance function to check for valid teleport positions too, using the map crash info. Not sure if the two functions are somehow related...

This would be great. Jump to safety is rare since CompassMove() was disabled. Perhaps a db second flag should be added so crashes can be distinguished between HasThreatOnPath() and CompassMove(). This would force us to wrap both calls though, adding additional disk IO. I'm sure Arkhan can work something out.

Edited by LarkinVB, 10 April 2009 - 07:43 PM.

[LarkinVB]

Enabled CompassMove() and had an immediate crash in my first game. Seems no good idea trying to use it even with mapdb.