A new TESH Syntax Highlighter for Warcraft 3

KILLCIDE · Mar 27, 2017

My god that looks beautiful. Great stuff, lfh. Hoping @MindWorX can also include this to his JNGP.

Ruke · Mar 27, 2017

Excellent work man, four suggestions:

1 - Allow to search fonts
2 - Allow to change font line space
3 - Allow to export/import config (want to install my theme?, here)
4 - Allow to list & change (installed?) themes/configs

MyPad · Mar 27, 2017

moyackx said:
It looks like pure sex, almost pornographic vJASS coding. I'll try it soon and, of course, it will be added to the JNGP

I agree..

looking_for_help · Mar 27, 2017

Thanks guys, I am glad you like it.

Please report any bugs/problems you encounter (or also things you like), looking forward for your feedback.

Ruke said:
Excellent work man, four suggestions:
1 - Allow to search fonts

You can already change the font: the font dialog enumerates all installed fonts, if you want to add new ones just install them (they will be automatically added the next time you open the dialog).

Ruke said:
2 - Allow to change font line space

This is not supported by Scintilla due to performance reasons.

Ruke said:
3 - Allow to export/import config (want to install my theme?, here)

You can already export/exchange your config: just share your styles.ini file (or your options.ini file if you want to share your general/autocomplete options). In those two files, all information about your current config is stored.

However, I will probably add the option to load a different style file at runtime, but I think the way it is now is already quite flexible.

Ruke · Mar 28, 2017

1 - Allow to search fonts

I meant an input to search for installed fonts ^^.

looking_for_help · Mar 29, 2017

Ruke said:
1 - Allow to search fonts

I meant an input to search for installed fonts ^^.

Why?

The list is already sorted alphabetically, so it should be straightforward to find the desired font. Also the list is sensitive to typing, so you can basically already search for installed fonts by just typing the name. The list itself is the input: it will scroll automatically to the matching font while you type its name. This is also pretty much the standard way how it is done in the common ChooseFont dialog from the Win API.

Every new feature should provide a real and measurable benefit for the user.

Hotwer · Mar 29, 2017

Looking forward to check it out.

kokorombom · Mar 31, 2017

Default font and style makes it impossible to differentiate between q and g in raw codes.

looking_for_help · Mar 31, 2017

kokorombom said:
Default font and style makes it impossible to differentiate between q and g in raw codes.

It has always been like that, even in the first TESH by SFilip, its nothing specific to this TESH.

TESH 2.0 keeps the default styling as close to the original as possible (with very few exceptions).

If you don't like this, just change the styling for raw codes to a style were you can differentiate between those. Thats exactly what the new options dialog was made for.

Kazeon · Apr 2, 2017

This piece of code was posted here from the JNGP using your tesh:

JASS:

    globals
        private constant real    INTERVAL                         = 0.0312500
        private constant real    RELOCATION_RATE                = 0.01
        private constant real    GRAVITY                         = 9.8*INTERVAL
        // Accuracy to calculate slope
        private constant real    SLOPE_DETECTION_RADIUS         = 0.1
        // Higher accuracy will result different trajectory
        // Consumes more memory but  guaranted to produce more realistic trajectory
        private constant integer SLOPE_DETECTION_ACCURACY         = 5
        private constant real    SLOPE_SPEED_INCREMENT_STRENGTH = 0.05
        private constant real    SLOPE_SPEED_REDUCTION_STRENGTH = 0.05
        // Higher value makes slopes have higher to move speed
        private constant real    SLOPE_STRENGTH_FACTOR             = 1.25
        private constant real    MAXIMUM_SLOPE_SPEED_BONUS_RATE    = 1.5
   
        private constant real   MAX_WALKABLE_SLOPE             = 85.0*bj_DEGTORAD
        private constant real   SLIP_MAXIMUM_SPEED             = 522.0*INTERVAL
        private constant real   SLIP_TURN_RATE                 = 15.0*bj_DEGTORAD
        private constant real   ABSOLUTE_SPEED_LIMIT             = 1044.0*INTERVAL
   
        // Minimum slope to indicate take-off
        private constant boolean IDLE_DEACCELERATION            = false
        private constant real   MINIMUM_TAKE_OFF_TILTNESS         = 45.0*bj_DEGTORAD
        private constant real   RANGE_UNIT_ATTACK_RANGE         = 600.0
        private constant real   MELEE_UNIT_ATTACK_RANGE         = 128.0
        private constant real   GENERAL_UNIT_BACKSWING_POINT    = 0.800
        private constant real   GENERAL_UNIT_TURN_RATE            = 5.0*bj_DEGTORAD
        private constant real   GENERAL_UNIT_ACCELERATION        = 16.0*INTERVAL
        private constant real    GENERAL_UNIT_DEACCELERATION    = 5.0*INTERVAL
        private constant real   GENERAL_UNIT_MASS                = 2.0*INTERVAL
   
    endglobals

Whereas it looks neat already in WE:

Can you fix it?

Anyway, this is a lot of improvements of the older tesh, nicey job!
It will be cool tho if it can put user declared functions and variables inside the auto complete list.

looking_for_help · Apr 2, 2017

Quilnez said:
Can you fix it?

Interesting, but this is not TESH related. It seems there is a difference between the richtext editor component of the forum and raw BB code editor, i.e. how they handle indentation in code.

If I fix your code within the TESH using tabs (same applies for spaces) and post it here in the richtext component using jass-blocks I get:

JASS:

 globals
        private constant real    INTERVAL                       = 0.0312500
        private constant real    RELOCATION_RATE               = 0.01
        private constant real    GRAVITY                       = 9.8*INTERVAL
        // Accuracy to calculate slope
        private constant real    SLOPE_DETECTION_RADIUS           = 0.1
        // Higher accuracy will result different trajectory
        // Consumes more memory but  guaranted to produce more realistic trajectory
        private constant integer SLOPE_DETECTION_ACCURACY       = 5
        private constant real    SLOPE_SPEED_INCREMENT_STRENGTH   = 0.05
        private constant real    SLOPE_SPEED_REDUCTION_STRENGTH   = 0.05
        // Higher value makes slopes have higher to move speed
        private constant real    SLOPE_STRENGTH_FACTOR           = 1.25
        private constant real    MAXIMUM_SLOPE_SPEED_BONUS_RATE   = 1.5
 
        private constant real   MAX_WALKABLE_SLOPE               = 85.0*bj_DEGTORAD
        private constant real   SLIP_MAXIMUM_SPEED               = 522.0*INTERVAL
        private constant real   SLIP_TURN_RATE                   = 15.0*bj_DEGTORAD
        private constant real   ABSOLUTE_SPEED_LIMIT           = 1044.0*INTERVAL
 
        // Minimum slope to indicate take-off
        private constant boolean IDLE_DEACCELERATION           = false
        private constant real   MINIMUM_TAKE_OFF_TILTNESS       = 45.0*bj_DEGTORAD
        private constant real   RANGE_UNIT_ATTACK_RANGE           = 600.0
        private constant real   MELEE_UNIT_ATTACK_RANGE           = 128.0
        private constant real   GENERAL_UNIT_BACKSWING_POINT   = 0.800
        private constant real   GENERAL_UNIT_TURN_RATE           = 5.0*bj_DEGTORAD
        private constant real   GENERAL_UNIT_ACCELERATION       = 16.0*INTERVAL
        private constant real    GENERAL_UNIT_DEACCELERATION   = 5.0*INTERVAL
        private constant real   GENERAL_UNIT_MASS               = 2.0*INTERVAL
 
    endglobals

If I paste the same code in the BB code editor I get:

JASS:

 globals
        private constant real    INTERVAL						= 0.0312500
        private constant real    RELOCATION_RATE				= 0.01
        private constant real    GRAVITY						= 9.8*INTERVAL
        // Accuracy to calculate slope
        private constant real    SLOPE_DETECTION_RADIUS			= 0.1
        // Higher accuracy will result different trajectory
        // Consumes more memory but  guaranted to produce more realistic trajectory
        private constant integer SLOPE_DETECTION_ACCURACY		= 5
        private constant real    SLOPE_SPEED_INCREMENT_STRENGTH	= 0.05
        private constant real    SLOPE_SPEED_REDUCTION_STRENGTH	= 0.05
        // Higher value makes slopes have higher to move speed
        private constant real    SLOPE_STRENGTH_FACTOR			= 1.25
        private constant real    MAXIMUM_SLOPE_SPEED_BONUS_RATE	= 1.5
   
        private constant real   MAX_WALKABLE_SLOPE				= 85.0*bj_DEGTORAD
        private constant real   SLIP_MAXIMUM_SPEED				= 522.0*INTERVAL
        private constant real   SLIP_TURN_RATE					= 15.0*bj_DEGTORAD
        private constant real   ABSOLUTE_SPEED_LIMIT			= 1044.0*INTERVAL
   
        // Minimum slope to indicate take-off
        private constant boolean IDLE_DEACCELERATION			= false
        private constant real   MINIMUM_TAKE_OFF_TILTNESS		= 45.0*bj_DEGTORAD
        private constant real   RANGE_UNIT_ATTACK_RANGE			= 600.0
        private constant real   MELEE_UNIT_ATTACK_RANGE			= 128.0
        private constant real   GENERAL_UNIT_BACKSWING_POINT	= 0.800
        private constant real   GENERAL_UNIT_TURN_RATE			= 5.0*bj_DEGTORAD
        private constant real   GENERAL_UNIT_ACCELERATION		= 16.0*INTERVAL
        private constant real    GENERAL_UNIT_DEACCELERATION	= 5.0*INTERVAL
        private constant real   GENERAL_UNIT_MASS				= 2.0*INTERVAL
   
    endglobals

