The RFC builtin database replacement card discussion
JuliusBorisov
Member, Administrator, Moderator, Developer Posts: 22,754
Greatings, NWN:EE enthusiasts!
Please, provide more details and feedback for
https://trello.com/c/urQVWOsc/14-rfc-builtin-database-replacement
in this thread.
Please, provide more details and feedback for
https://trello.com/c/urQVWOsc/14-rfc-builtin-database-replacement
in this thread.
0
This discussion has been closed.
Comments
Sql is always the most robust / flexible /reliable anyway.
So, @Cablefish , if you have a reason for not using NWNX on your PW, I'd love to hear it.
The nwdb does have some issues that, as of 1.69, I believe still have't been "fixed". If I remeber correctly it doesn't handle the float data type well. Thus the need for Nats scripts to flush the database and what not. Otherwise you will end up with a bloated database that can cause some in-game issues like lag when using "GetCampaign" functions.
Not all PWs use NWNX or at most, many are ONLY using the watchdog aspect of it to reset the PW. The one I used to script on was one of those. Setting up watchdog alone is enough to turn some would be PWs away from seeing the light of day. Now add on too that setting up the database, especially for people without much scripting knowledge, they just don't want to touch it. Integration and ease of use will make people less "afraid" of it.
Adding an updated, reliable database with more flexibilty and more functions may help the scripting and module community as well. And since Beamdog is already integrating aspects of NWNX, why not integrate it's database or similar?
I, myself, am developing a sandbox-type module that I want playable singleplayer and on LAN sessions, so I need to provide persistence that can't be based on NWNX. If a PW's definition is in its name, then by all means my module is a PW.
Then there are other uses of databases:
-it's the only way of storing actual game objects and not just their IDs
-non-PW modules can have some creative uses of databases - see Infinite Dungeons and its dungeon sharing feature
Right, because it makes a copy. You can also do a CopyObject(), and store that as a local, it'd do the same thing.
Or do you actually need the relational aspect of SQL to perform complex queries/updates?
@NeverwinterWights In that case, wouldn't a better feature request be "Make NWNX easier to use"? The endgame of the docker approach is to be able to just take the "server package", add your module/haks to it, and run a "deploy" script.
Keep in mind that all the features we request take dev time away from other features. So, isn't it better to just make it easier to use ALL of NWNX. One great advantage of NWNX is that it isn't bottlenecked by just a few devs - there's dozens of people willing to add features to it, which would then be usable by all servers.
Me and my friend were just talking about this the other day in fact (two 40 year old dudes drinking coffee at Denny's, reminiscing about the good old NWN days). He really got into NWN2, started his own PW, but handed it off years ago to someone else. Myself and a group of other peeps from a PW decided to start our own NWN1 PW. Lasted for a couple years and then life happened. Anyway, one of the things we both hated having to do was messing around with NWNX to get the game to do what a PW needs to do.
On the other hand, I don't quite see how "you need to go over to this website and download this thing that isn't really part of our game" is the big barrier to making a traditional PW. Building a PW is a lot of work, measured in hundreds or even thousands of man-hours. There will be dozens of things you're not familiar with that you'll need to do, which will involve searching online, going through other projects on the vault and so on. Is following a 30 minute tutorial on how to set up NWNX really a dealbreaker here?
Granted, the tutorial doesn't exist, but it probably will - and certainly could. What I'm saying is that making such a tutorial, and making it so the process is simple enough to be doable in 30 minutes, is a much better use of the limited resources.
It's not that it's a deal breaker. It's a PITA. Especially when a couple years goes by before you have to do it again and you forget how and have to go look it up and install it again.
So this is just going to be one of those agree to disagree type things. Personally I think of NWN as more of this PW building software that should have always just had NWNX type features built in. And if they can, they should.
All features we request at worst, take eyes away from other requested features of which will still be seen and added to Trello.
Then the features we request get put into Trello... Which uses the community to work through the churn.
Then finally someone in charge will make the call if a feature can and should be implemented or if time is better spent elsewhere.
It's really only if Beamdog decide to move forward with an idea that it begins to take any serious time away from other potential features.
I can petition to have NWN fully rebuilt into a 16bit JRPG. I could get 10,000 likes on Trello and that means absolutely nothing the moment someone in charge takes a quick look and decides it's outside the scope of the EE and resources could better be spent elsewhere.
At most I would waste my time and the time of people who wanted to participate in the discussion. And the 30 seconds it took for someone in charge to skim over the post and go "NOPE!"
If you are concerned with preserving precious development time and making sure eyes are on the right feature requests then don't continuously respond to ideas you don't like on the forum and don't upvote them on Trello.
Because every time you respond to something like this you are bumping down the features you actually do want to see make it into the game and drawing more eyes onto the ones you do not.
Otherwise, it's all good healthy discussion.
On that subject...
-----------------------------------------------
My $0.02:
It would be nice if the bioware database worked better. However, NWNX has been handling the database side of PW's for a decade or more just fine. If it ain't broke... Don't fix it.
That's all.
Best regards,
- Jamie
https://trello.com/b/K0C0i8wF/neverwinter-nights-enhanced-edition
Which still means by taking on a crusade you are drawing focus away from ideas you want to be implemented rather than pushing ideas you like.
Every time you adamently argue why database functionality shouldnt be extended then more people will respond as to why it should. There would have been all of 3 responses to this idea if you said your piece and left it alone and instead there is an active debate with lots more reasons why. Which is great if you want to see healthy discourse but bad if you have an agenda.
You do you my friend.
However, social media has taught us the best way to squash things we don't like is to not talk about them. Heck, it's the principle that reddit is founded on.
In 2017 we just ignore it and it goes away. Then signal boost the things we do like. It has been proven to be very effective.
So if you actually want to see the database system replaced then the devils advocate path is a great way to do so and I commend you on your dedication. Otherwise you could probably find more success focusing on telling people why the things you want are great as opposed to why the things they want are stupid.
Because anything else leads to the active discussion and the free sharing of ideas, much like you and I are doing now.
Imagine if every post you have made here and every response to you in kind was in support of a feature you cared about while this thread sat at the bottom of the list with all of 3 responses. That would probably be more effective in actualizing the features you want. Right?
Just a thought,
- Jamie
--------------------------
NWNX is Linux only at present - nothing need be said more there.
Our systems are arguably the most advanced in NWN - a dumbed down version released in CEP 2.4 but we have far more than that and NO NWNX and NO SQL.
I would agree that database update in capability would be great - I have one overriding concern - my existing databases must be backward compataible or a conversion program that is flawless need be available.
My crafting, much monster creation, storage and spawning come for the database as well as items not on the pallet we store in a DM resource area - items by the - don't have an exact count but - by the many hundreads. If the NWN db was remade and that broke my database it would be a major blow and loss of work, some irretrievable.
so yes more capability and yes we use some scripted solutions to db management but it is still all NWN DB.
I use to work with Dbase years ago - first just writing code and then came a wizard where you clicked options and selected data and like magic it all setup and worked. Now there is an idea, as long as one can modify the code and is not forced to use the wizard but can write their own instead.
Are you using Natural Bioware Database Extension or just raw Bioware database?
What kind of persistent systems are you using? Location/chest/time/bank/journal/quest?
Tell me your secrets!
yes we have banks, saddle bags, storage systems and more - we have a pixie post system that can send money, items, and creatures.
The postal system is persistent and goes player to player and DM to player or player to DM.
We can build with placeables in game and keep it persistent or change out a set for seasonal changes -
We use the Stage Manager System to set up seasonal questing systems for October fest, Yule, Spring Feat, Summer Fest and Harvest - just put the proper widget set in the setup chest in the DM area and it is done.
There is more - much more - and all with the NWN database.
So how are you getting around the NWN perceived slowness? Is it just no longer an issue in 2017?
I ask because as amazing as NWNX is, using the built in database has potentially greater long time compatibility should the game go dark again, simply by the benefit of being self contained.
NWNX was the gold standard in 2007 but it is a decade later and I honestly didn't bother to even try NWNDB when I returned.
I hope you don't mind me asking. However, the answer does change the complexion of this discussion.
- Jamie
@voidofopinion and @Sherincall These "Need More Discussion" cards appeared in the Roadmap at once as this is the start of the card system, and they were moved to the Roadmap and not to the Input because of the mix of popularity (as the forum and other places showed) and the devs' opinion.
So no need to worry, and these threads are for constuctive feedback about the topic, not the talk about whether the card(s) should exist.
So these discussions are just that. Discussions. And no one needs to feel threatened by the conversation simply existing.
Thank you.
GetSystemDate() Returns the current date in the format (mm/dd/yyyy)
GetSystemTime() Returns current time in the format (24:mm:ss)
GetTimestamp() Returns the number of seconds since midnight on January 1, 1970
Their importance cannot be underestimated.
Yes there are some other nice things could be added but these three calls are very important and should not be breakng the bank to add them.
Also, this is NWN:EE (Enhanced Edition) for a reason, the intention should be enhancing it and I think the right bet is using non obsolete standards that designers in 2018 and forward can easily use.
If someone specifically wants the timestamp at the start of a database transaction, likely they want actual transactionally compliant SQL and can use nwnx.
more on this here:
https://forums.beamdog.com/discussion/comment/932243#Comment_932243
For the internal database that NWN uses, I'd personally think it'd be good to spend some brainpower and update it to something more modern. Those cruddy dBase files in the servervault directory are a nightmare and bloat horribly over time. SQLite would be a logical upgrade path and a good choice (embedded friendly, multi-platform, decent performance, standards based-ish). .
As far as the NWNX stuff goes - that's a separate discussion. That functionality should exist there for the people that need it. Currently, the unified NWNX only supports MySQL, but others will come in time, I'm sure.