Closed nepomuk16321 closed 2 weeks ago
Here's an English-translated version of the recognition loop:
{for body in SystemDetails(system.systemname).bodies:
{body.shortname}
{set bodies to bodies + 1}
{if body.bodytype = "Moon" || body.bodytype = "Planet":
{if body.alreadydiscovered:
known, {set alreadydiscovered to alreadydiscovered + 1}
|elif !body.alreadydiscovered:
unknown,
{set nondiscovered to nondiscovered + 1}
}
}
{if body.bodytype = "Star":
{set stars to stars + 1}
{if body.alreadydiscovered = true :
{_ system known }
|else:
system is unknown
}
}
}
bodies = {bodies},
stars = {stars},
known objects = {if alreadydiscovered = 0 || !alreadydiscovered: 0: |else: {alreadydiscovered} }
unknown bodies = {if nondiscovered = 0 || !nondiscovered: 0: |else: {nondiscovered} }
Thanks T'Kael. Small correction or extension to recognise discovered main stars and thus systems.
{if body.bodytype = "star":
{set stars to stars + 1}
{if body.mainstar:
{if body.alreadydiscovered: system known,
|elif !body.alreadydiscovered: system unknown,}
}
}
But the problem remains. In the journal, the main star is listed as ‘WasDiscovered:false’
, but EDDI recognises it as ‘true’
!
Journal.2024-10-20T163755.01.txt
Look at the system: Pheia Ain GV-P b6-0 A
The system scan in the next system then brought the correct result again > main star ‘WasDiscovered:false’ and EDDI also says: ‘unknown system’! (Pheia Ain LB-0 b7-0 A
Journal.2024-10-20T163755.01.log
I'm not sure when or how it may have started but in short you seem to be having an issue with writing data to your SQLite database which is connected to a non-unique systemaddress
property.
2024-10-18T15:31:59 [Warning] StarSystemSqLiteRepository:handleSqlLiteException SQLite error: : {"message":"code = Constraint (19), message = System.Data.SQLite.SQLiteException (0x87AF202F): constraint failed\r\nUNIQUE constraint failed: starsystems.systemaddress\r\n bei System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt)\r\n bei System.Data.SQLite.SQLiteDataReader.NextResult()\r\n bei System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave)\r\n bei System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior)\r\n bei System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior)\r\n bei System.Data.SQLite.SQLiteCommand.ExecuteNonQuery()\r\n bei EddiDataProviderService.StarSystemSqLiteRepository.insertStarSystems(ImmutableList`1 systems) in EddiDataProviderService\\StarSystemSqLiteRepository.cs:Zeile 666."}
Please rename EDDI.sqlite
to EDDI.sqlite.old
and allow EDDI to re-create a new EDDI.sqlite?
If you can manage to reasonably compress your EDDI.sqlite and can share it then I'd like to be able to inspect it.
I have also noticed the SQL database error message in the eddi.log. I will try to create a new database. A few months ago, I carried out the repair suggestion from CMDR Darkcyde. I hope this does not cause the error. EDDI.sqlite.zip EDDI created a new SQL-Lite database without asking.
Yes, EDDI is designed to create EDDI.sqlite if if it does not currently exist. Do you know when the database errors started appearing in your logs?
Sorry, unfortunately NO. The last eddi.log file, eddi9.log, is from 17.10.2024 and the errors are already occurring there.
A few months ago, I carried out the repair suggestion from CMDR Darkcyde. I hope this does not cause the error.
I don't believe it would be the cause. I have used it several times myself on my own database, and I'm not seeing the same problems you are experiencing. However, if it is found to be the cause for whatever reason, I'll see about removing access to it, and then try to investigate what the problem could be.
I had or have no problems, at least I was able to use it without any problems. @Tkael probably just noticed it. Let's see what he has to say.
I have no evidence for or against the repair script. All I know for certain is that the systemAddress is a unique contraint in the database and @nepomuk16321 's logs indicate unique constraint violations for this property spanning multiple sessions. I'm not yet sure what could generate a consistently failing systemAddress constraint across many play sessions and star systems.
The most likely scenario is that something somewhere in the code is generating a systemAddress of 0
rather than the value it should have. 🤔
@nepomuk16321 The file you forwarded did have one system with a systemAddress of 0
(at system SYNUEFAI UC-R B51-1
). I'm guessing the file you forwarded was your new EDDI.sqlite rather than your old EDDI.sqlite. Is that correct? If yes, was it sent right after syncing your flight log from EDSM and before jumping to another system? Has the error messages recurred since you replaced your EDDI.sqlite file?
Hello @Tkael , no, the first SQLite file was the old file. I am attaching the newly created one here. It is also much smaller. EDDI-sqlite-aktuell.zip
Thank you. Have you been able to confirm whether new the sqlite file has resolved the problem?
There is still an error message indicating SQLite. However, I have no idea to what extent this error has to do with it. During my last jumps and scans I did not notice any recognition errors on the celestial bodies. However, it often happens that a second or third sun is only recognized after a second honk. But that is not dramatic. It only results in an incorrect number of celestial bodies still to be explored being announced (+- 1 or +-2 depending on the number of suns).
"Warning 1" 2024-10-27T19:53:17 [Warning] StarSystemSqLiteRepository:handleSqlLiteException SQLite error: : {"message":"code = Constraint (19), message = System.Data.SQLite.SQLiteException (0x87AF202F): constraint failed\r\nUNIQUE constraint failed: starsystems.systemaddress\r\n bei System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt)\r\n bei System.Data.SQLite.SQLiteDataReader.NextResult()\r\n bei System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave)\r\n bei System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior)\r\n bei System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior)\r\n bei System.Data.SQLite.SQLiteCommand.ExecuteNonQuery()\r\n bei EddiDataProviderService.StarSystemSqLiteRepository.insertStarSystems(ImmutableList`1 systems) in EddiDataProviderService\StarSystemSqLiteRepository.cs:Zeile 666."}
"Warning 2" 2024-10-27T20:34:33 [Warning] CompanionAppService:GetResponse Der Remoteserver hat einen Fehler zurückgegeben: (400) Ungültige Anforderung.: {"m_HttpResponseHeaders":["Connection","Access-Control-Allow-Credentials","Request-Tag","Content-Length","Content-Type","Date","Server"],"m_Uri":"https://companion.orerve.net/fleetcarrier","m_Certificate":null,"m_Version":{"Major":1,"Minor":1,"Build":-1,"Revision":-1,"MajorRevision":-1,"MinorRevision":-1},"m_StatusCode":400,"m_ContentLength":112,"m_Verb":"GET","m_StatusDescription":"Bad Request","m_MediaType":null}
Ok, in the last few days I have not been able to confirm any problem with recognizing the celestial bodies. I will continue to observe it. However, you can still read an error or a warning in the eddi.log. This one here:
2024-11-07T21:25:39 [Warning] CompanionAppService:GetResponse Der Remoteserver hat einen Fehler zurückgegeben: (400) Ungültige Anforderung.: {"m_HttpResponseHeaders":["Connection","Access-Control-Allow-Credentials","Request-Tag","Content-Length","Content-Type","Date","Server"],"m_Uri":"https://companion.orerve.net/fleetcarrier","m_Certificate":null,"m_Version":{"Major":1,"Minor":1,"Build":-1,"Revision":-1,"MajorRevision":-1,"MinorRevision":-1},"m_StatusCode":400,"m_ContentLength":112,"m_Verb":"GET","m_StatusDescription":"Bad Request","m_MediaType":null}
I'm closing this job now and will open another issue if I have more new facts about recognizing the celestial bodies.
Thank you @Tkael
Thanks. :-) From that error message you might want to try disconnecting and reconnecting with the Frontier API.
What's Wrong (please be as specific as possible)
Expected
Correct reading of the properties, if a loop is used for reading, the property is only recognised or output correctly on the second pass
Observed
Body properties are not recognised correctly, e.g. "body.alreadydiscovered" for newly discovered systems
Steps to reproduce
see text below
Configuration
My Investigation
Investigation Notes
see text below
EDDI Logs
eddi.log
Player journals
Journal.2024-10-18T150918.01.log
Hello everyone, I think EDDI has a problem recognising the properties of the celestial bodies correctly? How do I arrive at this assertion? I am currently outside the bubble to discover a few undiscovered systems. It was while doing this that I noticed something. Once you have found an undiscovered system (sun with the property ‘body.alreadydiscovered = false’), you scan the bodies of the system (planets and moons) with the VSS/FSS. If you use a loop to query the property of whether the body has already been discovered (to recognise undiscovered bodies), you will be told on the first run that all bodies have been discovered, except one. If you run the query a second time, the bodies are correctly displayed/announced as not yet discovered. (Loop, which I have used, see at the end). The entries in the journal are correct. The bodies are listed as ‘WasDiscovered:false’. It is now difficult for a second CMDR to understand this, as the system has already been discovered by me. But wait, I haven't submitted the data yet, so a second CMDR would be able to check this. Here is the system where I noticed this: Pyult ZZ-E c28-2 . Only the last planet (planet 5) is announced as ‘unknown’ on the first run, the other 4 planets are announced as ‘known’ on the first run. Perhaps this error also has to do with not recognising the second or third sun, which I already described in the last thread. The second run of the FSSDiscoveryScan recognises the second or third sun.
Recognition loop: