10 replies to this topic

[iam1me]

Hi all

I'm thinking of making my own extension and i wanted to know what the difference between LIB & GEX were - under which situation is one preferable to the other? Both are composed of GML scripts right?

Edited by iam1me, 11 February 2012 - 06:45 AM.

[Gamer3D]

I'm thinking of making my own extension and i wanted to know what the difference between LIB & GEX were - under which situation is one preferable to the other? Both are composed of GML scripts right?

LIB = Collection of actions (usually scripts) that are treated as Drag-and-Drop blocks.
GEX = Collection of LIBS, DLLs, and pure GML scripts.

Make a LIB if you are making a drag-and-drop thing. Gift the noobs with your code, but know that many users will ignore it because they can't use it in GML.
Make a GEX if you want to provide GML functions with hidden code or automatically-initialized DLLs.


If nothing else, the difference will become clear once you open the editors.

Anyway, (I think) I've answered that. I have a question for the people who use this forum:
DLL, GEX, or both?

[iam1me]

I'm thinking of making my own extension and i wanted to know what the difference between LIB & GEX were - under which situation is one preferable to the other? Both are composed of GML scripts right?

LIB = Collection of actions (usually scripts) that are treated as Drag-and-Drop blocks.
GEX = Collection of LIBS, DLLs, and pure GML scripts.

Make a LIB if you are making a drag-and-drop thing. Gift the noobs with your code, but know that many users will ignore it because they can't use it in GML.
Make a GEX if you want to provide GML functions with hidden code or automatically-initialized DLLs.


If nothing else, the difference will become clear once you open the editors.

Anyway, (I think) I've answered that. I have a question for the people who use this forum:
DLL, GEX, or both?

Thank you

[kburkhart84]

I myself prefer a GEX.

1. For dlls, it auto-inits them once you are using them, instead of having to call scripts defining the functions and arguments(though they still have to be defined in the extension creator). It also includes the dll in the package, and so you don't have to separately put it into the game's folder, rather it gets extracted along with the game's resources.

2. Another good reason is that you can make scripts that "acompany" the dll. For example, in my kbzip extension, the dll itself only contains the simple extract, archiving functions. But the gex also contains gml that loads in sprites and backgrounds, utilizing the dll functions in the process. So in one function call, the gml side calls the dll side to extract a given file, then the gml loads the file as an external resource, then it deletes the file(using gml). To do this kind of thing distributing a dll, I would have to provide separate scripts for that functionality, or the user would have to come up with them.

3. It allows you to create "script containers." For example, my kbinput3 extension is a bunch of gml scripts, and nothing else. It simply extends on GM's input system, allowing the game player to choose his/her controls, and your games input response to rely on a single function, not caring about whether the player is using a keyboard, joystick, or both. Instead of loading this up as a group of scripts in the game maker resource tree, I have it all in an extension, and the scripts are all available.

4. It allows for d&d actions(like libs) along with all of the other things, all at once. I've never actually done this because most of my extension simply would get too complicated for d&d usage and are actually easier to use with gml code, but for some extensions, this would make sense.

5. Another good reason is that all the scripts/functions, whether they are gml coded or dll functions, or even gml code that ends up calling dll functions, all can appear on the autocomplete box, and in the status bar(showing the arguments). This can help a lot when you are actually coding things.

6. The last reason that comes to mind is the fact that all of these things come in a single package, even the help file(if you so desire). You have only a single file to distribute, and it includes any number of these things.

[iam1me]

I myself prefer a GEX.

1. For dlls, it auto-inits them once you are using them, instead of having to call scripts defining the functions and arguments(though they still have to be defined in the extension creator). It also includes the dll in the package, and so you don't have to separately put it into the game's folder, rather it gets extracted along with the game's resources.

2. Another good reason is that you can make scripts that "acompany" the dll. For example, in my kbzip extension, the dll itself only contains the simple extract, archiving functions. But the gex also contains gml that loads in sprites and backgrounds, utilizing the dll functions in the process. So in one function call, the gml side calls the dll side to extract a given file, then the gml loads the file as an external resource, then it deletes the file(using gml). To do this kind of thing distributing a dll, I would have to provide separate scripts for that functionality, or the user would have to come up with them.

