+0x - Plus Symbol Used In Hexadecimal Constant

[OrionSR]

const
    m_nsize = +0x1C
end

The + is used in documentation to indicate a relative offset.
This format works when used as a constant in SB, but the highlighting is lost for the text of the constant.

[x87]

core/src/language_service/scanner.rs

Line 250 in 10101e9

if value.starts_with("0x") || value.starts_with("-0x") {

[x87]

@OrionSR test with this version
core.zip

[OrionSR]

The +0x highlighting is working but other issues have popped up.

The text for all constants in the CONST..END construct is not highlighted unless that line is selected. Eventually it all fills in.

When switching between SCR and SAv1 edit modes, the highlighting for text of constants breaks. The highlighting that was enabled by scrolling over the line is removed when that line is selected.

Update: I'm currently using SB v3.8.0. Just used the upgrade tool. Need to retest.

[OrionSR]

After retesting with a current SB build; the +0x highlighting is working and no new issues are immediately apparent.

I still have problems with larger text scripts. If I edit a line with a constant the highlighting disappears for all constants until I scroll to the const..end construct and edit a line. I suspect this might be resolved by adjusting Sanny's scanning range option but haven't tested the idea. (Never mind, scanning range 1000 fixed this issue.)

For some odd reason, these two constants from ePickupType never highlight.

    PropertyLocked = 17
    PropertyForSale = 18

IIRC, this is expected behavior.

const 
  Font_Pricedown = 0
  Font_Aharoni = 1
  Font_Gothic = 2
  Font_Beckett = 3   
  text_font = Font_Aharoni
end

text_font is not highlighted.

[x87]

Thank you for testing!

For some odd reason, these two constants from ePickupType never highlight.

can you show how you define and use them ?

IIRC, this is expected behavior.

Yes sannybuilder/dev#134

[OrionSR]

can you show how you define and use them ?

Um... Well? I defined them shortly before:

//  tPickupFlags
    UsedPickup = 0
    NoAmmo = 1
    HelpMessageDisplayed = 2
    PickupNearby = 3
    PropertyLocked = 4
    PropertyForSale = 5

Defining the constant twice should break the highlighting. So everything seems to be working properly.

[OrionSR]

Curious: In SB v3.8.5, BREAK is highlighting but CONTINUE is not. Nether is defined in keywords.ini since the update. Both are listed under compiler.ini.

[x87]

add Break & Continue to keywords.ini

[x87]

break is highlighting in SA SCR because of 084C=BREAK

[x87]

@OrionSR could you please test the recursive highlighting with this version?
core.zip

[OrionSR]

Is there anything in particular I should be looking for?
Should I keep scan range at 1000 or drop it back to 250?

[x87]

check your example with text_font = Font_Aharoni.
text_font should now be getting the same coloring as Font_Aharoni. try different types

here is a updated version

core.zip

[x87]

Should I keep scan range at 1000 or drop it back to 250?

you should find an optimal value for scanning range that works best for you.
smaller number is faster but does not highlight constants declared outside of the range
larger is slower but has better results

[OrionSR]

The highlighting seems smoother when loading a large script. It could be that the slower 1000 scan range gives a nice impression when loading. It's difficult to compare the difference though.

Everything seems to be highlighting properly.
Overall, I really like the semantic highlighting. It's an awesome feature.

I've got a couple of scripts that are creeping up on the 1000 line scan limit. When working with the default scan range of 250 I was a bit frustrated with the highlighting disappearing from all constants when I edited any line. I kept jumping to the top of the script to tweak a constant definition to get the highlighting back and then struggling to find my place again without breaking the highlighting. The highlighting serves as an automatic spell check - I miss it when it's not up to date. Have you considered a hotkey to manually refresh the highlighting?

[OrionSR]

text_font should now be getting the same coloring as Font_Aharoni. try different types

I missed this note before - but it wasn't working until the latest core was installed.
Looks good now.

[OrionSR]

Tested the new core.dll with mockups for... chained constants. String and Variable types are highlighting too. I'm assuming the the chains actually work when compiled - they did before; this was only a issue with highlighting.

An observation that... highlights the advantage of highlighting. When I switched to SCR mode some of the R* constants I pulled out of the Dealer.sc script were highlighted as keywords, suggesting a potential conflict.

const
  TASK_STAND_STILL = 1466
  TASK_LOOK_ABOUT = 1481
  TASK_WANDER_STANDARD = 1502
  TASK_FOLLOW_PATH_NODES_TO_COORD = 1525
  TASK_PLAY_ANIM = 1541
  TASK_TURN_CHAR_TO_FACE_CHAR = 1593
end

sa_scr\keywords.txt

05BA=TASK_STAND_STILL
05C9=TASK_LOOK_ABOUT
05DE=TASK_WANDER_STANDARD
05F5=TASK_FOLLOW_PATH_NODES_TO_COORD
0605=TASK_PLAY_ANIM
0639=TASK_TURN_CHAR_TO_FACE_CHAR

I haven't tried using these constants in SCR mode so I'm not sure what will happen. But it will be a little disappointing if I can't use standard R* constants in SCR scripts.

[x87]

TASK_LOOK_ABOUT TASK_LOOK_ABOUT is perfectly fine. First word is the opcode 05C9, the second is the constant 1481

[OrionSR]

Rounding out the easy tests:

Constants defined in constants.txt are highlighting. I thought I read that this didn't work so I'm glad I ran the test.
Constants defined in $Include files are not highlighted - as expected. Not sure how that would work anyway.

This time around I'm trying to avoid modifying Sanny's default configuration files. The strategy inevitably leads to problem when sharing scripts with other players.

I tend to avoid defining constants in $Include files anyway. Highlighting doesn't work, and there's too much risk of conflicts. Instead. I just copy the constants I intend to use and paste them into the scripts header. I might change this strategy if Sanny included standard sets of definitions.

Previous tests suggest that defining large sets of constants in constants.txt can cause a lot of lag in SB. If used conservatively, there are a lot of standard constants that could be defined here, but if everyone doesn't have the same list I don't want to use them.

[x87]

Constants defined in $Include files are not highlighted - as expected.

they should be highlighted. I just checked and it worked for me. Are you sure they are in the scanning range?

Simple test:
c.txt

const
 date=555
end

script.txt

{$CLEO .cs}

{$I c.txt}
0000: NOP 

0001: wait date <-------- highlights as a number and the status bar displays 555

[OrionSR]

they [constants defined in $Include files] should be highlighted

Oh wow! This is so cool. After saving the (Untitled) file Sanny was able to find the path to the $Include file and the highlighting filled in. Now I need to research SB's search path to find the best place to group my enums and constants. Awesome!!!!!

[OrionSR]

alloc ($Extended_Var, 14999)

const
  MyString = "This is the way."
  StringTest = MyString
 
  Temp_Lvar = 0@
  Lvar_Test = Temp_Lvar
 
  Temp_Var = $15000
  Var_Test = Temp_Var

  Test_Alloc = $Extended_Var
  Alloc_Test = Test_Alloc

  ModelID = #SANCHEZ
  TestModel = ModelID 

  HexTest= +0x1C
  Offset = HexTest
 
  Float_Test = 999.9
  MyFloat = Float_Test

  mysubroutine = @DEALIN_1603
  test_subroutine = mysubroutine
end

Everything is highlighting except for "alloc" in alloc ($Extended_Var, 14999).

[OrionSR]

I was going to say that the only thing that didn't quite seem perfect, were the constants highlighted as keywords from SCR mode. The hint text can clearly tell the difference; maybe the scanner could too. But after thinking about it for a while, I made this mockup of a hybrid SA/SCR snippet to see how it looks in practice.

const
  this_ped = 0@
  iTemp = 13@
  FINISHED_TASK = 7
  TASK_LOOK_ABOUT = 1481
end  

062E: get_script_task_status this_ped TASK_LOOK_ABOUT store_to iTemp // ret FINISHED_TASK if not found 
00D6: if 
04A4:   iTemp == FINISHED_TASK // == constant 
004D: goto_if_false @DEALER_1603 
05C9: task_look_about this_ped -1 ms 

Given an example like this, a coder might correctly assume that the appropriate constant to use for the task parameter of 062E has the same name as the keyword for 05C9.

I am not familiar with task commands; are there other commands and constants that show a similar relationship?

I'm thinking, don't change it and call it a feature - Working as Intended.

[x87]

constants highlighted as keywords

it really depends on Coloring Theme. Try other themes, they could highlight them using different colors
https://github.com/sannybuilder/themes#gallery
https://docs.sannybuilder.com/editor/options/editor#color-theme
https://docs.sannybuilder.com/editor/options/theme-editor

[x87]

I am not familiar with task commands; are there other commands and constants that show a similar relationship?

looks like any TASK_XXX opcode can be used in 062E?

			GET_SCRIPT_TASK_STATUS this_ped TASK_STAND_STILL iTemp 		
			IF iTemp = FINISHED_TASK
				TASK_STAND_STILL this_ped -1
			ENDIF

			GET_SCRIPT_TASK_STATUS iOther_Ped TASK_PLAY_ANIM iTemp			
			IF iTemp = FINISHED_TASK
				SET_CHAR_SAY_CONTEXT iOther_Ped	CONTEXT_GLOBAL_DRUGS_BUY iTemp
				TASK_PLAY_ANIM iOther_Ped shop_pay DEALER 4.0 FALSE FALSE FALSE FALSE -1
				++iSubStateStatus
			ENDIF

[OrionSR]

looks like any TASK_XXX opcode can be used in 062E?

A bit of a tangent but... I've been searching in vain through the SA source files, looking for enums or constant definitions for the tasks, and finally figured out the easy trick - converting the constants to hex with Ctrl-H.

const
  TASK_STAND_STILL = 0x05BA
  TASK_LOOK_ABOUT = 0x05C9
  TASK_WANDER_STANDARD = 0x05DE
  TASK_FOLLOW_PATH_NODES_TO_COORD = 0x05F5
  TASK_PLAY_ANIM = 0x0605
  TASK_TURN_CHAR_TO_FACE_CHAR = 0x0639
end

sa_scr\keywords.txt

05BA=TASK_STAND_STILL
05C9=TASK_LOOK_ABOUT
05DE=TASK_WANDER_STANDARD
05F5=TASK_FOLLOW_PATH_NODES_TO_COORD
0605=TASK_PLAY_ANIM
0639=TASK_TURN_CHAR_TO_FACE_CHAR

The task ID is the same as the associated opcode number.