Add new syntax

[XMDS]

Before that, I foundxxxx()When WRITE_OPCODES is turned on, this grammar will not be decompiled to OP0050, and it remains the same.In addition, I think the SB tool should default WRITE_OPCODES to be on.

Back to the topic, about the grammar when writing. There are usually these types:

1. OP syntax (ID+English descriptor)
   This kind of grammar is our most commonly used grammar. When we need a certain function, open the OP search bar to search for ID or a certain word to determine the operation code we need, and then copy and paste.OP grammar causes many writers to memorize certain opcodes by ID or words, and it is the most widely used. But it is not convenient and suitable for programming

2.Class syntax（classes.db）
Because we did not update the classes.db file with this syntax, only a small amount of code can be used.
This kind of syntax is actually very good. I don't have many languages. I think this kind of syntax is like functions in C and JavaScript. But updating the classes.db file is a long-term problem, and this syntax is not suitable for all opcodes. We can use ‘player’, ‘actor’, ‘vehicle’, ‘object’, etc. as class names, but some special opcodes, such as those for setting game parameter environment and other data, are not very good to classify and set a group of class names. And the parameters in the brackets of this syntax (parameters) are not very friendly to beginners, they don't necessarily know how many parameters this opcode has and what the parameter types are.

3.Keyword(gta3sc)
This is the original syntax of this scripting language. I still don't understand that SASCR mode uses this syntax, but what is the meaning of the keyword file in normal mode, I don't think anyone will use this syntax in normal mode. In addition, OP files in SCR mode are actually more confusing. Even though this grammar still requires the writer to be familiar with the parameters of each command, more people will use gta3sc to expand and write cleo with vscode, because the writing environment and mode of vscode are very good. In addition, I don't know if SB's SCR mode will fully support this syntax, such as "if end_if". In short, the current SCR model is very confusing, I prefer vscode.

The above. Now when writing CLEO, the grammar is actually a mixture of OP grammar + class grammar, which is actually very messy. . .

@x87 I remember I discussed keywords with you before. Currently, due to the updated keyword file, the same English words in the OP grammar will also be highlighted due to keyword highlighting. This is actually uncomfortable. In addition, after the const of 3.7.0 is highlighted, it will be more uncomfortable to mix up. I think that in normal mode, classes (classes.db) and keywords should be combined to update a new syntax, and When in use, the keywords are highlighted. Otherwise in normal mode There is no point in updating keywords. Of course this is just my suggestion. In addition to discussing grammar, I also want to add some abbreviated grammars of basic opcodes.

[XMDS]

@x87 About opcode abbreviations:
#45
There was a function syntax here before. I think the abbreviation of the basic OP should be independent, rather than still placed in the keyword file:

03A4: script_name 'xxxx'
thread 'xxxx'
script 'xxxx'

0000:
nop

0002: jump @MAIN_177
jump 
goto

004E: terminate_this_script
end_thread
end_script

if
gosub 
reture

These are some commonly used abbreviations for opcodes. But some need to be added, and CLEO4 also added some:

0485:   pc_version
return_true
059A:   australian_game
return_false

0A93: terminate_this_custom_script
end_cleo_script

0AB1: cleo_call @GetSQR 1 10 $result
0AB2: cleo_return 1 0@

cleo_call
ret

The above are just some examples

In addition, some OPs should also have a syntax supported by compilers similar to "xxxx()":

0079: 351@ += frame_delta_time * -1.325 // (float)
007F: 421@ -= frame_delta_time * 1.0 // (float)
0092: 22@ = float 17@ to_integer
0093: 14@ = integer 13@ to_float
0095: make 9@ absolute_integer
0097: make 196@ absolute_float
0098: 0@ = random_float_in_ranges_0.0_to_1.0
0099: $8224 = random_int_in_ranges_0_to_32767
08B7:   test 54@ bit 5
08BD: set 54@ bit 10
08C2: clear $391 bit 3@
.................

The above OP is still only a part, and this type of OP is not suitable to be created as a class syntax. We need more flexible abbreviations.

[x87]

@XMDS You've made some very good points here. I agree, the mixture of opcodes/keywords/classes is kinda messy and confusing, but this is also something that makes this language very unique and flexible. I agree with the point that some operations are hard to classify (as in literally turn into a class) and very few keywords should exist. I started outlining Sanny Classes Library recently where I try to make consistent names to all known opcodes:
https://github.com/sannybuilder/dev/wiki/Sanny-Classes-Library

