Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
kb1

Wad compatibility option database - ideas

Recommended Posts

(created a new thread to split discussion from http://www.doomworld.com/vb/source-ports/57014-tnt-map30-stairs)

We all know the frustrations of getting 20 minutes into a game when we realize that we can't complete the map due to some compatibility/feature option being set incorrectly.
This thread is to share ideas, and discuss the possibility of creating some type of per-map database, constantly updated and maintained, that would contain a list of options required for proper play.
Of course, this is a monumental task, as there are tens of thousands of wads. But, many are vanilla-compatible, and entries can be added over time.

Here's my initial thoughts:
1. Format should be extremely simple - like text files. Don't let the fancy word "database" fool you.

2. Filenames should match wad filename, with a different extension. (.cop?? heh) Makes it real easy to find the compatibility file, and eliminates the need for the file to have a unique identifier (like a SHA-1, MD5 hash, etc.) Simply put the file in the same path as the wad.

3. One file per wad - no need to litter up directories. Could look like a Windows .ini file:

[Global]
; things which apply to all maps go here
use_doom_stair_building = 1

[Map03]
; applies to Map03 only
archvile_ghosts = 1
coop_friendly = 0
Above, I added a flag "coop_friendly" which, is not really an option, but this could provide a warning that the map doesn't work well with coop games, which follows the spirit of why we would make this database to begin with: To prevent problems when we just want to sit down a play a game

4. No need to add this to source ports (yet) - That can happen later, and would complicate the discussion. Sure, we need to design it to be ready for that next step. I envision a source port looking for a ".cop" file of the same name as each loaded wad, and parsing it into some type of simple "mapinfo-like" structure, discarding what it doesn't understand, and referencing it on each map load.

5. Accessibility? - These files would need to be hosted somewhere, and be available for download, update, etc. They would fit really well in the idgames archive, but I don't know how feasible that is.

6. More Info - Cautiously, I would suggest adding some more entries to the Global section, such as "idgames path", "iwad required", "other required wads", "wadfile hash", "wad name", etc. Some of that could be auto-populated based on the included .txt files. In fact, many of these ".cop" files could be pre-generated by writing a program to parse the .txt files and/or using the Doomworld db. Wads created before the first source release could automatically be considered vanilla - then, all each one would need was a list of required supplemental (texture, etc) wads, if that.

Please discuss further.

Share this post


Link to post

What, no XML? Where's that whole enterprisey factor?

Share this post


Link to post

Though I'm sure you meant that with tongue firmly in-cheek... I'll just say that given the format only really need consist of name = (mostly boolean) value pairs; XML is definitely overkill.

Heck, each map's options could even be described as a n-bit hash where the first 160 bits are the file's SHA-1, followed by 32 bits to hold the logical map index from the start of the file, followed by the compat bits on the end.

Share this post


Link to post
DaniJ said:

(scary format stuff)

Yeah, efficient, but not very editable without an app...
My big problem with the hash is that it won't survive a map update, whereas a filename-type match will.
The trickiest part of creating this database is
a) Standardizing the option set
b) What to do about defaults
c) Where to host - download/edit/upload/security/verification

For (a) I think a combination of ZDoom and PrBoom-Plus would cover most requirements. Once again, the goal is to prevent options from downright breaking games.

As for (b), this is tricky. At first, I was thinking that an omitted option should default to vanilla behavior, but I now tend to believe that a missing option should be treated as "don't care", just like it would if there was no option file present. That let's the file be used strictly to prevent gameplay problems, while allowing all the other options to be chosen freely. "Compat bits" are 0 or 1 - what we need is tri-state: Off, On, or Don't care, which uses the menu-selected option. Source ports could allow you to override at your own risk, etc.

Within the next couple of months or so, I'll be building some sort of similar thing for my local collection of wads, cause it annoys me to have these issues (especially more than once!) It would therefore be nice to share those efforts (and have some help setting options, of course).

Share this post


Link to post
kb1 said:

My big problem with the hash is that it won't survive a map update, whereas a filename-type match will.

The strength of the hash is, that after a map update, it may well have changed options.

Although, I wouldn't store the rest of the details as an n-bit hash - I'd prefer the text format for that. Easy to extend.

Share this post


Link to post
kb1 said:

Yeah, efficient, but not very editable without an app...

Indeed. That was sort of the reasoning behind it...