As you can see, indentation is broken in the richtext component, in the raw BB code edior eveything is fine.

This problem persists in the old TESH and even without any TESH (just the raw WE text edit component).

So this is a bug on the forum side, not related to TESH. As a workaround, until this is fixed, just use BB code when posting code.

Quilnez said:
Anyway, this is a lot of improvements of the older tesh, nicey job!
It will be cool tho if it can put user declared functions and variables inside the auto complete list.

Thanks. Yes, would be cool, but at the moment this is out of scope (maybe some day).

Kazeon · Apr 2, 2017

looking_for_help said:
This problem persists in the old TESH and even without any TESH

Are you sure? I mean, for example:

JASS:

    /************************************************************************************
    *                                                                                   *
    *                          Special Creep Engine v3.2                                *
    *                                         *****                                     *
    *                                     by: Dalvengyr                                 *
    *                                                                                   *
    *  This engine generates special behavior to creep units. Makes your RPG become     *
    *  much more alive. Give some brains to those shrimp-head creeps. They can flee,    *
    *  they have sight area (you can sneak behind them), they are able to help each     *
    *  other, they become aggressive and not aggressive as well. And many more!         *
    *                                                                                   *
    *  External dependencies:                                                           *
    *   (required)                                                                      *
    *     - Table                                                                       *
    *     - UnitIndexer                                                                 *
    *     - GetClosestWidget                                                            *
    *     - Any DDS                                                                     *
    *   (optional)                                                                      *
    *     - TimerUtils                                                                  *
    *                                                                                   *
    *  Implementation:                                                                  *
    *     - Copy paste SCE folder into your map                                         *
    *     - Give two player slots for passive and aggresive player, better just         *
    *        leave'em as closed slot                                                    *
    *     - Configure the system                                                        *
    *     - Done.                                                                       *
    *                                                                                   *
    *  Credits:                                                                         *
    *     - GDD by Weep                                                                 *
    *     - GetClosestWidget by Bannar                                                  *
    *     - UnitIndexer by Nestharus                                                    *
    *     - TimerUtils by Vexorian                                                      *
    *     - Table by Bribe                                                              *
    *                                                                                   *
    *   (You can read more info at READ ME trigger)                                     *
    *                                                                                   *
    *************************************************************************************
    *                                                                                   *
    *                                CONFIGURATION                                      */

It was before updated using your tesh. And this is how it looks afterward (I renamed the system):

JASS:

    /************************************************************************************
    *                                                                                   *
    *                           RPG Threat System v3.2c                                 *
    *                                         *****                                     *
    *                                       by: Quilnez                                 *
    *                                                                                   *
    *  This system generates special behavior to creep units. Gives some brains to        *
    *  those shrimp-head creeps. They can flee, they have artificial sight area            *
    *  (you can sneak behind them), they are able to help each other, they become        *
    *  aggressive or not aggressive as well. And many more!                             *
    *                                                                                   *
    *  External dependencies:                                                           *
    *   (required)                                                                      *
    *     - Table                                                                       *
    *     - UnitIndexer                                                                 *
    *     - GetClosestWidget                                                            *
    *     - Any DDS                                                                     *
    *   (optional)                                                                      *
    *     - TimerUtils                                                                  *
    *                                                                                   *
    *  Implementation:                                                                  *
    *     - Copy paste RPG Threat System folder into your map                            *
    *     - Give two player slots for passive and aggresive player, better just         *
    *       leave'em as empty player slot                                               *
    *     - Configure the system & start defining your creep behavior                    *
    *     - Done.                                                                       *
    *                                                                                   *
    *  Credits:                                                                         *
    *     - GDD by Weep                                                                 *
    *     - GetClosestWidget by Bannar                                                  *
    *     - UnitIndexer by Nestharus                                                    *
    *     - TimerUtils by Vexorian                                                      *
    *     - Table by Bribe                                                              *
    *                                                                                   *
    *   (You can read more info at READ ME trigger)                                     *
    *                                                                                   *
    *************************************************************************************
    *                                                                                   *
    *                                CONFIGURATION                                      */

