A terrible idea that involves SQL.

For AI and campaign script related discussions and questions
Post Reply
User avatar
NoQ
Special
Special
Posts: 6189
Joined: 24 Dec 2009, 11:35
Location: /var/zone

A terrible idea that involves SQL.

Post by NoQ » 31 Dec 2017, 08:36

I looked at #4688 and had a terrible idea. The code could have been refactored with the help of sql.js: put all stats into an in-memory per-AI SQL database at the beginning of the game, update those when various research is done, query whenever you are trying to pick the best weapon or whatever. Well, just wanted to share the aforementioned idea. Never mind, really.

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3753
Joined: 03 Aug 2006, 19:39

Re: A terrible idea that involves SQL.

Post by Per » 31 Dec 2017, 13:32

Why SQL? If you want raw access to stats, could just give direct access to the source JSONs.

User avatar
Darkling
Rookie
Rookie
Posts: 18
Joined: 07 Feb 2016, 00:45

Re: A terrible idea that involves SQL.

Post by Darkling » 31 Dec 2017, 14:13

It would be nice to be able to simply call up current stats for a weapon taking into account completed damage and rof research. It would give an easy way to rank weapons based on current damage output. Within a given weapon family later is usually better, but current expected damage would be a nice way to weight selections between weapon families.

User avatar
NoQ
Special
Special
Posts: 6189
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: A terrible idea that involves SQL.

Post by NoQ » 31 Dec 2017, 18:30

Per wrote:Why SQL? If you want raw access to stats, could just give direct access to the source JSONs.
Because i'm executing a complicated query with an ugly system of spaghetti functions that loop through JSON stats. So i thougth that SQL makes more sense for that. I didn't *actually* try to write down the queries it boils down to, but it feels like that.

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3753
Joined: 03 Aug 2006, 19:39

Re: A terrible idea that involves SQL.

Post by Per » 01 Jan 2018, 05:32

Ah. There are json-specific query languages that might be more appropriate in this case, which we could possibly support natively from the scripting API, like jq (through libjq) or jsoniq. Although I've never used any of them (except mongodb, which I would not recommend).

samuraicrow
Greenhorn
Posts: 10
Joined: 15 Sep 2015, 17:50

Re: A terrible idea that involves SQL.

Post by samuraicrow » 21 Mar 2018, 12:29

Per wrote:Ah. There are json-specific query languages that might be more appropriate in this case, which we could possibly support natively from the scripting API, like jq (through libjq) or jsoniq. Although I've never used any of them (except mongodb, which I would not recommend).
I agree. MongoDB is quite heavy for a single-user skirmish as is SQL.

Post Reply