Imagine being able to click a few buttons in an HTML form on /idgames which calculates the hash and then adds it to the database alongside the addon itself. It could be easily stored in a SQL database and the whole lot could be exported using a simple script.

Share this post


Link to post
Yagisan said:

The strength of the hash is, that after a map update, it may well have changed options.

If the mapper has changed the map in a way that affects the options, he/she could also update the option file. (Not trying to argue, I'm just saying :)
But, I would want the option file to work, even if I rebuild nodes or reject. Specifically, if the file name matches, the file should get used, period, IMHO. Otherwise, you defeat the "easy-to-play, without-dicking-with-the-config" concept. I don't want something stupid that I've done to the wad (like change music, or a texture, etc.) to affect this ability to have the options get pretty damn near correct. Does that make sense?
I do understand the desire to tie the two together via a hash, or something. Maybe the hash could be included in a non-mandatory way ("Hash doesn't match, use file anyway?"), but I don't know if it's necessary or beneficial. I like the filename approach, because at least, the wad filename is unique in each directory, so a matching option file would be as well.

Share this post


Link to post

I don't like the idea of matching on file name alone because you have no way to determine if its the correct info. Say I have two files named coolmod.wad, one is for DOOM while the other is for DOOM2. By matching filenames you pass the onus onto the user to ensure they pair up the metadata with the addon in a fine-grained organisational structure which separates them. I.e., I couldn't dump all compat metadata into one file/directory without having to implement further bookkeeping to associate addon paths with addon-metadata paths. With a hash you retain this option.

Share this post


Link to post
DaniJ said:

Indeed. That was sort of the reasoning behind it...

Imagine being able to click a few buttons in an HTML form on /idgames which calculates the hash and then adds it to the database alongside the addon itself. It could be easily stored in a SQL database and the whole lot could be exported using a simple script.

Sounds reasonable. But, what would the download consist of? Option files as I am suggesting? A one-line-per-map CSV file with wad hashes duplicated for each map of a wad? Or map lump hashes?

DaniJ said:

I don't like the idea of matching on file name alone because you have no way to determine if its the correct info. Say I have two files named coolmod.wad, one is for DOOM while the other is for DOOM2. By matching filenames you pass the onus onto the user to ensure they pair up the metadata with the addon in a fine-grained organisational structure which separates them. I.e., I couldn't dump all compat metadata into one file/directory without having to implement further bookkeeping to associate addon paths with addon-metadata paths. With a hash you retain this option.

Yep, all valid points. For me personally, I stopped putting all wads in the same folder a long time ago, in fact I have one folder per wad which includes the .wad, .txt, .deh, etc., with the .zip discarded, so, for me adding a single file to each makes sense. But, there is definitely some value in having them all grouped together as a single, easily downloadable database/file.

There is strength in doing it both ways, and it all boils down to how the data is to be used:

Option 1. The option file stays with the wad, and a source port can use minimal code to load the corresponding file from the same path. In this case, "coolmod.wad" for Doom would have to be in a separate folder from "coolmod.wad" for Doom II. The option file would also specify "doom.wad" or "doom2.wad", which would be even more helpful.
If it seems important, the file *could* contain a hash that the source port/launcher uses as a overridable double-check. File can contain options that, possibly, some source ports don't understand, and thereby ignore, with a console warning if so equipped.

Option 2. The data for, say, all of idgames' wads exists in a, say, comma-delimited file, one-line per map per wad. Hashes could be maybe duplicated for each line for simplicity, and, possibly sorted alphabetically to allow binary search. A launcher program could match the wad hash with all corresponding lines in the CSV file, and then would have to devise a way to pass that config to the source port, if desired. Or, the source port can perform the wad hash and lookup itself. Custom/unusual options are more difficult to handle, but could be additional columns on the line.

Maybe I'm missing something, but to me, Option 2 is *a lot* more work, without buying you much. I'm not against having the hash included, but I think the matching filename idea gets you a lot of bang for the buck. It's only real drawback is that you carry another file along with the .wad, and the .txt, or the .zip. And, could be problematic if you like to place all .wads in the same folder (of course, each .wad would have a unique filename in that folder by definition, so that's not really an issue either.)

I do like the idea of being able to submit changes via checkboxes on an HTML form. Perhaps the options themselves can, in fact be stored via bits of an integer in the database. And, upon downloading the wad, the option file could be generated using those bits. Perhaps, also a hash could be included in the file as well.