You see the only parts that got wrongly indented are only the ones I modified with your tesh. So I think the older tesh doesn't have this problem.

looking_for_help · Apr 2, 2017

Quilnez said:
You see the only parts that got wrongly indented are only the ones I modified with your tesh. So I think the older tesh doesn't have this problem.

Hm, please be more specific... are you talking now about the code in the WE itself? Or only about how the code is displayed here on this site within jass blocks?

With the code you posted, I cannot reproduce the problem, because the first code is indented correctly when I paste it into the WE with the new TESH.

Can you upload a minimal example map that contains code of your example above (only the renamed system)?

KILLCIDE · Apr 5, 2017

It seems the new TESH crashes the editor when you try to save it after opening the Trigger Editor.

As you can see with the second GIF, all I do is open the Trigger Editor and immediately close.

looking_for_help · Apr 5, 2017

Quilnez said:
Are you sure?

The bug has been confirmed on the forum side in the meantime, so I am pretty sure that it is not TESH related. If you have indications that it could be different, please share them.

KILLCIDE said:
It seems the new TESH crashes the editor when you try to save it after opening the Trigger Editor.

As you can see with the second GIF, all I do is open the Trigger Editor and immediately close.

Hm, I cannot reproduce this behavior, I can safe and close without any problems... I need more details:

Which OS and which version of Wc3 are you using?
This only happens when actually closing the whole WE, not when just saving, right?
Does this also happen if you close without saving (click "No" button)?
Does this always happen (i.e. reproducable) or does it sometimes work?
Did you open any sub-windows of the TESH before (like function list etc.)?

KILLCIDE · Apr 5, 2017

looking_for_help said:
Which OS and which version of Wc3 are you using?

Windows 10 64 Bit / 1.27b

looking_for_help said:
This only happens when actually closing the whole WE, not when just saving, right?

Yes

looking_for_help said:
Does this also happen if you close without saving (click "No" button)?

Never gave it a try. I will try once i reinstall WC3 because patch 1.28 has some issues.

looking_for_help said:
Does this always happen (i.e. reproducable) or does it sometimes work?

Yes it always happened, which is how I was able to record the GIF

I was able to figure out what was causing the crash because I was reviewing a few submissions in the Spell Section.

looking_for_help said:
Did you open any sub-windows of the TESH before (like function list etc.)?

Nope. All I did was open the Trigger Editor, close it, and then closed the WE.

Kazeon · Apr 5, 2017

looking_for_help said:
The bug has been confirmed on the forum side in the meantime, so I am pretty sure that it is not TESH related. If you have indications that it could be different, please share them.

Yep you're right. That's my bad for reporting without testing the older tesh. In fact I just tested it a few moments ago : p

KILLCIDE · Apr 5, 2017

Back with an update, lfh.

looking_for_help said:
This only happens when actually closing the whole WE, not when just saving, right?

Saving doesn't crash it. However, if you save, and then close the map after, it still crashes.

looking_for_help said:
Does this also happen if you close without saving (click "No" button)?

Yes. It also happens when I click on the "No" button

looking_for_help said:
Does this always happen (i.e. reproducable) or does it sometimes work?

100% of the time. All I have to do is open the Trigger Editor, close it, and close the map.

looking_for_help · Apr 5, 2017

Quilnez said:
Yep you're right. That's my bad for reporting without testing the older tesh. In fact I just tested it a few moments ago : p

Ok, thats good to know, thanks for checking that again.

KILLCIDE said:
Back with an update, lfh.

Thanks for the detailed explanation, I will try to fix that ASAP. However, I am still not able to reproduce the bug, maybe thats something Win10 specific... (I use Win7).

Glowackos · Apr 8, 2017

Awesome! Will give feedback after giving it a test ride.

Thanks very much for constantly addressing all the points everyone raises. I'm already loving what I've read in the changelog.

I'd give you more rep, but website won't let me yet.

Glowackos · Apr 14, 2017

Looks like the hex in styles.ini might be backwards.
eg. 0xD8AB70 == rgb(216,171,112)
but you're saving that rgb value as 0x70ABD8.

It 's not an issue unless someone tries to edit the styles.ini manually, in which case they need to put in the hex values backwards.
Also a minor nitpick re styles.ini, what's the reasoning for enforcing
```
blah.backcolor=0x...
blah.backcolor_index=1
```
only to hide it with `blah.transparent=1`.
Surely these could all just be unset by default, and then setting them would override the background colour?
Worldedit hangs on closing if tesh has been started up during that session, sending me through two forcequite cycles before it finally gives up and goes away. (wc3 tft 1.28, cannot confirm if this is new, or if it affects 1.27b as well).

