You are not logged in.

#26 2019-11-06 21:39:27

Spirit
Administrator

Re: A weekend of Quaddicted future?

How about this year? Small, global, hackathon style?

#27 2019-11-10 01:30:38

efess
Member

Re: A weekend of Quaddicted future?

I'm down. Lets do this!

#28 2019-12-10 21:32:03

Spirit
Administrator

Re: A weekend of Quaddicted future?

I might find some time in the end of the year. Any suggestions what to focus on? I would prefer to iteratively replace bits of the current system step by step so it stays fun and managable. Maybe a conversion of the current database to that JSON format first, then the reverse of parsing that into the database? Then we could put the JSON files into Git, let everyone contribute and have the database take updates to the live site.

#29 2019-12-22 08:55:02

Spirit
Administrator

Re: A weekend of Quaddicted future?

Maybe a conversion of the current database to that JSON format first, then the reverse of parsing that into the database?

I will be working on that today.

#30 2019-12-22 13:52:00

Spirit
Administrator

Re: A weekend of Quaddicted future?

I am on dumptruck's discord and would love some collaboration :)

#31 2019-12-22 14:52:10

Spirit
Administrator

Re: A weekend of Quaddicted future?

#32 2019-12-23 20:44:53

Spirit
Administrator

Re: A weekend of Quaddicted future?

We have a dedicated channel on dumptruck's discord now, you are welcome to join in there.

Here is what I posted as mission:

So here is the gist:
This is about https://www.quaddicted.com/reviews/ and the database behind it

The problem(s)
- The site is in a state where updates are requiring too much work and the code is terrible
- Uploading files relies on me and only few people can then add them to the database
- Because people release different versions of files with the same filename, the whole system of using the filename as idenficator is not working
- Because people like to release maps not as zip but also as plain bsp files or rar or 7z, the limitation to zip files does not work
- Because files are often packaged weirdly and file paths inside of releases can clash with others (think "readme.txt") automated installations with the Quake Injector often fail or require manual repackaging of files (which goes against the whole idea of an archive). All we have in the database at the moment is an instruction where to extract a zip file which does not make a conflict-free and working installation possible in some cases


The idea(s)
- Instead of having the database editor interface available to just a few people (:heart:negke:heart:), we will have a public Git repository filled with one JSON file per released file
- This JSON file will describe the file itself and have a dictionary of tags describing the contents
- This includes neutral information like author names, the title, tags about the size or texture set, the releasedate etc.
- This does not include the description (maybe it will? let's discuss this), the editor's rating, the user ratings or comments, those will stay in the Quaddicted database
- Things like dependencies, external links, alternative download URLs could all be added as tags
- Things like installation instructions and commandline parameters as well
- The files included in the file itself (e. g. things inside a zip archive) will be listed in a dictionary with rudimentary information, this could also be extended for files included in these (e. g. zipped sources, contents of pak files, etc.). This will be used e. g. to determine if something is a mod or just a plain bsp release.
- Anyone will be able to send a Pull Request for proposing changes to these files! Spot a mistake? You can fix it! Installation was broken? You can fix it! Lots of people will get merge rights on the repository.
- The JSON files will very regularly get ingested into a database at Quaddicted that serves a new and improved https://www.quaddicted.com/reviews/ and links the data to its Quaddicted data (description, ratings, comments)


Now, for some bad news. URLs will not be nice and readable like https://www.quaddicted.com/reviews/100b2.html anymore. As I said above, filenames can not serve as identificators unfortunately. Instead we will use a sha256 hash of the file. That's something ugly like 51f6502bd842a0a9d0e439e0f59000f13333141be0f15d1185c323f64bf0612... https://www.quaddicted.com/reviews/51f6 … 64bf0612d/ for a "review" page, https://www.quaddicted.com/files/by-sha … lename.zip for a download URL. A side benefit is that this is content-addressable, an engine or tool could be pointed at a random file, calculate its hash and get the appropriate JSON file for installation and launching instructions.
Here is an example JSON generated from the current DB: https://github.com/SpiritQuaddicted/Qua … cf181.json

How you can help
- The Quake Injector and other tools/engines relying on the current system will stop getting updates and probably break. If you know Java, updating the Quake Injector to this would be awesome. If you are an engine coder, I know that FTEQW and Mark V have some QI-based support.
- I would like to base the new backend and frontend on Python. Backend I can do, but web frontend I suck at. If you know Flask or Django, you could write the new public face of the Quake files at Quaddicted :)
- The JSON files need a schema and a validator, fancy that? Yay!
- Discuss my idea (please also read through the messy https://www.quaddicted.com/forum/viewtopic.php?id=622 ), propose better alternatives (on a small scale, not the general idea)
- Come up with a way to describe complex installation instructions in JSON, think not only extracting to a certain relative path in the Quake directory, but renaming files or placing them in different locations
- Come up with a way to describe launching instructions and engine requirements. Maybe we should just have a commandline:fteqw=-this and that sub-namespace?
- Pull Requests should go through validation and linting before they could be accepted, if you know how to set up that kind of stuff at GitHub, you would help so much!

So far I wrote some Python to play with the existing database, exported it to JSON files (https://github.com/SpiritQuaddicted/Qua … layground/) and imported those back into a new database with just two tables: files and tags.

Next step will be a prototyp of a webpage like https://www.quaddicted.com/reviews/ and the details pages linked from it.

Quick reply

Write your message and submit
Are you human or robot? If you have trouble, mail to spirit åt quaddicted døt c

Checking if this is requested by a real person and not an automated program.

Board footer