It would be nice to not require the source port to compute hashs and look up entries in a file, or file folder - to me that's just not reasonable.

Why would you want to dump all the metadata in one folder anyway? (really, I'm curious). I suppose it could be a little difficult to place the option files if you've already downloaded the entire idgames archive and structure :)

Share this post


Link to post
kb1 said:

3. One file per wad - no need to litter up directories. Could look like a Windows .ini file

One file per wad would mean that if you had a huge number of wads, you'd have a huge number of compatibility files.

Just look at how prboom+ does the demo compatibility. There's a whole lot of wads covered there but it's all done in one file, not a file for each wad.

If each of those wads had a separate file it would be unwieldy.


As far as matching goes neither name only nor hash only covers all situations, so both should be used. Here's some examples.

If there's more than one wad with the same name, the hash is what would decide what settings to use.

If a filename is recognized but the hash doesn't match up, then it's less straightforward. Maybe it could be assumed to use the settings for the filename anyway (and possibly give a message to the user that settings maybe be wrong).

If there's more than one wad with the same name and the hash isn't recognized, an option to ask which settings to use might be best. There'd be no real way to determine what to do.

Share this post


Link to post
sector666 said:

One file per wad would mean that if you had a huge number of wads, you'd have a huge number of compatibility files.

..you're huge! That's means you have HUGE GUTS!!.. Sorry, heh! :)

sector666 said:

Just look at how prboom+ does the demo compatibility. There's a whole lot of wads covered there but it's all done in one file, not a file for each wad.

That's a thought too...of course, with demos, it's one line per-demo (or group of demos), not one line per map per wad, which does add another dimension of complexity to the problem.

sector666 said:

If each of those wads had a separate file it would be unwieldy.

Yes, and your OS will make each one of those take up a lot of hidden space (file partition size).

sector666 said:

As far as matching goes neither name only nor hash only covers all situations, so both should be used. Here's some examples.

If there's more than one wad with the same name, the hash is what would decide what settings to use.

If a filename is recognized but the hash doesn't match up, then it's less straightforward. Maybe it could be assumed to use the settings for the filename anyway (and possibly give a message to the user that settings maybe be wrong).

If there's more than one wad with the same name and the hash isn't recognized, an option to ask which settings to use might be best. There'd be no real way to determine what to do.

But, there's *always* a filename match if you're option filename matches the wad file. And there can be at most one match per folder - the OS dictates that. Yes, it's a bunch of little files. I just saw a 3TB external drive for $189 - a small price to pay for the prospect of flawless gaming. (not trying to be a smart-ass, just trying to present all sides of the equation, so to speak).

Share this post


Link to post
kb1 said:

Sounds reasonable. But, what would the download consist of? ...A one-line-per-map CSV file with wad hashes duplicated for each map of a wad?

This.

Maybe I'm missing something, but to me, Option 2 is *a lot* more work, without buying you much. I'm not against having the hash included, but I think the matching filename idea gets you a lot of bang for the buck. It's only real drawback is that you carry another file along with the .wad, and the .txt, or the .zip. And, could be problematic if you like to place all .wads in the same folder (of course, each .wad would have a unique filename in that folder by definition, so that's not really an issue either.)

The benefit behind this approach is that a port could potentially completely abstract the management of the metadata out of the user's sight. It wouldn't matter where you install your addons or the file structure an individual uses as the port could still reconcile metadata with addon paths.

It would be nice to not require the source port to compute hashs and look up entries in a file, or file folder - to me that's just not reasonable.

How so? If the port isn't going to compute the SHA-1 part of the hash then who is? Surely this is the least troublesome part, no? There are plenty of open source implementations out there.

Why would you want to dump all the metadata in one folder anyway? (really, I'm curious). I suppose it could be a little difficult to place the option files if you've already downloaded the entire idgames archive and structure :)

Automation. Ideally I'd like for implementing ports to be able to communicate directly with the compat database (e.g., using cURL I transmit an HTTP request which interfaces with the SQL database to return a list of complete hashs for each SHA-1) but for practical reasons that may not be desirable.

Share this post


Link to post
kb1 said:

..you're huge! That's means you have HUGE GUTS!!.. Sorry, heh! :)

RIP AND TEAR! :P

kb1 said:

..Yes, and your OS will make each one of those take up a lot of hidden space (file partition size).
Yes, it's a bunch of little files. I just saw a 3TB external drive for $189 - a small price to pay for the prospect of flawless gaming. (not trying to be a smart-ass, just trying to present all sides of the equation, so to speak).