Rest looks pretty sweet!

More feedback to come later.

looking_for_help · Apr 14, 2017

Thanks for the feedback.

Glowackos said:
Looks like the hex in styles.ini might be backwards.
eg. 0xD8AB70 == rgb(216,171,112)
but you're saving that rgb value as 0x70ABD8.
It 's not an issue unless someone tries to edit the styles.ini manually, in which case they need to put in the hex values backwards.

Yes thats right. This is because COLORREF stores colors in BGR order.

Maybe I will change that to store RGB, however I don't really see a reason why someone would modify the styles.ini manually.

Actually there is a pretty massive amount of plausibility checks implemented in the option file parser to avoid that manual modifications of this file can lead to undesired effects/crashes. So, it is not neccessary to manually modify that file: every possible option can also be set from within the WE.

Glowackos said:
Also a minor nitpick re styles.ini, what's the reasoning for enforcing
```
blah.backcolor=0x...
blah.backcolor_index=1
```
only to hide it with `blah.transparent=1`.
Surely these could all just be unset by default, and then setting them would override the background colour?

Its not hidden, the color is actually used. There are several things to consider here, I have put quite some time in thinking this through before implementing this. Let me explain:

Typically, when users change the backcolor of the whole editor (the background of the editor itself), it is expected that other styles also change their backcolor "automatically". I.e. that they behave as if transparent.

For example, if I want to use a dark backcolor style, I usually just want to change the editor backcolor to black. I don't want to set the backcolor of all other styles manually to black as well, because thats redundant and tedious work. Therefore changing the editor backcolor should change other styles backcolors as well.

However, what happens if for some styles, I actually want to have a different backcolor. Then I don't want that this information is lost/overwritten when changing the editor backcolor.

There are basically two approaches to resolve this issue:

Change only the backcolor of styles automatically, that had the same backcolor as the editor backcolor before the change was requested.
Use a seperate flag to let the user configure which style should be "transparent". This is what is done in TESH 2.0.

So, why was the second option chosen over the first? Because it gives the user more flexibility by avoiding undesirable effects: Imagine your editor backcolor is white, the backcolor of, say, native types is red. Now the user changes the editor backcolor to red. After that, the user changes the editor backcolor to green. If method 1.) was used, the algorithm would have no way to detect that native type backcolor should actually stay red, regardless of the editor backcolor.

With option 2.) this is easily possible. It gives better control of style handling to the user. Therefore, this option was chosen for TESH 2.0.

Why I write "transparent" in double quotes?

Because the backcolor of the styles are not really transparent. Behind the scenes, if set to transparent, they look up the editor backcolor and just use this one.

Glowackos said:
Worldedit hangs on closing if tesh has been started up during that session, sending me through two forcequite cycles before it finally gives up and goes away. (wc3 tft 1.28, cannot confirm if this is new, or if it affects 1.27b as well).

Yes, I have already identified (and fixed) that issue, will release a patch for this soon.

Glowackos said:
Rest looks pretty sweet!
More feedback to come later.

Thanks, looking forward for that.

Glowackos · Apr 15, 2017

looking_for_help said:
Yes thats right. This is because COLORREF stores colors in BGR order.

Maybe I will change that to store RGB, however I don't really see a reason why someone would modify the styles.ini manually.

Actually there is a pretty massive amount of plausibility checks implemented in the option file parser to avoid that manual modifications of this file can lead to undesired effects/crashes. So, it is not neccessary to manually modify that file: every possible option can also be set from within the WE.

Hehe, well i tried to translate my old config into your format, and felt it'd be quicker to just edit the styles.ini directly.

I got it all to work, cept my colours turned out inverted. XD Trust Microsoft to make things weird. I'd suggest fixing this, though it's not huge priority. It just causes unnecessary confusion.
In this vein, it would be sweet if there was a button in the WE TESH style editor section to reload from the styles.ini (i had to restart wc3 each time lol). Using the interface is a bit slow, esp since it doesn't let you feed in hex directly.

looking_for_help said:
Its not hidden, the color is actually used. There are several things to consider here, I have put quite some time in thinking this through before implementing this. Let me explain:

Typically, when users change the backcolor of the whole editor (the background of the editor itself), it is expected that other styles also change their backcolor "automatically". I.e. that they behave as if transparent.

For example, if I want to use a dark backcolor style, I usually just want to change the editor backcolor to black. I don't want to set the backcolor of all other styles manually to black as well, because thats redundant and tedious work. Therefore changing the editor backcolor should change other styles backcolors as well.

