As your gamemodes and scripts grow, you'll probably reuse functionality across them, or you just want to split up huge files. Having the ability to reference/import files will give us the ability to re-use code and splitup codebases into smaller and easier to manage files.
In my Upgrade Shop script I have many sections of code. If I could have a parent owpy file that just imports a variety of modules in, then I could make the code easier to navigate and manage.
Execution / Development
Ideally, what I think would logically happen is that prior to transpiling the script, it just essentially reads the lines and pretty much "pastes" them into the current input right where it's imported. So it still acts, essentially, one huge file, but from the development side it's not.
I could see one major issue being people importing incorrectly. So they import a file in after the function is needed so you get the standard error saying the function is not defined.
Another one could be for bigger games, compiling could take longer as every file it copies the code and pastes it. Reference below for possible solution
Compiling with Imports
I think by default, it should not use imports. I think this should be an optional flag added to the CLI. The flag could be: --enable-imports or something along the lines and then it can show a warning saying something like:
WARNING: Using imports could cause longer waits for code compilation. Please be patient.
The reality is, smaller projects wouldn't use this anyway and would be mainly for bigger gamemodes and scripts. So longer time to compile really wouldn't be THAT big of an issue.
Example Usage
File: lib/functions.owpy
%CreateEffect(pos, type, color)
Create Effect
Visible_To: Everyone
Type: type
Color: color
Position: pos
Radius: 1.5
Reevaluation: Visible To
File src/setup.owpy
Rule "Setup Effects"
Event
On Global
Actions
CreateEffect(<0,0,0>, Ring, Red)
File: src/game.owpy
#import 'lib/functions'
#import 'src/setup'
The output of which, prior to transpiling to Workshop code, would look like:
%CreateEffect(pos, type, color)
Create Effect
Visible_To: Everyone
Type: type
Color: color
Position: pos
Radius: 1.5
Reevaluation: Visible To
Rule "Setup Effects"
Event
On Global
Actions
CreateEffect(<0,0,0>, Ring, Red)
Then it would proceed to being transpiled like normal.
Why #import?
I decided to propose #import to ensure no clashing with any other converting and to set the OWScript specific stuff apart from general. This way of importing is actually used in C++ and is still close to Python's style of importing as well. It should be easy to parse and easy to handle.
Importing another import within an import.
I think this should be discouraged at all costs. We're not node_modules and there's no need for it to be.
While I understand that you may want to import from other files within the import...since we're essentially copying and pasting code, all you have to do is make sure another file is listed above yours, not import it in.
So to go into more detail....
Why?
As your gamemodes and scripts grow, you'll probably reuse functionality across them, or you just want to split up huge files. Having the ability to reference/import files will give us the ability to re-use code and splitup codebases into smaller and easier to manage files.
In my Upgrade Shop script I have many sections of code. If I could have a parent owpy file that just imports a variety of modules in, then I could make the code easier to navigate and manage.
Execution / Development
Ideally, what I think would logically happen is that prior to transpiling the script, it just essentially reads the lines and pretty much "pastes" them into the current input right where it's imported. So it still acts, essentially, one huge file, but from the development side it's not.
Could be added at the top level: https://github.com/adapap/OWScript/blob/master/OWScript.py#L54 We could also create another file called
OWScript/Importer.pyand handle it all there. Not really sure. Up to you.Possible issues
I could see one major issue being people importing incorrectly. So they import a file in after the function is needed so you get the standard error saying the function is not defined.
Another one could be for bigger games, compiling could take longer as every file it copies the code and pastes it. Reference below for possible solution
Compiling with Imports
I think by default, it should not use imports. I think this should be an optional flag added to the CLI. The flag could be:
--enable-importsor something along the lines and then it can show a warning saying something like:The reality is, smaller projects wouldn't use this anyway and would be mainly for bigger gamemodes and scripts. So longer time to compile really wouldn't be THAT big of an issue.
Example Usage
File:
lib/functions.owpyFile
src/setup.owpyFile:
src/game.owpyThe output of which, prior to transpiling to Workshop code, would look like:
Then it would proceed to being transpiled like normal.
Why
#import?I decided to propose
#importto ensure no clashing with any other converting and to set the OWScript specific stuff apart from general. This way of importing is actually used in C++ and is still close to Python's style of importing as well. It should be easy to parse and easy to handle.Importing another import within an import.
I think this should be discouraged at all costs. We're not
node_modulesand there's no need for it to be. While I understand that you may want to import from other files within the import...since we're essentially copying and pasting code, all you have to do is make sure another file is listed above yours, not import it in.