Jump to content

[REL] GUI Editor 3.1.3


Remp

Recommended Posts

  • 3 weeks later...

As for bug reports, I can't tell whether I'm doing something wrong or not.

But more often than not, whenever I click to change for example Start X or End X and etc, it'll 2 or 3 or sometimes all of these options with the proper one at the very back of them all. Thus having to close 2-3 windows before I can change what I want.

Nothing major, of course. I'm actually not sure what causes it. :(

Link to comment
As for bug reports, I can't tell whether I'm doing something wrong or not.

But more often than not, whenever I click to change for example Start X or End X and etc, it'll 2 or 3 or sometimes all of these options with the proper one at the very back of them all. Thus having to close 2-3 windows before I can change what I want.

Nothing major, of course. I'm actually not sure what causes it. :(

This is actually a really great catch, thanks for the report!

It seems to be to do with the menu item overlay button handling. If you hover over the overlay button on one item (e.g. Set Start X) then move the mouse downwards onto the next item (Set Start Y) without moving the mouse left or right it will fail to properly detect that you are no longer inside the first overlay button (Set Start X). Then when you click (on the Set Start Y overlay button), it thinks you are inside both items buttons and processes both handlers. If you start at the top and go down the whole menu it will even open them all!

This will be fixed in the next version.

Link to comment

Sweet! Can't wait for the update :D

Another thing I would like see introduced would be the ability to "lock" certain elements. For example, I like to draw a big black screen as a background - sort of an old habit from working with Photoshop.

But doing so, I can't ever add anything because when I right click that, it assumes I want to edit it. What I'm asking for is something like this;

1. I draw a black rectangle, image or whatever which covers the entire screen.

2. Add some right-click option to "Freeze" that element.

And then for unlocking it, I guess some keybind or whatever. This isn't really something important, just a thing of convenience :P

Link to comment

3GGh5Bz.png

GUI Editor 3.1.2 update:

- Changed "Shadow" and "Outline" options of DX Rectangles to use DX lines rather than drawing an offset rectangle

- Added "Set default size" menu option to DX images

- Made "Outline" and "Shadow" on relative DX items output the correct code (+ improved loading relative DX a little)

- Added "Locked" menu option that stops right click detecting the element (can be accessed/bypassed by holding ctrl)

- Added "Set outline colour" and "Set shadow colour" to DX items with shadow/outline options

- Fixed menu item overlay buttons not properly detecting mouse exit event

- Fixed problem with the "Automatically resize output window" setting when generating DX code

MTA Community link

As usual please let me know of any bugs/errors that you get, they are very helpful in improving the GUI Editor!

Link to comment
I can't seem to find how to "lock" elements.

Hold ctrl (either left or right) while you right click an element and the menu will have an extra "Locked" item at the bottom. Once it is locked you can't right click on it again unless you are holding ctrl.

If that doesn't work, something must be wrong!

Link to comment

I can't even express how much better it is to work with now :D

Do you think it would be possible to make it so we can assign a DX Rectangle/Image as a "parent"? So all DX stuff we draw afterwards have their positions relative to that parent, instead of the screen resolution? This would speed up the process of making movable DX windows :)

Link to comment
Do you think it would be possible to make it so we can assign a DX Rectangle/Image as a "parent"? So all DX stuff we draw afterwards have their positions relative to that parent, instead of the screen resolution? This would speed up the process of making movable DX windows :)

I suppose it is technically possible, though the output code might be a little odd (especially if they are toggled relative). Keeping that parent relationship when loading dx code back in would also be very hard to do.

I think the main problem with things like this is that the way the output code is designed will depend on the specific situation you are using it for and the developers coding style. For example, does it just hard code (parent position + child offset) into every single position argument (which isn't very usable/manageable for a human, and certainly not very easy to modify), or does it start creating variables that store the parent positions and pointing to them in the child position arguments. If GUI Editor starts defining local variables in its output, how extensive should that support be? It is very likely that people could design their code to fit their specific use case (and modify the output to match) in a far better way than the GUI Editor would ever be able to.

Link to comment
  • 1 month later...

Ehm, I guess this could be considered as a bug,

When I make a Dx rectangle relative in a resolution 1440, 900 and the size of the rect is 1440, 900 and test it in higher resolution it gets automatically re-sized to 1440, 900 that happens in the preview resolution option..

Link to comment

Looks like you are right, it appears that all elements won't resize properly when testing in a resolution higher than your own.

This seems to be an MTA limit, for some reason it won't allow you to create GUI elements larger than your own resolution. I tried a few variations of this in runcode, but it just disregards sizes bigger than my window:

Executing client-side command: button = guiCreateButton(0, 0, 1920, 1080, "", false) 
Command executed! 
Executing client-side command: guiGetSize(button, false) 
Command results: 1680 [number], 1050 [number] 

This also effects the DX items in the GUI Editor since they are technically implemented as masks drawn over GUI elements under the hood. I'm not sure there is anything i can do about this unfortunately, unless the MTA limit can be removed or worked around (if anyone else has any information about this, i would be grateful for it). Sorry!

Link to comment
  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...