In this classification only some opcodes can be expressed with keywords. Only those that are part of the scripting system (jump, wait, return, etc). The rest is being converted into a Class.Member form.

I absolutely agree that mathematical operations should be free to use without opcodes and this is where we move towards. A new expression parser is under development and I plan to introduce it with bitwise operations (#97) first and then expand on other opcodes you mentioned.

[wmysterio]

@x87 Hm, if SB contains suffix/prefix for strings, maybe need add suffix/prefix to others base datatype (int, float)?

0@i        +=   $XXXX  // 005C: 0@ += $XXXX // (int)
0@i        +=   1@     // 005A: 0@ += 1@  // (int)
i$XXXX     +=   0@     // 005E: $XXXX += 0@  // (int)
i$XXXX     +=   $XXXX  // 0058: $XXXX += $XXXX // (int)

0@f        +=   $XXXX  // 005D: 0@ += $XXXX  // (float)
0@f        +=   1@     // 005B: 0@ += 1@  // (float)
f$XXXX     +=   0@     // 005F: $XXXX += 0@  // (float)
f$XXXX     +=   $XXXX  // 0059: $XXXX += $XXXX // (float)

The opportunity is situational, but it can be useful.

[x87]

@wmysterio I see your point here. It could be useful in some cases if one prefers low-level syntax with granular control over data types. Ideally I would like people to use shorter variable declaration #32 but I do agree that having suffixes/prefixes for string variables only makes the grammar inconsistent. In other words, we do have s$var and v$var but why can't we have i$var and f$var (same for locals).

I will look into adding support for i/f types. It will be low priority though.

[wmysterio]

@x87 I know this is of low priority, which is why I wrote "situational". Suffixes/prefixes are useful in places like the for loop:

for 0@i = 1@/*[i]*/ to 2@/*[i]*/
// ...
end

I write now:

int 0@
for 0@ = 1@ to 2@
// ...
end

But I preferred to get rid of the first line :)

[x87]

Oh, in this case it would be much better to support:

for int 0@ = 1@ to 2@
// ...
end

[wmysterio]

Looks better than the current version. This syntax is definitely worth adding.

I didn't find an obvious use of prefixes/suffixes for integers and float numbers, so I wrote the first thing that came to mind))

[XMDS]

@x87 Hm, if SB contains suffix/prefix for strings, maybe need add suffix/prefix to others base datatype (int, float)?

0@i        +=   $XXXX  // 005C: 0@ += $XXXX // (int)
0@i        +=   1@     // 005A: 0@ += 1@  // (int)
i$XXXX     +=   0@     // 005E: $XXXX += 0@  // (int)
i$XXXX     +=   $XXXX  // 0058: $XXXX += $XXXX // (int)

0@f        +=   $XXXX  // 005D: 0@ += $XXXX  // (float)
0@f        +=   1@     // 005B: 0@ += 1@  // (float)
f$XXXX     +=   0@     // 005F: $XXXX += 0@  // (float)
f$XXXX     +=   $XXXX  // 0059: $XXXX += $XXXX // (float)

The opportunity is situational, but it can be useful.

In fact, I think this kind of abbreviation is not good, because there are so many symbols.

In addition, I have a question:

int 0@ 
int 1@
0@ += 1@

and

int 1@
int 0@ += 1@ 

@x87 Why both variables need to be declared? I think it seems to be enough to declare the previous variable
Instead of:

int 0@ += 1@

[wmysterio]

@XMDS In fact, I think this kind of abbreviation is not good, because there are so many symbols.

In fact, I think such abbreviations are appropriate because the number of characters is will reduced here.

int 0@ += 1@// 12 symbols
0@i += 1@//     9 symbols

I am in favor of both options.

[XMDS]

https://github.com/sannybuilder/dev/wiki/Sanny-Classes-Library

In this classification only some opcodes can be expressed with keywords. Only those that are part of the scripting system (jump, wait, return, etc). The rest is being converted into a Class.Member form.

