Autocomplete list should display constants anywhere

[x87]

• currently constants are only displaying when the list is called on a standalone statement, not within an opcode. Contansts are applicable anywhere and therefore the list should get a general availability.

• Constants defined in constants.txt are not included on the list.

• another note: list of values for an "extended" param (enum) should not include functions (currently it does).

• should display user-defined constants (const..end)

[OrionSR]

Ah, got it working finally. Needs a standalone line and the constants must be defined in the script. Constants defined in constants.txt are not included on the list.

Constants are not yet included with the Ctrl+Space documentation under Hotkeys.

Syntax highlighting for constants would be nice to have. Then you know you've spelled it right.

I've been modifying the descriptors of constants with proper case and a trailing underscore to prompt the user towards a filtered list. For example;

{$CLEO .cs}
const
 Switchstyle_Smooth = 1
 Switchstyle_Jumpcut = 2
end // const

0000: NOP 
0160: point_camera_at_point 885.25 -305.8125 13.0 Switchstyle_ 1 
05DC: terminate_this_custom_script 
/*
Switchstyle_
*/

[x87]

Syntax highlighting for constants would be nice to have. Then you know you've spelled it right.

#28

constants with proper case and a trailing underscore

those are essentially enums #20

Constants defined in constants.txt are not included on the list.

constants.txt had been implemented recently and not integrated with the autocomplete feature yet. makes sense to correct this.

Constants are not yet included with the Ctrl+Space documentation under Hotkeys.

not sure if that documentation should be exhaustive, as autocomplete is very context-sensitive and would be tedious to list all use cases. maybe need to rewrite to something more general

[x87]

another note: list of values for an "extended" param (enum) should not include functions (currently it does).

[OrionSR]

How are you defining the difference between Constants and Enums? My initial lists only included stuff that was defined as constants by constant specific opcodes. But the use of constants isn't terribly consistent in the scripts. The only thing that seemed defined completely within the script (SA) and not dependent on outside resources is, iirc, Town Number.

I'm dropping the proper case for descriptors of Enums/Constants. It just looks funny.

[x87]

Constant is an immutable named value. Example: True=1, False=0, Pi=3.1415. Constants represent values in a human-friendly form, so you don't need to remember them.

Enums are scoped constants i.e. a group of constants under a common prefix. Example: you can group town numbers in one enum Town and enumerate possible values:

enum Town
LS = 0
SF = 1,
LV = 2
end

then you could use Town.SF to substitute 1 in a script.

Enums and constants are usually interchangeable, so one can define const Town_SF = 1 and use it, but enums have more advantages. First, you logically group related values, second you don't pollute the global scope with many constant names (imagine 1000+ AudioEvents constants list), and lastly if the compiler is capable to do so, you can define an opcode parameter as having a type of enum and so you can only assign values from that enum, not any arbitrary numbers.

016C: restart_if_wasted_at 2027.77 -1420.52 15.99 angle 137.0 town_number False // this would throw an error if town_number has the type of Town even though False represent a valid number of 0.

[x87]

"Extended" params defined with Sanny classes are also enums, but they don't have the scope name (15 years ago I had to invent many things on my own 🤷‍♂️)

[OrionSR]

This is nice, Sanny doesn't protest about trailing periods in descriptors like it does for constants. Will enums decompile the same way that constants do now?

I don't need to imagine. I converted 7000+ sounds from audioevents.txt to constants. It worked, but Sanny wasn't happy about it and took forever to managed the list.