---
metadata:
- name: generator
content: Diplodoc Platform v5.48.2
alternate:
- https://admin.contest.yandex.ru/docs/en/problem/main-problem.md
- https://admin.contest.yandex.ru/docs/ru/problem/main-problem.md
---
> **Documentation Index:** Fetch the complete configuration index at https://admin.contest.yandex.ru/docs/en/llms.txt
# Settings
To create a problem:
1. Go to [Problems](https://admin.contest.yandex.ru/problems/) and click **Create problem**.
2. Enter a name and click **Create**. The name will be displayed in the participant interface.
A page with the problem settings will open.
## General {#common}
#### Short name of a problem
A short name makes searching for a problem in the list faster.
#### Name
This is the name that participants see. You can specify names in Russian and English.
#### Problem type {#type}
You can create different types of problems in Yandex Contest.
1. Programming problems:
- **PROBLEM_WITH_CHECKER**: Standard programming problems. The system runs the code from the participant's solution and feeds the test data to the user's program as input. The received answer is compared with the reference answer specified in the system.
- **INTERACTIVE_PROBLEM**: Interactive problems. In addition to the problem text and tests, you need to prepare a special interactor program. The system first runs this program, then feeds the data it receives to the participant solution's input, receives the answer, and feeds it back to the interactor.
2. Problems where the answer must be specified in the `` field:
- **TEST_PROBLEM**: A problem for which the participant needs to choose one or more options from a list of suggestions.
- **TEXT_ANSWER_PROBLEM**: A problem for which the participant needs to enter their answer in a text field.
- **PROBLEM_WITH_MATCH_SETS**: A problem for which the participant needs to match horizontal and vertical options.
3. Problems checked via GitLab and Jupyter:
- **GITLAB_PROBLEM**: Checking runs through GitLab. On the **GitLab repositories** tab, use **Answer field** to choose how participants submit solutions: a personal repository or the code editor or file upload (verified in CI). You cannot change **Answer field** after repositories are created.
- **JUPYTER_PROBLEM**: The participant solves the problem in JupyterLab; the organizer configures JupyterHub and the environment, while the repository and checks are tied to GitLab according to the problem settings. In one contest, all Jupyter problems must use the same GitLab instance.
{% note info %}
**GITLAB_PROBLEM** and **JUPYTER_PROBLEM** are available to a limited set of administrators. To request access, use [Support](https://admin.contest.yandex.ru/docs/en/troubleshooting.md).
{% endnote %}
#### Problemsets with this problem
This field is only visible if the problem is added to a [problemset](https://admin.contest.yandex.ru/docs/en/problem-set/settings.md).
#### Use code template {#use-code-template}
Add a template for participants' code.
#### Use an alternative renderer for statements and correct answers
This setting is used for conditions and solution comments in TeX format.
If an **Alternative renderer** is used, an extended list of KaTeX language instructions is available, and an HTML file is created after generation. Such statements can be copied and selected.
If an alternative renderer is not used, an image is created in an HTML file when generating a TeX construct. Such statement can't be copied as text. The list of available TeX language constructs is limited. For more information, see [problem statement descriptions](https://admin.contest.yandex.ru/docs/en/problem/statements.md).
Other settings depend on the selected problem type.
## File settings {#file-settings}
{% note alert %}
Only for **PROBLEM_WITH_CHECKER** and **INTERACTIVE_PROBLEM** type problems.
{% endnote %}
Configure settings that affect the behavior of the user's program and its interaction with tests.
#### Name of input file
The name of the file that is fed to the program as input. By default, this is `input.txt`.
#### Name of output file
The name of the file that is submitted to the program output. By default, this is `output.txt`.
#### Allow reading from stdin
This setting allows the user's program to read data from **stdin**. It's enabled by default.
#### Allow writing to stdout
This setting allows the user's program to write data to **stdout**. It's enabled by default.
#### Allow creation of files
This setting allows the program to create new files in the Yandex Contest file system. It's disabled by default.
#### Test's file type
This is the expected type of tests' files that are fed to participant's program as input. There are two options:
- **TEXT**: Text files. It's selected by default.
- **BINARY**: Binary files like images and ZIP archives.
#### Source code size limit
This is the limit for the size of the user's program. By default, it's 256 KB. If the limit is exceeded, the participant sees an error notification saying Source code size limit exceeded.
## Runtime limits {#run-settings}
{% note alert %}
Only for **PROBLEM_WITH_CHECKER** and **INTERACTIVE_PROBLEM** type problems.
{% endnote %}
Set the limits that the participant's program must comply with. The limits are valid for one program run for one test.
{% note info %}
For most contests and problems, default settings are sufficient. If the limits you set are too strict, Yandex Contest may be unstable and it may take a long time to check participants' solutions.
{% endnote %}
#### Time limit
This is the maximum time to completely check problems. If it is exceeded, the participant receives a TL (_time limit exceeded_) verdict. By default, it's 1 second.
#### Wait time limit
This is the maximum wait time for the program to output data. If it is exceeded, the participant receives an IL (_idleness limit exceeded_) verdict. By default, it's 10 seconds.
#### Memory limit
This is the maximum amount of RAM that the participant's program can use. If it is exceeded, the participant receives an ML (_memory limit exceeded_) verdict. By default, it's 64 MB.
#### Output limit
This is the maximum amount of data output by the participant's program. If it is exceeded, the participant receives an OL (_output limit exceeded_) verdict. By default, it's 64 MB.
#### Add custom limits
You can set custom runtime limits for a specific compiler:
1. Enable the **Add custom limits** option.
2. Select a compiler from the list and click **Add**.
3. Set limits. The set is the same as the problem runtime limits.
## Compilation limits {#compilation-settings}
{% note alert %}
Only for **PROBLEM_WITH_CHECKER** and **INTERACTIVE_PROBLEM**.
{% endnote %}
Set the limits that the participant's program must comply with at the compilation stage. The limits are the same as the [problem runtime limits](#run-settings).
## Checker settings {#checker-settings}
A **checker** is a program that checks answers received after executing a participant's program. The checker receives the reference answer and the participant's answer as input.
Open the problem and select **Checker settings** in the menu on the left.
#### Checker type
The following checker types may be used to perform checks:
- **STANDART_CHECKER**: A standard checker. It's selected by default.
- **EJUDGE_EXITCODE_CHECKER**: You upload your own checker program which operates the [Ejudge](https://ejudge.ru/wiki/index.php/Serve.cfg:problem:scoring_checker) system return codes (source in Russian).
- **TESTLIB_EXITCODE_CHECKER**: You download your own checker program which operates the [testlib](https://github.com/MikeMirzayanov/testlib) library return codes.
#### Other checker settings
You can also:
- Select the checker ID from the standard programs (for **STANDART_CHECKER**).
- Configure sending points.
- Add checker files.
See [Checkers](https://admin.contest.yandex.ru/docs/en/problem/checkers.md).
## Additional files and processing {#checker-settings_1}
#### Runtime files
Select the files that are copied to the root directory when launching the program.
#### Files to compile
Select the files that are copied to the root directory when compiling the participant's program.
#### Files for postprocessing
Select the file with the postprocessor program. A **postprocessor** is a program that runs after all problem checking is completed. The postprocessor receives the entire test log as input and interprets it into a final verdict or score, which is returned to the participant.
You can view examples of available postprocessors in [our Yandex Disk](https://yadi.sk/d/oJw8JNqc3ELf6e). Have a look at the file `postprocessor.py`, which is used together with `scoring.json`. This is the most common way to use postprocessors, with points for solving problems awarded based on the solved test groups.
Write to Support