ayecue / greybel-js Goto Github PK

Dear Developer(s),
I recently build something in gs and came across this bug :
if I have an object with an List in an attribute and check if it is the same as an List that should have the same value.
Ingame it tells me they are the same but the interpreter thats also used in your vscode extension tells something different.
My code can be found in the attachments section
ArrayBufferBug.txt

It would be great to have a support for MiniScipt files too.

Grey Script is based on MiniScript, and as far as I'm aware, it has no differences compared to the 2021 version of MiniScript.

A simple change would be to include the extension to cover .ms files, but ideally, some changes to autocompletion are needed to make the extension not to suggest GreyHack-only APIs

While using this tool, I have noticed that the name of the outputted build folder is always "build" and cannot be customized by regular means (i.e. through command options), as a result, I was wondering if a new CLI option could be added to modify the name of the outputted build folder?

Currently import assertions is used even though not supported by node 16.13. It's used within all bin files:

• https://github.com/ayecue/greybel-js/blob/master/bin/compile.js#L8
• https://github.com/ayecue/greybel-js/blob/master/bin/execute.js#L8
• https://github.com/ayecue/greybel-js/blob/master/bin/repl.js#L8
• https://github.com/ayecue/greybel-js/blob/master/bin/ui.js#L8

As a solution either the required node version should be increased to the latest lts or the assert should be removed.

This is a feature request.

It would be nice to not only sync the compiled src but also compile it and remove the src to prevent accidentally leak the src.
This would result in a realtime sync of the tool without manual build and rm of the src.

By e. g. either use the ShellIntrinsic "build" or PlayerServerMethods "BuildScriptServerRpc" when --instlal & --auto-compile flag is giving to the greybel compiler which then should use the installer*.src

Bonus perfect would be to rm the src after successful build.

Currently, the name of the outputted executable file is dependent on the name of the entrypoint source code file.

Is it alright if an additional CLI option (that could be called something like --executable-name or --program-name) could be added that would allow the user to specify the name of the executable file that would be outputted either after auto-compilation or after running the generated installer script in Grey Hack?

In one of my Greyscript projects, I have a folder/file structure that looks like so:

my-greyscript-project
- src
  - main.src
  - helpers
    - enum-helpers.src

It should be noted that in this case, the main.src file imports the enum-helpers.src file (which is located in the helpers folder).

The issue is that when enabling auto compilation using the --auto-compile option, although the main.src and enum-helpers.src files are deleted after the auto-compilation process has been completed, the helpers folder is not deleted from the specified in-game output folder.

However, I was anticipating that the helpers folder would also be deleted from the specified in-game output folder (just like the main.src and enum-helpers.src files had been deleted after the auto-compilation process had been completed).

If necessary, I can provide further elaborations and details regarding this issue.

When using the sync it always works, but sometimes spawn an Terminal window which is unusable:

mtx@nop:~$ s
unknown error: can't find remote process
mtx@nop:~$ ls
unknown error: can't find remote process

While using this tool, I have noticed that when building the files, the result (i.e. resulting files) of the build are outputted into a folder called "build" which is then stored in the output folder located at the path specified by the output argument.

As a result, I was wondering if the behavior of this tool could be updated such that the result (i.e. resulting files) of the build would be directly outputted into the output folder located at the path specified by the output argument?

If necessary, I can provide further elaborations and details regarding this feature request.

Introduced with 6321b55

Description

Any interaction in regards of user key press or loading bar doesn't seem to work with gitbash on win10.

Priority

Low Priority since the features are still usable.

Tests

Tested on Mac:

• seems to work fine

Tested on Win10:

• gitbash seems to have issues with TTY
• seems to be connected to the emulated environment

Suggested workaround

• clone project and execute bin commands via node
• use PowerShell or ConEmu

Can I request the option when pressing F7 to build that it saves before doing the build?

Problem
When declaring a new function like below, the compiler throws an error.

Steps to reproduce
rng = function (start, end = 0, increment = null) return range(start, end - 1, increment) end function

Unexpected parameter in function declaration at line 1.

Observations
I tested a bit further and apparently the arguments names are the problem, apparently they are considered as a keyword or something internally?

Apparently it's the name end that bothers the compiler, as it's used to define a code block end.

It would be great to be able to import code like import_code('~/some/path') with a symbol like ~ or using / in the first character to get the root path of the project so I don't have to be looking backwards with double dots, also it would be great if it could be configured like using ~ for root path and @ to import from, for example, a vendor folder.

Here is the command that I ran as well as the output from greybel-js after attempting to build my Greyscript project using it:

