Submission Testing Instructions: Difference between revisions
(added category) |
(→BitPlayer: fixed a typo) |
||
Line 189: | Line 189: | ||
If you've never tested a BitPlayer submission before, you'll need to set up a Testing Curation in the Games tab of Core. In the Games tab, you will need to click the New Game button in the bottom right of the window. The only field you need to fill out is the Application Path, which needs to be <code>FPSoftware\FlashpointSecurePlayer.exe</code>. You can set any other fields however you want. | If you've never tested a BitPlayer submission before, you'll need to set up a Testing Curation in the Games tab of Core. In the Games tab, you will need to click the New Game button in the bottom right of the window. The only field you need to fill out is the Application Path, which needs to be <code>FPSoftware\FlashpointSecurePlayer.exe</code>. You can set any other fields however you want. | ||
When testing a BitPlayer submission, you'll need to copy all of the files in the Content folder and move them into the <code>Legacy/htdocs</code> folder of Core. You'll then copy the submission's Launch Command and paste it into your Testing Curation's Launch Command field. | When testing a BitPlayer submission, you'll need to copy all of the files in the Content folder and move them into the <code>Legacy/htdocs</code> folder of Core. You'll then copy the submission's Launch Command and paste it into your Testing Curation's Launch Command field. Then run the submission using the Testing Curation's Play button. | ||
====Hyper-G and Hypercosm==== | ====Hyper-G and Hypercosm==== |
Revision as of 21:35, 4 June 2022
Checking Metadata
This list contains the basic requirements for each metadata field, however this is not a complete list of all ways that the metadata can be correct or incorrect. If you're unsure whether something is allowed, you should ask in one of the staff channels.
Field | Requirements |
---|---|
Title and Alternate Title | Titles should:
Along with the above, Alternate Titles should:
|
Library | The Library field should be:
|
Series | The Series field should:
|
Developer and Publisher | Changes should be requested for either of these two fields if:
You don't need to request changes for differences in how the Developer or Publisher's name is written. For example |
Tags | Changes should be requested if:
|
Play Mode | Changes should be requested if the Play Mode is missing supporting modes or if the listed mode is incorrect. |
Status | Changes should be requested if:
|
Version and Release Date | These fields are only incorrect if the information is wrong. The information being missing is not something that needs to have changes requested for. |
Language | The Language field should:
|
Source | The Source field should:
|
Platform | Changes should be requested if this field is incorrect.
For information specific to each Platform go to #Platform Specific Requirements. |
Application Path | Changes should be requested if the Application Path:
|
Launch Command | Changes should be requested if the Launch Command:
|
Notes | Changes should be requested if:
|
Original Description | This field is only incorrect if what's in it is not an Original Description. This includes the curator making up their own description or the Notes or Curation Notes being in the wrong field. |
Curation Notes | This field is only incorrect if the information in it should actually be in the Notes field. Since the Curation Notes are not kept when the submission is added to Flashpoint, unnecessary text is not an issue. |
Alternate Applications | Changes should be requested if:
|
Extras | Changes should be requested if:
|
Logo | Changes should be requested if the Logo:
|
Screenshot | Changes should be requested if the Screenshot:
|
Content Files | Changes should be requested if:
|
Platform Specific Requirements
Some Platforms have their own specific requirements for what makes a properly curated submission. These things will need to be checked when testing a game of that Platform. If a Platform is not listed in the sections below, it has no special requirements. For submissions of those Platforms, you will only need to check whether it works.
Common Platforms
Flash
Flash is the most common Platform you will come across while testing.
- Flash submissions must run in Flash Player or Basilisk. Which of the two a submission runs in, or what version of Flash Player is chosen, does not matter as long as the submission works as intended.
- Flash submissions cannot be run in Browser Mode.
- If the submission is set to run in Basilisk, it should typically have an HTML embed. Games that run properly in a full screen size may be fine without embed.
- Submissions running in Flash Player should not open tabs in the user's normal browser when run or when clicking buttons that aren't supposed to link to other websites. If a game has this issue, it should be run in Basilisk using an HTML embed. An exception is made for games which need an older version of Flash Player than Flash 32, as they cannot be run in Basilisk, however they do need a Note about the issue.
Shockwave
- Shockwave submissions must run in the Shockwave Projector or in Basilisk.
- If the submission is running in Basilisk, it must have an HTML embed. Unlike with Flash, there is no exception to this.
- Shockwave curations should not have Script Errors unless absolutely unavoidable and with a Note explaining the issue.
- Curations running in the Shockwave Projector should close by clicking the X button in the top right corner.
- Submissions running in the Shockwave Projector should not open tabs in the user's normal browser.
HTML5
- HTML5 submissions usually run in Basilisk, Browser Mode, or Chromium. In rare cases they will run in Flashpoint Secure Player or Netscape. Which of these browsers is chosen does not matter as long as the submission works as intended.
- If the submission gives a
QuotaExeededError
or any other error related to the browser it's running in, changes should be requested to have it run in a different browser, unless the error is unavoidable and a Note is included. - HTML5 submissions should run as intended with the browser window at full size, unless otherwise Noted.
- HTML5 Alternate Applications cannot run in Browser Mode.
Unity
- Unity submissions must have an HTML embed, without exception.
- Unity submissions cannot contain a
webplayer.unity3d.com
folder with updater files inside.
Java
- If the submission is running in browser, it should have a Curation Note listing a domain that needs to be added to the Exceptions List.
- Before testing a Java submission that runs in browser, you will need to copy and paste that domain onto the end of the file
FPSoftware\Java\JDK_1.8.0_181\jre\lib\exception.sites
in your Core folder. If the domain is already on the list, then this is not needed. - Java submissions instead running in AppletViewer should not have a Curation Note about an exception.
Less Common Platforms
ActiveX
ActiveX submissions will have a FPSoftware
folder next to their Content folder. This folder will need to be merged with Core's FPSoftware
folder before testing.
If this folder is missing, inside the Content folder, or is otherwise incorrect, the submission is not properly curated and changes will need to be requested.
BitPlayer
If you've never tested a BitPlayer submission before, you'll need to set up a Testing Curation in the Games tab of Core. In the Games tab, you will need to click the New Game button in the bottom right of the window. The only field you need to fill out is the Application Path, which needs to be FPSoftware\FlashpointSecurePlayer.exe
. You can set any other fields however you want.
When testing a BitPlayer submission, you'll need to copy all of the files in the Content folder and move them into the Legacy/htdocs
folder of Core. You'll then copy the submission's Launch Command and paste it into your Testing Curation's Launch Command field. Then run the submission using the Testing Curation's Play button.
Hyper-G and Hypercosm
Before you can test a Hyper-G or Hypercosm submission, you will need to copy all of the files in the Content folder and move them to Core's Legacy/htdocs
folder. You can then test the submission as normal.
VRML
The majority of VRML submissions can be tested as normal with no special requirements. However, a small number of them will use the Application Path FPSoftware\startVRweb.bat
. Submissions with this Application Path must have all of the files from the Content folder copied and moved to the Legacy/htdocs
folder of Core before testing.