That's not the real inconvenience of having so many files. Here's the reasons why I hate have having loads of tiny files when something could have been done with one or a few:

1. Extracting so many files from an archive takes much longer than extracting one file of the same size. This is a minor annoyance however, though it is much more noticeable on slow computers.

2. This is where I really, really dislike having thousands of tiny files. When you're running a search on your computer and have no idea where a particular file is, all the tiny little files on the drives slow the search down so much. Thousands of little files would make quite a difference when running a search. Because of that I hate things that put a load of little files on the drive.

You can get around that if you know the file you're looking for is above a certain size, but if that's not the case all the little files add extra minutes to a search. I don't want that.

3. I'm pretty sure it's much slower defragging a thousand little files than it would be to defrag one file or a few files of the same size. So it slows that down unnecessarily too.


Here's two possible ways I can think of to get the number of compatibility files down while still doing things close to the way you'd like:

1. Instead of one file per wad having one file for ever letter of the alphabet, and all the wads that start with that letter (plus one for numbers). That would reduce the number of files to 27 without cramming everything into one file.

2. Having one file per wad, but leaving them in an archive that does not need to be extracted. If all the ports that would use the compatibility list can support checking the files in archive that may be one way to go. But it would be slower than if there were fewer files, I believe.

kb1 said:

But, there's *always* a filename match if you're option filename matches the wad file.

Well here's the thing. With the 8 character limit in vanilla, some wads have filenames that make it hard to tell what it's even supposed to stand for. I have old wads sitting around that I renamed at some point years ago, so their names wouldn't match any name check. They would still have the same hash however. So due to the hash they could be recognized despite having a wrong name.

After all these years, I'm sure there would be other people who have some renamed wads too, for whatever reason. Checking hash as well as filename allows to get the largest number of compatibility matches.

Share this post


Link to post

Ok, so there's different ways of thinking about it - fair enough. The biggest reason I like the text files is that, I can fully re-create a database, from the file folders themselves. What I just realized is that, I can fully create individual text files from your all-in-one .csv file too! Of course, once the data is populated, you could always extract it and manipulate it as you see fit.

At this point, I'm more focused on capturing that data. I'd like to discuss exactly what fields are required. Remember the goal is not necessarily to give the mapper any additional abilities, other than ensuring that your source port of choice will properly render the game.

As stated previously, a subset of demo-compatibility options is a good place to start. I'd also like to see some non-options, like "coop-friendly", which could be used to warn the player of being in a map that doesn't work well in coop, for example.