3. It allows you to create "script containers." For example, my kbinput3 extension is a bunch of gml scripts, and nothing else. It simply extends on GM's input system, allowing the game player to choose his/her controls, and your games input response to rely on a single function, not caring about whether the player is using a keyboard, joystick, or both. Instead of loading this up as a group of scripts in the game maker resource tree, I have it all in an extension, and the scripts are all available.

4. It allows for d&d actions(like libs) along with all of the other things, all at once. I've never actually done this because most of my extension simply would get too complicated for d&d usage and are actually easier to use with gml code, but for some extensions, this would make sense.

5. Another good reason is that all the scripts/functions, whether they are gml coded or dll functions, or even gml code that ends up calling dll functions, all can appear on the autocomplete box, and in the status bar(showing the arguments). This can help a lot when you are actually coding things.

6. The last reason that comes to mind is the fact that all of these things come in a single package, even the help file(if you so desire). You have only a single file to distribute, and it includes any number of these things.

Thank you for all the info

At this moment I'm only using GML for my library - no need for DLLs for now. #5 is very appealing though - is there a way to name the arguments for the drop down? or does it merely show how many you need?

You stress that with a GEX everything comes together as a single package - is this NOT the case with a LIB? Do all the individual scripts just get added to the project or something? If so, this might be preferable with the first release or two so that others can see the code and make further suggestions - but I definitely see the appeal of GEX.

[kburkhart84]

A lib can come with all the script in that package, but since it is only d&d boxes, you don't get most of the features of a gex, whereas the gex can have lib files, and then some. And in the extension builder, where you define the functions/scripts, be it dll or gml scripts, there is a text box where you define the help line, and this is where you would put"gmlfunc1(arg1, arg2)" at. The arg1, arg2 could easily be "pos" and "direction" or whatever they are, according to what your function does. Like my kbzip would have things like "filename" and "zipfilename" and my kbinput3 extension would have "actionnumber" and "delayinseconds". Then, the help line and autocomplete have no relevance to the lib files, because they are d&d blocks, not code that gets written. Then, the d&d dialog box that opens, allowing the user to define the arguments, would have those values like "filename" etc... which is defined as part of the lib.

About libs and open source code, the lib doesn't directly show code in any project, rather it just adds tab to the d&d actions list. You can't see the resulting code, unless either you give them a txt/gml file containing it, or they open up the lib file(which I believe has the code in a readable form) itself. So if you want to allow users to know/see your code, you can either give them the gml file, or the gmk/gm81 file, which could contain those scripts, as they are before turning them into lib/gex in the first place. Like in the case of kbinput3, I provide the scripts in a .gml file, so someone could use them in older gm versions, change them to add/remove features, maybe even upgrade them to a newer gm version if functions changed and I quit upgrading or something like that. But for simplicity of use(between the autocomplete and the help line) I prefer to actually use the thing in the form of a GEX file.

[iam1me]

Question: What does D&D stand for? I've only ever used GML (I avoid doing things via the interface).

I think I will go ahead and do as you suggest - provide it as a GEX and also provide the source code in a separate gm81 file. The autocomplete/help line features will be very useful!


I've got another question for you to. Are there currently any popular GUI API extensions? I've searched the forum but there doesn't seem to be much save little pieces here and there. I ask because that's what mine is - a GUI Application Programmers Interface. Rather than just provide a couple nice objects like buttons and such (which it will have) - it provides a whole new coding interface for designing complex GUIs with ease. It will also, itself, be extensible. Sound like something you might use for your projects?

[kburkhart84]

Question: What does D&D stand for? I've only ever used GML (I avoid doing things via the interface).

I think I will go ahead and do as you suggest - provide it as a GEX and also provide the source code in a separate gm81 file. The autocomplete/help line features will be very useful!


