A new TESH Syntax Highlighter for Warcraft 3

[KILLCIDE]

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

 

[Ruke]

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]

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]

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.

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).

2 - Allow to change font line space

This is not supported by Scintilla due to performance reasons.

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]

1 - Allow to search fonts

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

 

[looking_for_help]

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]

Looking forward to check it out.

 

[kokorombom]

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

 

[looking_for_help]

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]

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

    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]

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:

Richtext code

 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:

BB code

 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.

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]

This problem persists in the old TESH and even without any TESH

Are you sure? I mean, for example:

    /************************************************************************************
    *                                                                                   *
    *                          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):

    /************************************************************************************
    *                                                                                   *
    *                           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]

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]

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

Saving map without opening Trigger Editor

Saving map after opening Trigger Editor

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

 

[looking_for_help]

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.

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]

Which OS and which version of Wc3 are you using?

Windows 10 64 Bit / 1.27b

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

Yes

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.

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.

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]

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]

Back with an update, lfh.

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.

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

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

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]

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.

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]

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]

1. 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.
2. 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?
   
3. 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]

Thanks for the feedback.

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.

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:

1. Change only the backcolor of styles automatically, that had the same backcolor as the editor backcolor before the change was requested.
2. 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.

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.

Rest looks pretty sweet!
More feedback to come later.

Thanks, looking forward for that.

 

[Glowackos]

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.

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:

1. Change only the backcolor of styles automatically, that had the same backcolor as the editor backcolor before the change was requested.
2. 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]

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]

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.

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.

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.

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]

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]

Will be added in the next patch.

Awesome, thanks

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!

since JNGP will be discontinued.

wat? JNGP2.0?

 

[looking_for_help]

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.

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.

since JNGP will be discontinued.

Hm, did I miss something?

 

[MindWorX]

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]

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]

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

 

[Kazeon]

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]

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 :

Run-time Error

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 :

Error

 

[looking_for_help]

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.

Options

Looking forward for feedback.

 

[psxlover]

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]

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]

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.

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.

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]

Tnx

 

[MindWorX]

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]

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]

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

 

[Spellbound]

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]

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]

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...

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]

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]

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

 

[Zwiebelchen]

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]

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]

Out of curiosity, what was the cause?

 

[looking_for_help]

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.