A terrible idea that involves SQL.
A terrible idea that involves SQL.
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.
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: A terrible idea that involves SQL.
Why SQL? If you want raw access to stats, could just give direct access to the source JSONs.
Re: A terrible idea that involves SQL.
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.
Re: A terrible idea that involves SQL.
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 wrote:Why SQL? If you want raw access to stats, could just give direct access to the source JSONs.
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: A terrible idea that involves SQL.
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).
-
- Greenhorn
- Posts: 12
- Joined: 15 Sep 2015, 17:50
Re: A terrible idea that involves SQL.
I agree. MongoDB is quite heavy for a single-user skirmish as is SQL.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).