If we really are going to go the .csv file route, it becomes more important to iron out the options (or, we'll have to create really long lines):

option_count, 4, coop-friendly, 1, boom-specials, 1, passthru, 1, doom-stair-building, 0, bla-bla
I think some options could be bits in an integer, but there has to be a way to add new flags later.

Share this post


Link to post

Personally I think it would be a mistake to start introducing new features at this stage. Especially if those are non-tangible or hard to quantify concepts like "is it coop friendly".

Let us first concentrate on what we know is needed, for example the lists of compatibility options/flags already implemented in many ports. We should derive a super set of all the options, eliminate redundancies and resolve any conflicts.

Share this post


Link to post

Properly formed CSV does not include a record count; it uses consecutive delimiters to indicate missing fields, ex:

Field1,Field2,Field3,Field4
foobar,,baz,
Records are terminated by a linebreak. If we were going to do CSV it should be proper CSV; otherwise just invent an entirely different way of doing the input.

Share this post


Link to post

Sorry, got here late in this discussion.

TNT MAP31, yellow key is multiplayer.
Just bought a copy of Doom Collectors Edition. TNT has the MAP31, yellow key is multiplayer only, bug.
(Of course, it is on a CDROM so every buyer will discover this anew)
Isn't this another of those things that ports need to fix ?


I like the original idea.
Those files need to be distributed with the source ports.
Source ports need to be able to distribute a few large combined option files.
And users must be able to add or force use of individual option files
they have made.
I do not play online (have no network on that machine), and many machines are not connected to internet at play time, so option files supplied by the source port download would be desired

Would be more efficient if several descriptions could be packaged in the same file. That means a port searches for all such files for any matching. This is something the individual port can do, combine descriptions into a faster lookup, or smaller distribution model.
It will have to be adapted to the unique way each port identifies a wad. Such a port would have to accept users files too, downloaded files, and user edited files, into its database, or bypassing the database. But this needs to be left to the database. The port will be needing to combine files and compress. But it should not be part of the distribution option file format. Ports will probably settle on a few ways to do this, but others will be radically different, for the same reason that every port store wad information and savegames differently.

Make it look like BEX as much as possible, because we already have BEX parsing functions in the ports.
CSV files are hard to edit, there are no line breaks, and it quickly runs off into 100 char lines.
In terms of file size, there is no difference between a comma and LF, but a LF is much easier on the person editing.
Could have term by a semicolon, and let CR LF be transparent and optional (put them as needed).

It must be possible for a user to easily write, edit, or otherwise change any such description.
Some ports may need a different setting, just because they have a unique ability that should be used.

The database might have a hash, the port may read the files and create a hash lookup of its own, but the distributed files should NOT contain any hash. HASH is too all encompassing, it prevents any modifications.
Identification has to be by something that can be different between wads, but always survives a mild user edit and zennode build.

Due to name clash and changing, by name is not going to be a great distinguishing factor. Some name substitution method will be needed by the port, such as a name redirection ability.
This could be a separate file that user makes:
[RENAME]
crazy= crazy1.2 # my wad named crazy is really crazy1.2

Identification by name has problems. DoomLegacy identifies by three possible names, plus some WAD LUMP present, and some WAD LUMP not present.
[OPTIONS]
[WADOPTION]
IDENTNAME= crazy, crazy1.2
IDENTLUMP= MAP31, GORRYTEX, THING334, THING335, THING336, THING337
IDENTLUMPNOT= MAP33, MAP34 #only in crazy1.3


Same options file MUST be used if the user modifies the PWAD with an editor. Otherwise developers have a headache. If a user makes a slight modification to a PWAD, the whole thing should not develop all sorts of unrelated errors (due to suddenly not using the options settings)

Speedups are something the port does after it gets the file to itself.

Some port developer (like me) may decide to allow these as wad lumps (why not). To make that feasible, they should look as much like a BEX or DEH lump as possible, so the existing parsers work.
Use the same comment char '#'.
Use the same "name = value" format.
Use "[OPTIONS]" BEX style headers.

There is no reason to introduce any radically new formats.
Have more than just 1/0 values. That assumes way too much about similarity of port implementations. Not every port has Boom style compatibility options. Some are going to be multiple choice.

Share this post


Link to post

Please do not take this the wrong way wesleyjohnson but pretty much every exception you raised is preemptively countered in the fundamental design of the proposed CSV hash scheme. Using such a design it is not necessary for the port to implement any of the numerous new mechanisms you suggested.

If you want to ship the CSV file with your port you'd be free to do so.

As far as I can see there seems to be division of opinion among port authors which ultimately originates from the requirements of the users of the ports they primarily represent. Doomsday users, for example, never need to rebuild a wad's nodes, thus there is far less need for transitive metadata. Is this the fundamental concern for those backing the no-hash argument?

Share this post


Link to post

The advantages of CSV or a similar format are that it's supported by spreadsheet and database tools (Excel reads and saves it, MySQL can export to it, etc), and reading it is dead simple. Even a college student still learning Java in CS2132 could write a CSV parser.

The disadvantages are that it has a fixed field order, and requires either certain characters to be escaped and/or for quoted-string support to be added.

So there are basically three options for CSV to be expandable:

  • suck it down and only add new fields at the end of the record
  • allow the fields to be specified in any order and actually pay attention to the field headers at the top (so for example in a C++ program with map<string, string> csv_file you would store the value in column N to field N key -- csv_file[field_N] = value_N;)
  • Store a non-CSV record at the beginning that describes the version of the standard to which the database adheres, and publish new spec'd out versions every time a field needs to be added.

Share this post


Link to post
Quasar said:

Properly formed CSV does not include a record count...

Never knew there was a rule above and beyond "comma-separated-values". Not sure how else you would go about providing the ability to add a variable number of flags.

If I am to be forced to actually use CSV (which is what others seem to prefer here), I would put a variable number of fields at the end of the line, after the fixed fields. And, yes, there's no need for a count, just parse until arriving at the end.

Admittently, when I wrote that text line, I was hoping to portray the awesome ugliness of using CSV, in hopes that others would realize that it's massively cleaner and extensible to use one option per line, with sections (like an .ini file). I suppose you could shove a bunch of wads into the same file using the .ini structure too. Over-engineering will kill this project before it gets started.

Share this post


Link to post

Geez, I've created a monster...

Everyone is getting hung up on a file format. My whole thoughts were to create a simple method to ensure that playing a random wad was simple. If I'm playing TNT.wad and the stairs break, I want to quit, open a new text file, type

[Global]doom-stair-building = true
, click Save As, and type \Doom\IWads\TNT\tnt.opt, and be done with it. Not compute checksums, add up bit fields, search a huge text file, etc. I see some value in those things, but making it any more complicated than what I described is going to doom the project.

Sure, all of those other abilities and complexities can be tacked on to it, and nothing is preventing that from occurring as well. But, right now, we have 0kb of data to put into any format.

How many of you *don't* have the idgames archive on your HDD? Any one of us can run off a list of hashes, filenames with paths, etc., and turn my messy little config files into just about any slick database you desire. That can come later.

I propose we focus on Name/Value pairs that, when set properly, helps to prevent gameplay problems, possibly better than a lot of our recent source port efforts could. Iron those out, and we'll get it into a format that allows all manners of over-engineering!

Share this post


Link to post
Quasar said:

The disadvantages are that it has a fixed field order, and requires either certain characters to be escaped and/or for quoted-string support to be added.

Of course, if we hashed all options into a single field we wouldn't need to worry about changing the format at a later date. We could simply append bits to the end of The One field as and when they are needed. Implementers would simply stop interpreting bits once it's reached the nth bit it supports.

Edit: Response to kb1's second post.

I think you are grossly exaggerating your perceived impracticalities of using CSV and hashes.

1) Given that any implementing ports are required to compute the hash in order to make use of them, the port itself can be used to generate and output the completed hash for the user.
2) An ini like representation requires significant extra storage (compared to a hash) and requires the user to deliberately manage said files in a compatible organisation structure.
3) An ini like representation cannot exist purely in a database unless you use BLOBs or other such storage types. This representation cannot be easily sorted and/or indexed.
4) Managing an ini like representation mandates considerable bookkeeping mechanisms from any implementing applications.