I absolutely agree that mathematical operations should be free to use without opcodes and this is where we move towards. A new expression parser is under development and I plan to introduce it with bitwise operations (#97) first and then expand on other opcodes you mentioned.

Now according to your instructions, I roughly summarize the construction of a grammar
First of all, start with decompilation. I think the decompiled syntax should be displayed as OP syntax, then I think the tool should default write_opcodes to be on (now off by default). (The reason why I think it is enabled by default is that OP syntax is easier for beginners to understand) In addition, xxxx() is not correctly decompiled to 0050 when write_opcodes is on. This needs to be fixed.

Then the grammar at the time of writing:
There are two modes (normal mode and SCR mode):

1. SCR mode
   Currently only SASCR mode is available, and SCR mode can be added for VC and GTA3 later. The writing syntax of SCR mode is the original syntax of GTA3sc. However, the syntax of the current SASCR mode is messy, and it is not fully supported. In fact, we should extend the alignment to vscode's gta3sc (such as end_if). The current SCR mode does not support it. In addition, the highlight of each named code in the SCR mode is not It should be determined by the keyword file, it should exist as a separate "gta3sc.txt" file, and let the compiler support highlighting. As you said, the keyword file should be the basic cleo structure (jump wait Nop ret), and the basic OP is very suitable for this abbreviation. In addition, SCR mode does not require OP grammar and class grammar, it just exists as a primitive grammar gta3sc. Of course, the syntax during decompilation depends on the write_opcodes option, which is displayed as OP syntax when it is turned on, and gta3sc syntax when it is turned off.

2. Normal mode.
   The OP syntax should certainly exist. (Very friendly to beginners, there should be an English word before each parameter to describe the meaning of the parameter.)

But the normal mode requires a formal and stable grammar that is conducive to programming, that is, the class grammar.
We need to update the class syntax for all OPs to support all game modes except SCR mode. For basic OP (wait jump ret, etc.), no class syntax is needed, we still use keywords. For mathematical calculations, variable assignments, bit operations, etc., we also don't need class syntax. We use a simple signed abbreviation syntax supported by a specific compiler. At the same time, the normal mode does not require gta3sc syntax.
The keyword file exists as the abbreviation of the base OP. There is no need to add gta3sc keywords in normal mode.

@x87 Are future grammar updates and patterns roughly what I said? In addition, your grammar tables are currently too few, maybe you can share them and update them together (in fact, I don't like markdown to make such a long table. Or it would be better to write on gtawiki). We need a stable version of the SB tool to write cleo in class syntax. Which version do you plan to implement class syntax updates in the future?

[x87]

@XMDS Yes, you've described pretty much everything. I'm not going to spend much time on improving SCR mode, I think there are better tools out there for this. My primary focus would be on Sanny Classes Library. I don't know how much time it takes to complete. I plan to gradually roll out classes starting with GTA3 first, then VC and so on.

[XMDS]

@XMDS Yes, you've described pretty much everything. I'm not going to spend much time on improving SCR mode, I think there are better tools out there for this. My primary focus would be on Sanny Classes Library. I don't know how much time it takes to complete. I plan to gradually roll out classes starting with GTA3 first, then VC and so on.

I very much agree to build the class library first. It does take a long time to perfect. But I think you should make a world or excel table, or create a table file or markdown file in the git repository. In other words, I think wiki forms are not suitable for viewing. And it is not suitable for multiple people to participate.

[x87]

I wanted to create a separate repo for classes work when I finish first round of converting commands to classes. Do you wish to help me in converting the remaining items?

[XMDS]

I wanted to create a separate repo for classes work when I finish first round of converting commands to classes. Do you wish to help me in converting the remaining items?

Yes. If I have free time, I will participate.

[x87]

Moved current wiki page into a separate repo
https://github.com/sannybuilder/classes

This is very raw and subject to change at any moment

It's also viewable at https://sannybuilder.github.io/classes

[x87]

Update on the classes library 1/18/2021

Classification of GTA III commands is complete. See it there https://sannybuilder.github.io/classes/gta3/index.html
It's time to start naming command input and output arguments.

GTA Vice City command classification is in progress. Everything starting from the command SET_CHAR_CEASE_ATTACK_TIMER is new and needs a proper class name.

[x87]

As usual, any feedback, comments and help are very welcome and highly appreciated 👍

[x87]

Update 3/26/2021

The library has been massively updated and got many new features.
New web url: https://library.sannybuilder.com

I have created a new discussion, so please share your ideas and comment here: #136