greybel --auto-compile-name program --disable-build-folder --auto-compile-purge --create-ingame-mode "local" --create-ingame --installer --auto-compile --ingame-directory "/usr/bin" "./src/program.src" "./build"

Creating installer.
Importing files ingame.
Trying to connect to 127.0.0.1:21200 (attempt: 0)
Imported /program.src successful
Imported /helpers/enum-helpers.src successful
Imported /command.src successful
Imported /helpers/string-helpers.src successful
Imported /command-factory.src successful
Build done in /usr/bin
Delete pre-existing program done!
Renaming failed! Reason: /usr/bin/program not found
Deleted /usr/bin/program.src
Deleted /usr/bin/helpers/enum-helpers.src
Deleted /usr/bin/command.src
Deleted /usr/bin/helpers/string-helpers.src
Deleted /usr/bin/command-factory.src
Deleted /usr/bin/helpers
5 files got imported to /usr/bin!
Build done. Available in C:\Users\Arcane\Dev\Greyscript-Projects\GS-Program\build.

When checking my GH computer after the auto-compilation process was completed, I did not find an executable file called program in my /usr/bin folder. I was expecting that such a file would be created as a result of the auto-compilation process.

If necessary, I can provide further details regarding this issue, do let me know if that is indeed the case.

I use mocking for my unit tests (code here if you're interested) and in certain tests, I override global functions.

For example, if I want to override include_lib then I instantiate a new Mock class, tell it to define the key/value pair and then assign the funcRef into globals.include_lib. After the test is completed, I remove the key from globals to restore the environment state to normalcy.

This works absolutely fine when I run my tests inside GreyHack. However, when using the debugger bundled with the VSCode extension, the class under test (which is in a different, included file) does not see the new global.

Hey

tried to get envar working with:
greybel --env-vars=random=bla src/cmd.src .
and also by using env files:
greybel src/cmd.src . -ev local.conf

local.conf

# MY COMMENT
random=SOME_VALUE

cmd.src

...
somevar = #envar random;
...

Build result

globals.H=globals
MODULES={}
EXPORTED={}
__REQUIRE=function(r)
if not MODULES.hasIndex(r) then
exit((("Module " + r) + " cannot be found..."))
end if
module=MODULES[r]
return @module(r).exports
end function
MAIN=function()
ENV={}
somevar=null
print("\x90     ")
print("\x90     n0p")
print("\x90     ")
print(somevar)
end function
MAIN()

Any idea why that is only return "null" on build?

Right now I can only see that files get created with the correct content.
I was wondering why there is no feature to also "compile them right away".
This can prevent leaving the lib src code on the machine.

Is this a limitation due to multiple installer files when having too much code? Or did I just not see the option? ;-)

It might just take an additional parameter which enhances the installer with

• compile the created files build(src, dest)
• delete the created files

Shouldn't be much of an effort.
After that one could compile the installer, run it and remove the installer - everything was already compiled and is ready to be used.

Hi @ayecue Im trying to use this feature like this: print("<color=red>Text message")
And it gives me this output: <undefined>Text message</undefined>
The same happens with the other TextMesh Pro supported features

There is a misbehavior in the builtin range function, where:

• In greybel-js, it considers the end parameter as excluded
• In the actual game, it considers the end parameter as included

Snippet to check:
print(range(0, 4))

In greybel-repl (or greybel-execute) it will output [0, 1, 2, 3], whereas in the game it will output [0, 1, 2, 3, 4].

Description

If a line is longer than maxChars allowed in installer an infinite amount of installer files gets created unless the script gets forcefully stopped.

Todo

• change approach on how installer files get generated to not depend on new line

Hey, I really like this project and the game. After quite some time I revisit the tools as I want to play some grey hack soon with the right tools to not freak out with the ingame editor.

As you now seem to have a solution to save changes from outside directly in the game I was wondering how you did that.

It seems that you're using a self-written library currently called greybel-proxy which is obfuscated and not open source.

Please don't get my followup question wrong. I don't want to blame you or anything. Everybody can decide for themself if they trust it or not.
But as a hobby security researcher I was wondering what the obfuscated code actually is doing.

My assumptions is:

• Steam Storage manipulation to change the savegame? Not in an evil way. Just wondering where else it would be stored.

I would like to ask if you could ellobrate some more info's what the package is doing, as there is obviously a network connection and you ask for some kind of steam credentials. (did not try, only what I read)

Again. Awesome project. Thanks!

EDIT:

Just tried this feature.
It destroyed my local savegame.
When trying the public one, it worked but logged me out and I have to login back again.

Is that how it should work?

Best
Steven

User reported: greybel-js doesn't work correctly with node version 16.10

I advise to use 14.17.0 for now.