I've got another question for you to. Are there currently any popular GUI API extensions? I've searched the forum but there doesn't seem to be much save little pieces here and there. I ask because that's what mine is - a GUI Application Programmers Interface. Rather than just provide a couple nice objects like buttons and such (which it will have) - it provides a whole new coding interface for designing complex GUIs with ease. It will also, itself, be extensible. Sound like something you might use for your projects?

d&d is for Drag & Drop, the little boxes that do things in the event editor. LIBs create those boxes instead of creating gml functions, so in your case, since you tend to use gml for everything, a LIB isn't really useful.

Before you dive too deep into your project, I would take a look at what is out there. A lot of the time, it has been done, and done dead. Take a look at Game Widgets by B&B Gaming for example. It is all gml and it doesn't come as a gex, rather as a bunch of scripts. The reason it was left like that is because a GUI isn't something you can just GEX up very easily while allowing massive customization, though with some work it could be done. You'll also notice that though the script names show in the autocomplete, you get no help with arguments on the help line. On the other hand, there are a TON of scripts there, and so it would be quite an undertaking to convert it all into a GEX.

The GUI extension you describe could be useful, but for me, I would need easy methods to customize it, have things move around if need be(for pretty menus) and so I tend to prefer to simply create what I need for a single project, reusing code where possible. But it could be useful.

[iam1me]

d&d is for Drag & Drop, the little boxes that do things in the event editor. LIBs create those boxes instead of creating gml functions, so in your case, since you tend to use gml for everything, a LIB isn't really useful.

Gotcha! GEX it is!

Before you dive too deep into your project, I would take a look at what is out there. A lot of the time, it has been done, and done dead. Take a look at Game Widgets by B&B Gaming for example. It is all gml and it doesn't come as a gex, rather as a bunch of scripts. The reason it was left like that is because a GUI isn't something you can just GEX up very easily while allowing massive customization, though with some work it could be done. You'll also notice that though the script names show in the autocomplete, you get no help with arguments on the help line. On the other hand, there are a TON of scripts there, and so it would be quite an undertaking to convert it all into a GEX.

That's a cool project. It's different from what I'm intending though (though related) - my GUI API won't simply provide widgets to use here and there but will provide an interface for developing your entire GUI, providing organization and flexibility that you can't achieve with just the built in GML features. Although, I might see if he would allow me to rewrite/package his widgets into my project - that would certainly save me lots of time.

The GUI extension you describe could be useful, but for me, I would need easy methods to customize it, have things move around if need be(for pretty menus) and so I tend to prefer to simply create what I need for a single project, reusing code where possible. But it could be useful.

I'm intending for it to be very easy to customize I even have custom event management. Every event has an Event_Args instance associated with it (which you can create your own version of/extend the one created easily) which is placed on a global EventStack. This allows you to pass around as much data for an event as you could possibly need - without having to use global variables everywhere. Every (local) event has an event listener list to which you can add any number of event listeners (event listeners have a variable in the form of "on_eventname_script" which points to a script to execute)

It'll probably be another week or two before I have a demonstration available - but keep yours eye out so you can let me know what you think!


I had another question about GEXs: can I hide some scripts from the autocomplete feature? I have many scripts which aren't meant to be directly called by the user - but which are essential to the GUI API. It would be extremely useful if I could make it so that they only see scripts that I want them to see!

Edited by iam1me, 12 February 2012 - 05:50 PM.

[kburkhart84]

OK, I'll watch for your GUI stuff...

Yes, you can easily have functions be hidden from the autocomplete and help line. In the extension creator, where you add functions(either dll or gml functions) there is a check box that says hidden. Then, the function is not visible. It can still be called from the other extension functions, and I think it can still be called by the user, but they would have to know the exact function name and arguments to use it properly.

[iam1me]

OK, I'll watch for your GUI stuff...

Yes, you can easily have functions be hidden from the autocomplete and help line. In the extension creator, where you add functions(either dll or gml functions) there is a check box that says hidden. Then, the function is not visible. It can still be called from the other extension functions, and I think it can still be called by the user, but they would have to know the exact function name and arguments to use it properly.

That's perfect - thanks for all your help