However, what happens if for some styles, I actually want to have a different backcolor. Then I don't want that this information is lost/overwritten when changing the editor backcolor.

There are basically two approaches to resolve this issue:

Change only the backcolor of styles automatically, that had the same backcolor as the editor backcolor before the change was requested.

Use a seperate flag to let the user configure which style should be "transparent". This is what is done in TESH 2.0.

So, why was the second option chosen over the first? Because it gives the user more flexibility by avoiding undesirable effects: Imagine your editor backcolor is white, the backcolor of, say, native types is red. Now the user changes the editor backcolor to red. After that, the user changes the editor backcolor to green. If method 1.) was used, the algorithm would have no way to detect that native type backcolor should actually stay red, regardless of the editor backcolor.

With option 2.) this is easily possible. It gives better control of style handling to the user. Therefore, this option was chosen for TESH 2.0.

Why I write "transparent" in double quotes?

Because the backcolor of the styles are not really transparent. Behind the scenes, if set to transparent, they look up the editor backcolor and just use this one.

Sure, but couldn't these just be left unset? ie if `text.backcolor` doesn't exist in the styles.ini file, use editor_background.backcolor in its stead. If it is set, use it. Then there is no issue with unintentionally overriding settings, as when the user selects a different global backcolour, only the editor_background.backcolor value changes in styles.ini. Everything else simply defaults to this backcolour if nothing else is set. If they want a different backcolour for something, eg `selection.backcolor`, then when they set this, `selection.backcolor` is explicitly added to styles.ini.
The old tesh used `backcolour=default` for these cases, but even that was superfluous imo. Just not including it in the file is enough. Then you might not even need the "transparent" flag.

MindWorX · Apr 15, 2017

Did you change how your injection works in the new version? I just tried out the current version with the JNGP replacement and it crashes the editor on startup. This doesn't happen with the old TESH and your previous version.

looking_for_help · Apr 15, 2017

Glowackos said:
Hehe, well i tried to translate my old config into your format, and felt it'd be quicker to just edit the styles.ini directly.

Ok, that makes sense.

Glowackos said:
I got it all to work, cept my colours turned out inverted. XD Trust Microsoft to make things weird. I'd suggest fixing this, though it's not huge priority. It just causes unnecessary confusion.
In this vein, it would be sweet if there was a button in the WE TESH style editor section to reload from the styles.ini (i had to restart wc3 each time lol). Using the interface is a bit slow, esp since it doesn't let you feed in hex directly.

Will be added in the next patch.

Glowackos said:
Sure, but couldn't these just be left unset? ie if `text.backcolor` doesn't exist in the styles.ini file, use editor_background.backcolor in its stead. If it is set, use it. Then there is no issue with unintentionally overriding settings, as when the user selects a different global backcolour, only the editor_background.backcolor value changes in styles.ini. Everything else simply defaults to this backcolour if nothing else is set. If they want a different backcolour for something, eg `selection.backcolor`, then when they set this, `selection.backcolor` is explicitly added to styles.ini.
The old tesh used `backcolour=default` for these cases, but even that was superfluous imo. Just not including it in the file is enough. Then you might not even need the "transparent" flag.

So you only meant why it is stored in the styles.ini like that, right?

Well, it could also be implemented like you explained. However, I don't really see an advantage over the way how it is done at the moment. I prefer to have everything explicitly stated in the file, because the structure of the file is then always the same and there are no implicit settings obscuring any options from the user. Also it avoids inconsistent states like setting transparent to 0 manually in the file, while not specifying a backcolor.

Of course that could again be checked when the file is read, but I prefer that if users want to modify the file manually, they at least have all options to modify there directly - without adding or deleting any lines, but just changing values.

However, I will probably display the transparent flag differently in the file... maybe just like text.backcolor=transparent instead of specifying the color itself.

MindWorX said:
Did you change how your injection works in the new version? I just tried out the current version with the JNGP replacement and it crashes the editor on startup. This doesn't happen with the old TESH and your previous version.

Yes, there are some differences... which JNGP replacement did you use? Which OS are you using and do you get any error messages?

MindWorX · Apr 15, 2017

looking_for_help said:
Yes, there are some differences... which JNGP replacement did you use? Which OS are you using and do you get any error messages?

I'm using my SharpCraft project which simply loads up your dll. I do have some of my own hooks into various functions like CreateWindowsEx and SetMenu. I also override the GWL_WNDPROC, but I do read out the old one and call it after my own logic.

I'm on Windows 8.1, and there are no errors, just a crash.

It might make sense if we work together a bit and make a SharpCraft specific version of your plugin, since JNGP will be discontinued.

Glowackos · Apr 16, 2017

