Moderated by myfist0, Seleuceia and GoaFan77.
Post your errors here and let's see if we can't get them resolved.Every error has an error number which will link to the web pages bookmark (anchor) and will be listed in order. Mouse-over the error number to confirm it matches your error.
If the error is not listed, please post it here.
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Window/Screens/MainMenuScreen.cpp(18) false
A game update changed the main menu, the older file in the mod is probably missing a section that was added. These are hard coded and are required.
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Galaxy/GalaxyOrientation.cpp(23) Vector3::IsNormalized(m_orientation.GetCross())
Explosions on a bad model.
The error is caused by lines in the model that were not polys, the explosion attaches to one of the lines it spits the error. And when a lot of models have it, trying to run test games is a real nightmare.
Have to raycast select all the polys and hide them, get a section done like above and delete the lines, unhide and weld everything where the lines were to get proper tangent lighting.
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IAntiMatterPool.cpp(107) antiMatterAmount >= 0.0f
This occurs when a capital ship (and possibly titan?) has used up some antimatter, levels up, but does not get an AM reserve stat boost from leveling up. Fix this by giving the capital ship an AM reserve stat boost for all levels (value as small as 0.000100 will suffice).
Assert @ c:\projects\Perforce\SinsDiplomacy\main\CodeSource\Engine/DataStructures/DynamicArray.h(128) i < size
One example of getting this error would be to set "totalMaxResourceAsteroids 5" and then having the min counts for metal at 3 and crystal at 3. There are other areas that also have modifiers like this that will give same error.
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IWeapon.cpp(140) m_weaponEffectsDef.weaponType == m_WeaponType
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IWeapon.cpp(144) m_TravelSpeed <= 0.f
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IAttacker.cpp(163) m_owner->GetIPlayerOwnedPtr()->GetPlayer()->GetIPlayerPtr()->IsEnemy(target)
Happens when our Borg ships assimilate an enemy ship that is casting an ability, does not cause any bad side effects that are known yet. Same as E212 but maybe a different abitity type.
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Player/PlayerOrbitBodyInfo.cpp(187) squad != 0
IIRC...This occurs when a unit, such as a carrier, is given the minelayer roletype but not any squadrons that can turn into mines. Error will only occur when AIs are involved.
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IChangeMesh.h(195) false
My guess is there's something wrong with an entity file that changes its mesh after research or an upgrade.
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IAttacker.cpp(212) m_owner->GetIPlayerOwnedPtr()->GetPlayer()->GetIPlayerPtr()->IsEnemy(target)
Happens when our Borg ships assimilate an enemy ship that is casting an ability, does not cause any bad side effects that are known yet. Same as E163 but maybe a different abitity type.
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IBuff.cpp(679) params.lastSpawner != NULL
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Render/MoveToRenderer.cpp(711) info.m_firstControllableEntity != 0 && info.m_firstControllableEntity->GetIOrderPtr() != 0
See Also:
Annotated Guide to the Developer.exe by GoaFan77
Just so they come up in the forum search, I will post what I started here.myfist0
E18Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Window/Screens/MainMenuScreen.cpp(18)false
E23Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Galaxy/GalaxyOrientation.cpp(23)Vector3::IsNormalized(m_orientation.GetCross())
E128Assert @ c:\projects\Perforce\SinsDiplomacy\main\CodeSource\Engine/DataStructures/DynamicArray.h(128)i < size
E140Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IWeapon.cpp(140)m_weaponEffectsDef.weaponType == m_WeaponType
E144Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IWeapon.cpp(144)m_TravelSpeed <= 0.f
E163Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IAttacker.cpp(163)m_owner->GetIPlayerOwnedPtr()->GetPlayer()->GetIPlayerPtr()->IsEnemy(target)
E195Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IChangeMesh.h(195)false
E212Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IAttacker.cpp(212)m_owner->GetIPlayerOwnedPtr()->GetPlayer()->GetIPlayerPtr()->IsEnemy(target)
E679Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IBuff.cpp(679)params.lastSpawner != NULL
E711Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Render/MoveToRenderer.cpp(711)info.m_firstControllableEntity != 0 && info.m_firstControllableEntity->GetIOrderPtr() != 0
Great idea and should help the devs a lot. I suggest this needs to be stickied though or it won't work so well. You also need to try and describe when the error happened and the steps needed to make it re-occur (if not intermittent). An error that is repeatable is the easiest to correct.
MyFist0, are you going to make links in the OP for all the errors you have or only those 3 you have solutions/explanations for?
Anyway here's two, I'll make them pretty latter:
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IAntiMatterPool.cpp(107)antiMatterAmount >= 0.0f
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Player/PlayerOrbitBodyInfo.cpp(187)squad != 0
All of them, I just got sidetracked. Trying to add users to x90x was a pain, it actually changed my admin logon address and root folder, took almost 2hrs to figure out how to login as admin. I was getting pissed and needed a break when I finally got in. I think it was because I got in when x90x was new and had a lot more features, messing with the account made me have to go new route.
List of stickies is already pretty long. If GoaFan puts a link to here from the dev guide, or people search the modding forum and the title DEV Errors comes up, should be pretty good.
updated by myfist0
stared a table wit 10 columns, see how that works for a while.
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\Engine/Render/Mesh/Mesh.cpp(608)pPipelineEffect != g_PipelineEffectSystem.GetPipelineEffectPtr(PipelineEffectID::GS_SHIP) || m_SelfIlluminationTexturePtrs.At(attributeID) != NULL
missing, or not connected texture
Material DiffuseTextureFileName "" SelfIlluminationTextureFileName "" NormalTextureFileName ""
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\Engine/Math/MathLibrary.h(480)Math::IsBetweenInclusive( x, -1.0f, 1.0f )
WTF
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\Engine/DataStructures/DynamicArray.h(128)
Lol....
Not sure but could be related to something in the gameplay constants file? I've gotten math errors before when messing with some of the marketDef things (the black market numbers), things being out of range or what not...
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\Engine/Math/MathLibrary.h(624)
! IsNear( ( time0 - time1 ), 0.0f, 0.0001f )
Here's another one...pretty sure it's a base game issue (not a mod), occurs in dev.exe sometimes when you use map designer and try to zoom in on a star far away...I get it frequently when I simply zoom in on the first star I see as soon as the map is loaded...
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/AI/BuildResearchAI.cpp(917)
ability->GetIAbilityPtr()->GetDef()->m_buffApplyAction.buffInstantActionType == BuffInstantActionType::CreateSpaceMine
No idea what this is at all...sometimes causes MD....it is cropping up in a variety of mods that previously game no error messages and have not been changed to my knowledge..
EDIT: This error has also come up while switching from a mod to VANILLA sins...it often comes up several times right in a row, but necessarily the same number of times, anywhere from 1 to ~11...the number of times it comes up does not seem to be related to whether an MD occurs or not...
Here's a rather infamous one...
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\Engine/File/FileSystem.cpp(308)
bResult == TRUE
May be a problem with the dev.exe, because I've had it come up with many mods I've used (some mine, some made by others) and sometimes when the game loads even in vanilla....
Might as well throw this in there:
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/EntitySystemHelpers.cpp(512)
researchRef != 0
Occurs when something (such as a structure) references a non-existent technology...
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IResearchSubject.cpp(675)
m_CurrentLevel <= GetDefinition().m_MaxNumResearchLevels
Occurs when you are in the process of researching a technology you already have...as far as I know, this only occurs when you grant all technology to a player (through the dev.exe) while that player was researching a technology...
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Render/Particle/ParticleAffector_RotateAboutAxis.cpp(90)
Math::IsFinite(particle->m_LinearAcceleration.GetLengthSquared())
Not sure what this is...occurred when 34 VL titans were fighting each other, no mods...
PF is different in REb so I think it's another case of not updating the DEV exe to account for the new code.
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IMove.cpp(1395)
findResult == PathFindResult::Success
Another found while just running the game...again, no idea what it is....
Yup, I think soon the Dev exe will be to useless to use anymore . What's the point if so many stock errors pop up that it makes testing impracticable.
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Galaxy/BuffSystem.cpp(76)
buffContainersWithAddedBuffs.Size() == 0
I have no idea what this is either...could be related to a mod but at it's current state, only one ability has been modded (planetary shield thing) and I really doubt it is the problem....didn't cause MD...reloading from most recent autosave did not cause the error to come up again....
C:\Projects\P4\SinsRebellion\main\CodeSource\GS\Player\PlayerResearch.cpp(449): assert! [level >= 0 && level < table->Size()]
C:\Projects\P4\SinsRebellion\main\CodeSource\GS\Player\PlayerResearch.cpp(472): assert! [level >= 0 && level < table->Size()]
Adding these to the list of unknowns (from recently necroed thread)....they probably will be solved though, I'm guessing it has to do with some number errors with the crew technologies....
Both error 449 and error 472 crop off if there is an unacceptable value for the research modifier CapitalShipMaxSlotLevel
AFAIK, putting a 1.000000 will always be fine...anything else probably should be avoided...
Assert @ C:\Projects\P4\SinsDiplomacy\Release\CodeSource\GS/Entity/Interfaces/IBuff.cpp(679)params.lastSpawner != NULL
Crud, sorry, already there
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Entity/Interfaces/IPlanet.cpp(1378)
newPlayerOwnerIndex != oldPlayerOwnerIndex
Seems to occur when a cannonshell hits a planet that has changed to an "inappropriate" owner. For example, if the cannon's ability's target filter only allowed you to target "enemy" planets and the planet switched to "friendly" during the cannonshell's transit, you would get this error as the cannon shell hit.
Assert @ C:\Projects\P4\SinsRebellion\main\CodeSource\GS/Galaxy/GalaxyOrientation.cpp(16)
Vector3::IsNormalized(m_orientation.GetCross())
This came up when I fired a novalith at a wormhole (I assume any planet with a null mesh would give the same error)...adding constraint "HasPopulation" to the cannon firing ability's constraints probably would prevent this from ever coming up....
I ended up with a phantom "could not load .mesh" error at one point. I was a little confused, as generally mesh errors come with a name and not a empty .mesh extension, and are typically a result of a typo (and one I can easily identify with an actual mesh name). However, it was actually a result of loading a savegame after changing module data to not have any research-dependent meshes. Although the module itself worked fine normally, apparently the save data was still asking for some kind of mesh research interaction that didn't exist.
So, if you ever use savegames to test like I do, changes like that can apparently do that.
Abilities also can be bad violators of that...changing the number of instant or periodic actions (and I assume overtime) can wreck havoc...
In general, I go by the rule that when you add or subtract anything, you shouldn't use a save...if you are just tweaking a number, icon, or string though you should be okay...
There are many great features available to you once you register, including:
Sign in or Create Account
