vpdb / server Goto Github PK

So far, progress doesn't seem to be working when uploading

• backglass
• logo
• playfield screenshot
• playfield video

Also check rotations, there seems to be a problem rotating the video.

I think this would be cool.

As far as I understood, P-ROC-based games run without ROM but a set of Python scripts (among other stuff). These files however end up in a separate folder, where P-ROC is installed. The table then needs to adapt the script in order to access it.

@horseyhorsey: is this accurate, and what interesting metadata could be extracted from those games that could be displayed to the user when browsing? Is the scripting something that could be done automatically or is in any case a special .vpx build needed?

See also:

• Thread on VPF
• Wiki

Long primary titles will overlap. This is a solution.

Nice resource

Feedback:

While uploading VPT file as ongoing, I typed release name then tried to set flavors and i think the
options could not be selected during the table upload. Once upload was done, I could select the
options.

Needed if VPDB Agent shows multiple matches with different thumbs of the same release.

Marked has as security vulnerability they apparently don't want to fix.

Not sure if we can pull multiple email addresses from GitHub, but Google returns a list of emails and we should try to match any of them in order to avoid duplicate account creation.

Something to help with release naming. See here

When listing releases, we show them by default with portrait thumbs because they better fill up space and are nicer to look at:

However, some releases obviously are only available in landscape ("desktop"), so they end up looking like this:

The idea here is to take the original landscape screenshot and distort it like this:

Then crop and resize it so it looks like this:

The problem is that the angle of the distortion can vary quite a bit:

So in order to generate the thumbnail automatically, VPDB needs to look at the table params and somehow calculate the right angle in order to distort correctly. There are quite a few parameters to play with:

I'm planning to use ImageMagick's four point distortion feature for this, so I'd need some way to calculate the 4 intersection points between the table and the canvas.

The table params should be easy enough to read from the table file. However, if someone (like a math wizard such as @c-f-h) has an idea how to calculate the distortion params, I'm listening. :)

Usually, only drag and drop is working. Add click support.

Specially when there's only one flavor to download.

Or rollback to Angular 1.3 if angular-ui/bootstrap#3676 doesn't get fixed

Some lightbox style fullscreen mode.

Some cron job should regularly clear them out.

Is the Redis server started, anyway to test? I have no idea...

'<2015-11-03T01:50:30.846Z - info: [model] Schema "Build" registered.
2015-11-03T01:50:30.860Z - info: [model] Schema "Comment" registered.
2015-11-03T01:50:31.282Z - info: [quota] Initializing quotas...
2015-11-03T01:50:31.283Z - info: [quota] Creating quota for credits per day...
2015-11-03T01:50:31.333Z - info: [model] Schema "File" registered.
2015-11-03T01:50:31.343Z - info: [model] Schema "Game" registered.
2015-11-03T01:50:31.347Z - info: [model] Schema "LogEvent" registered.
2015-11-03T01:50:31.349Z - info: [model] Schema "LogUser" registered.
2015-11-03T01:50:31.350Z - info: [model] Schema "Rating" registered.
2015-11-03T01:50:31.368Z - info: [model] Schema "Release" registered.
2015-11-03T01:50:31.371Z - info: [model] Schema "Rom" registered.
2015-11-03T01:50:31.373Z - info: [model] Schema "Star" registered.
2015-11-03T01:50:31.374Z - info: [model] Schema "Tag" registered.
2015-11-03T01:50:31.377Z - info: [model] Schema "Token" registered.
2015-11-03T01:50:31.384Z - info: [model] Schema "User" registered.
events.js:141
throw er; // Unhandled 'error' event
^

Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379
at RedisClient.on_error (I:\PinballX\node-vpdb\node_modules\redis\index.js:196:24)
at Socket. (I:\PinballX\node-vpdb\node_modules\redis\index.js:106:14)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at emitErrorNT (net.js:1253:8)
at doNTCallback2 (node.js:450:9)
at process._tickDomainCallback (node.js:405:17)

I:\PinballX\node-vpdb>>'