While it might first appear rather complicated to use the CSV with hash representation its actually a lot more practical and avoids a large amount of the complexity involved in a flat-file, textual format.

Share this post


Link to post

I've actually thought about doing something like this. A database that holds all the dmgflags/compatability flags for specific wads. Of course the feat to maintain and update this is tremendous but would get better over time.

I'm in the process of prototyping a GZDoom Launcher that should be able to do this. However, my plan is not to create an actual database that people connect to. It will just be a file that gets loaded by the launcher. Any updates to the launcher itself can potentially come with the updated local database.

Letting a launcher handle all the flags instead of the sourceport itself would be an easier task and less intrusive.

A good format to choose for something like this would be XML. Now, if we are really concerned about light-weight stuff, you could use JSON. http://en.wikipedia.org/wiki/JSON

Share this post


Link to post

Ease of end user edit-ability is the least important factor in this. Those of you fixated on verbose ini/xml/etc... text formats need to realise just how trivial it would be to write a de-/en- coder which takes the hashed form and spits out a pretty formatted ini file (if that is your want), or vice versa. Its not even a days work.

What is important however is the representation of this data in the central "database". This is where we need scalable "enterprisey" solutions as Maes put it. Unless it is of a form that can be expressed succinctly while pushing minimal overhead onto the database itself; it really doesn't matter how much data any individual collects using their ini file approach because I sincerely doubt you'll convince say /idgames to implement that model.

Its already a great shame that valuable metadata exists in effectively non-parse-able text files when it could instead be a record in a database. Lets not do the same with the compat options.

Share this post


Link to post

At my job we use the freeware Firebird database, which grew out of the originally commercial Borland InterBase. It is SQL and is up to par with the latest standard, including some features that Oracle and MS tout in their own products as if they invented and own them :P

If we had a server to set it up on, it could serve as the authoritative database ;)

Share this post


Link to post

Well, to be honest I could set this up myself on dengine.net but that would be rather silly when /idgames already exists.

If we can come up with a model that is lite enough to have negligible impact on the database I can't really see /idgames not adopting it, especially if its just one more field in a single table...

Share this post


Link to post

I suggested BEX because everyone with an editor could make files.
I run Linux.
Microsoft based databases will be a detriment to me.
I do not have Excel.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×