looking_for_help said:
Will be added in the next patch.

Awesome, thanks

looking_for_help said:
However, I will probably display the transparent flag differently in the file... maybe just like text.backcolor=transparent instead of specifying the color itself.

Sounds good!

MindWorX said:
since JNGP will be discontinued.

wat? JNGP2.0?

looking_for_help · Apr 17, 2017

MindWorX said:
I'm using my SharpCraft project which simply loads up your dll. I do have some of my own hooks into various functions like CreateWindowsEx and SetMenu. I also override the GWL_WNDPROC, but I do read out the old one and call it after my own logic.

I'm on Windows 8.1, and there are no errors, just a crash.

Ok, I will take a look into this, thanks for the feedback.

MindWorX said:
It might make sense if we work together a bit and make a SharpCraft specific version of your plugin

Well, I don't really want to have multiple versions around at the same time... at least if that can be avoided. I think having just one single version that works for everything is better and avoids confusions.

MindWorX said:
since JNGP will be discontinued.

Hm, did I miss something?

MindWorX · Apr 17, 2017

looking_for_help said:
Hm, did I miss something?

Since JNGP is still stuck on version 1.21, it's breaking more and more, like GUI features crashing the editor and the recent MPQ changes that broke it as well. We have better alternatives that are updated and work with the most recent patches, so it's not worth the hassle to try and keep JNGP working.

Kazeon · Apr 21, 2017

This sometimes crashes the WE when I open a trigger. But it's quite rare to happen, and it can happen to any trigger. Is it somewhat related to the patch 1.27b I'm using?

KILLCIDE · Apr 21, 2017

You might be encountering the same issue I had, @Quilnez.

Kazeon · Apr 21, 2017

KILLCIDE said:
You might be encountering the same issue I had, @Quilnez.

Looks like it's different. For me it never crashed when I save maps. Only happen when I open a trigger.

DD_legionTN · Apr 24, 2017

Not sure if it is TESH related, but this is the first time I encountered run-time error while using WE with TESH 2.0. Here is the image :

And another thing is, although not a big deal, WE tends to crash while I close it, and appear to have this error message before the crash message :

looking_for_help · May 6, 2017

Now fully WEX and Sharpcraft compatible. Also fixed quite some small bugs. Styles can now be reloaded at runtime. Tabs and spaces are now handled "as expected".

Update to version 0.9.1

Fixed a crash when closing WE
Added compatibility with WEX and Sharpcraft
Fixed that sometimes, text window was displayed over GUI
Fixed short flickering of the editor when starting WE starts for the first time
Added the option to load style themes at runtime
Fixed that under some circumstances, function list text could be modified
Fixed tabs to spaces does not take into account effective tab length
Fixed spaces to tabs does not take into account effective tab length
Added the option to use spaces instead of tabs
Fixed loading special characters from template files causing wrong encoding
Fixed error on loading trigger editor name from file containing unicode characters
Added an exported function to the dll to set the search string for the TE window programmatically
Changed all predefined templates from using tabs to using spaces by default
Styles are now stored as RGB instead of BGR in the styles.ini file

And attached an image of the new option dialog.

Looking forward for feedback.

psxlover · Jun 12, 2017

0.9.1 can't open files (options/style) if it is located in a folder with non ASCII characters:

If I move WEX in a folder without greek characters the options/style/function.db load correctly.

psxlover · Jun 12, 2017

I also noticed a strange issue with font rendering.
I changed my font to Consolas, and noticed that even though the font is monospaced the space size was not the same as the character size. Changing the font size to 11 for consolas it renders as a proper monospaced font but any other size renders wrong.
Trying with Courier New the font remains monospaced for any font size up to size 10. Any higher than that and the spacing is wrong.

Also what does "Filter legacy TESH scroll/fold info"? Does it remove those two line left by the old TESH, or does it use them to restore the last editor state?

looking_for_help · Jun 12, 2017

psxlover said:
0.9.1 can't open files (options/style) if it is located in a folder with non ASCII characters:

Will be fixed in the next patch.

psxlover said:
I also noticed a strange issue with font rendering.
I changed my font to Consolas, and noticed that even though the font is monospaced the space size was not the same as the character size. Changing the font size to 11 for consolas it renders as a proper monospaced font but any other size renders wrong.
Trying with Courier New the font remains monospaced for any font size up to size 10. Any higher than that and the spacing is wrong.

Will take a look into this, thanks.

psxlover said:
Also what does "Filter legacy TESH scroll/fold info"? Does it remove those two line left by the old TESH, or does it use them to restore the last editor state?

It just removes the two lines if they exist (if unticked, the two lines are not removed).