Plans in settings are defined as props, so when migrating settings, default plans are re-added every time.

Either change plans to an array (duh) or disable automatic settings migration.

API:

• Add update resource
• Copy media when necessary

Web:

• Edit base data
• Edit backglass and logo
• Be able to remove external media

• [API] Add directb2s MIME type
• [API] Crush down PNG files in directb2s file
• [API] Generate thumbnails from directb2s uploads
• [API] Create entity which links files and authors
• [API] Link uploads automatically to correct game using the ROM name in the file
• [Web] Add single upload to frontend
• [Web] List backglasses under game

Just some things I ran into during the setup.

Node JS

Redis

Server install command.
<redis-server --service-install redis.windows.conf --loglevel verbose -- service-name redisService>

The goal is to verify that content is owned by the uploader, that it corresponds to VPDB's quality requirements and that it aligns with VPDB's content policy before showing and distributing it. Per default, releases, media and B2S backglasses are verified (ROMs should become upload by moderator only).

Per default, uploaded content needs to be "approved" before it shows up publicly. Once a moderator approves, it becomes visible for everybody. Contributors have auto-accept permissions which skip the whole process.

Unapproved or refused content is invisible in listings and detail views are only visible by moderators and authors of the uploaded content. There is a view that allows moderators to list the queue of pending items. Uploaders are notified by email if their content is accepted or refused (see #67).

Adding updates or new versions to an existing release does not need further verification. However, there should be a way to "unaccept" content that has falsely published.

Data-wise, we'll have the following attributes:

is_approved:    { type: Boolean, required: true, 'default': false },
is_refused:     { type: Boolean, required: true, 'default': false },
auto_approved:  { type: Boolean, required: true, 'default': false },
history: [{
    event:       { type: String, 'enum': ['approved', 'refused', 'pending'], required: true },
    message:     { type: String },
    created_at:  { type: Date },
    _created_by: { type: Schema.ObjectId, ref: 'User' }
}]

A moderate mongoose plugin is used so controller code stays minimal.

Should contain links to:

• About
• GitHub
• Rules
• Sitemap
• FAQ
• Privacy Policy
• Terms and Conditions
• Forum (?)

Currently, it just refuses download and the user needs to click on download again when logged.

It should either

• Automatically open the release download dialog after login, or
• Start with the release download dialog even when not logged, display the login dialog after pressing "download", and serve the zip after login.

Still needs README & co filled up correctly.

When uploading another ROM after having submitted one or more ROMs already, The client seems to multi-post to /api/v1/games/{game_id}/roms resulting in a validation error on server side (client is silent, only console outputs error).

Tables with e.g. external music usually don't update the mp3s across versions, yet they need to be included in the download archive.

Currently, if the uploader doesn't include them for a new version, they won't be included in the download. There should be an option "persist file across releases" where non-table files are retrieved from the latest version that includes them.

Either make both empty or fill current date.

First release takes all the place. It would be better to only briefly list releases on the game details page and add another release details page.

This comes with a few more advantages:

• More space for everything on the release details page (now it's really crowded)
• Releases can be linked more easily
• It makes more sense navigation-wise. Ending up on the same page when clicking on a game or on a release is weird.
• Add release details page
• Add release views to API and stats
• Change game details page to smaller panels
• Update links: Release lists should point to the details pages

Comment for the record:

I think it might be easier for use to see a screen similar to the Release Tab but filtered only on Mystery Castle, so the see the 2 screenshots of the releases side by side and when they select on, it goes to the detailed page with release details and download option. if you keep the current format, maybe put at the top, how many releases are available, provide sort options, as it was not obvious to me that there was the AUTHOR2 release below. If there are tons of comments on the first release, scrolling to the 2nd author or 3rd author will be cumbersome.

See Dependency Report

Good article

Should be at least compact and large view. Table view probably not yet.

https://raygun.io/docs/languages/node-js

Contrarily to the user log, the action log is visible to everybody. It serves a general time line and can be filtered, trigger notifications etc.