In theory this legacy trigger state info could be used by TESH 2.0 as well to restore the last editor state. However, it doesn't really make sense because both fold and scroll state are already stored internally in the new TESH. So whenever you switch to a new trigger and then move back, both the fold and scroll state will be restored without modifying the trigger script. This has the benefit that the dirty flag isn't raised for the TE.

psxlover · Jun 12, 2017

MindWorX · Jun 24, 2017

I've had a few reports from @Spellbound and @Kithio who have been experiencing crashes when coding. Spellbound tried switching back to old TESH and haven't been having any problems since. Problem is, it's a periodic/unreliable crash so it'll be hard to debug.

psxlover · Jun 24, 2017

MindWorX said:
I've had a few reports from @Spellbound and @Kithio who have been experiencing crashes when coding. Spellbound tried switching back to old TESH and haven't been having any problems since. Problem is, it's a periodic/unreliable crash so it'll be hard to debug.

I also had a crash the first time I used it. For me it happened when I opened another trigger, and hasn't happened since so I have no Idea how to reproduce it.

MindWorX · Jun 24, 2017

That's the report I've been getting as well, it happens randomly when switching between triggers, more often for some than others.

Spellbound · Jun 24, 2017

Specifically, for me, the crash happens when selecting a trigger with vJASS in it. I doesn't happen all the time - sometimes selecting trigger A will crash the editor, but other times I can select it and modify it without any problems. It seems really random.

EDIT: MindWorX beat me to it lol

Bribe · Jun 24, 2017

maybe you have some infinite loop on your code if the highlighting hits a weird syntax situation. You can try limiting the number of draws to a finite number and display an error when it's reached.

looking_for_help · Jun 24, 2017

Bribe said:
maybe you have some infinite loop on your code if the highlighting hits a weird syntax situation. You can try limiting the number of draws to a finite number and display an error when it's reached.

Hm I doubt that this is the reason because then it would happen every time you select such a trigger, which apparently isn't the case here...

Spellbound said:
Specifically, for me, the crash happens when selecting a trigger with vJASS in it. I doesn't happen all the time - sometimes selecting trigger A will crash the editor, but other times I can select it and modify it without any problems. It seems really random.

Could you (or anyone else who experienced this problem) please upload a map with the exact trigger in it that was selected when this crash happened? Best would be an empty map with just the trigger in it (not posting the trigger here), because the forum software makes some minor changes to the trigger text.

Also, can you remember if this happened when you selected the trigger for the first time after opening the map? Or did you already select it before? Which OS are you using btw?

Also, can you explain what exactly happens when the crash appears? Does the editor freeze or do you get some error message (like: "Warcraft 3 has stopped working")?

Spellbound · Jun 24, 2017

It's not any specific trigger. Sometimes I can select a trigger and it's fine, and the next time I select it after have selected another one, it can crash. Another time I can select a trigger multiple times and it's also fine, and then select another one that was fine before, and then it crashes. Sometimes it crashes on the very first vJASS trigger I select. It seems to be completely random and has a risk of crashing whenever I select any trigger with vJASS in it.

The crash is a runtime error iirc. I get an error message after which my editor is forced to close.

My OS in Window 10 64bit

EDIT: If I have some time tomorrow I'll try recreating the error.

KILLCIDE · Jun 24, 2017

I used to have this issue, but after the recent update on tesh, I havent encountered it.

Zwiebelchen · Jun 25, 2017

I managed to somewhat reliably reproduce the error in a test map and even made a video of it:

SharpCraft World Editor Extended Bundle

PS: I used the current WEX default installation. No manual update on TESH yet.

looking_for_help · Jun 25, 2017

Zwiebelchen said:
I managed to somewhat reliably reproduce the error in a test map and even made a video of it:

SharpCraft World Editor Extended Bundle

PS: I used the current WEX default installation. No manual update on TESH yet.

You saved me a lot of trouble, with that map I was able to track down the error. Thanks a lot.

Crash will be fixed soon.

psxlover · Jun 25, 2017

Out of curiosity, what was the cause?

looking_for_help · Jun 25, 2017

psxlover said:
Out of curiosity, what was the cause?

For some reason the lexer is iterating beyond the text string... since that causes undefined behavior, it sometimes works, sometimes not (= crashes).

I'm not yet sure why this happens on this specific trigger (and not on other triggers I have tested so far), but there seems to be some code combination that is treated wrong by the lexer (so actually Bribe was more or less on the right track).

However, since I have now a way to reproduce the error, finding the actual cause will be pretty easy.

A new TESH Syntax Highlighter for Warcraft 3

Similar threads