Editor Wishlist/Coordination

[RickJ]

@tzachs:  If I understand correctly, the button we are talking about here would compile the game and transport the player to some specified room.   How would AGS know in which room and at which coordinates to place the character,  if he should be visible or not,  and what inventory items he should have?   It would be necessary to pop-up a dialog box to allow the user to enter the above information.   In the very least it would be necessary to enter the room number to be tested.   So - honestly - no, I doubt I would find much utility in such a button.   

@monkey:  I don't see any advantage of compiling only one room.   Currently only the rooms that have changed are compiled and so if one is working on one room at a time then AGS currently produces the same result.  On the other if changes are made in multiple rooms isn't it better to compile everything that has changed; the programmer would get immediate feedback would likely know where to fix any errors that occurred?

=============

I think time would be better spent improving the GUI import/export mechanism to include code/module and other resources and so that it could easily be "unimported" when no longer needed.  This would make it a little easier to create and use reusable debugers.

Really, the most important thing is to design code in manner that makes it easily testable.  There is no magic button that will do it for you.

[monkey0506]

I think that for the purposes of testing things like scaling, walkable areas, and room events that it would be reasonable to support the compilation of a single room for debugging and testing purposes, with no availability to go to other rooms. This would not simulate the actual in-game values of global variables, player inventory, etc., it would just let you see that room in action. The reason I suggested an alternate and additional script would be so that you could more easily simulate that when testing the room.

The reason for my suggestions in addition to the layout that tzachs provided is that it would avoid the need for the pop-up dialog that you're talking about. Compiling only this room would avoid a lot of the issues you perceive in this suggestion. I'm not saying that when building the actual game EXE that other rooms shouldn't be compiled, I'm talking only about testing a single room.

Rick, I think this suggestion has the most potential benefit for those that have extremely long games. This isn't so much about testing the in-game code (as far as I'm concerned) as it is more about testing the design and layout of the things within the room itself. That would require a fair bit less "magic" than what you're thinking of (which is closer to the original idea, which tzachs' is rather different from).

As far as GUI import/export including the GUI code, I think that would be great, and should probably be given a fairly high priority. I also would like to see the option of having standard event handlers appear in other scripts than just the global script. That would make it possible for GUIs to be able to import their own code much easier.

[RickJ]

@monkey:  My hangup was having a button that doesn't do anything useful unless custom script is attached.  However now that I think about it I'm intrigued.

What if the TestRoom button compiled and executed as is done now except that the PC starts in the current room and places the PC on a walkable area.   This part is uninteresting, unnecessary, and not worth much consideration from my point of view.   

However,  suppose that in addition and event handler called something like RoomTest(...) was also executed before any of the other event handlers?   There could also be an #iftest macro as well.   Now this would be interesting because people could leave test code in their source permanently.   If debug mode is not set in game settings then the test code would be omitted from the exe and would have no affect on release  versions.

Yes,  I would find use for something like this and it would not be complicated to implement (probably a bit of work though since both editor and runtime would need to be changed.    I'm persuaded...

[Knox]

@tzachs: I figured you would most probably be the one deciding if this is doable:

Do you think we can make the "edit custom properties" window resizable? Right now (for me anyways, windows 7 x64), it isnt resizable...since I currently have many custom properties, its a biatch having to scroll through a very small window!

ps: Do you think there will be future possibilities to have a whole menu section for "saving/loading user layouts"...so you can save a layout as a .agsUI file (or something) + load it in other copies of AGS on different computers (it would save window sizes, locations, font, template colors, preferences, etc).

[tzachs]

@monkey_05_06 & RickJ: I'm glad we've come to an agreement (well, sort of)!
I agree that the "TestRoom" event handler would make it even more useful.
I'm also very much for the export GUI as a whole with its code and for separating event handlers linking to other files (I wonder if the linking is done in the editor source code or in the native though).

@General_Knox: Yes, both of these are doable. As I told cat just a few posts above, I plan to integrate a docking windows library, which will make all windows being able to switch between docking to a certain area of the screen (which is resizable), or a floating window (which is also resizable). Plus, this library also comes with support for loading/saving the layout, so it will at least help incorporating some of your suggestions.

[Knox]

@tzachs: Nice! Do you think that it's also possible to drag tabs to change their order so a tab that's last can be grabbed, and dropped into the first position?

[tzachs]

I think that the library I was talking about have this functionality in it.
If not, then it is still probably possible, but might be complicated since I'm not sure if the default dot net tab control supports this out of the box.

[barefoot]

Hi

I think the idea of room test/debug is rather a must have..  Like if you make a new lable, gui etc then you should be able to test it without having to play through lots of other rooms first or restarting player in that room... Definitely a must..

Possibly an updated cursor when adding/taking away walkable/region/hotspot as it's sometimes almost impossible to see cursor (crosshair) without zooming right in..



barefoot

[Ryan Timothy B]

I'm not sure if this is both an editor feature and engine feature, or solely editor.

How possible would it be to have the function pointer for something like "Any click on character" to allow to pass variables? So you can have it point to: whatever(1, 2, 3)  instead of just: whatever

I think it would be very handy. Now get to work on it!

Edit: I realize that a small request like this requires tons of work. Or it may be possible to already use the script error checking that AGS already has built in. Otherwise you'd have to manually check if it's a string, integer, enum, global variable, etc, etc. Also checking if the variables in the function are asking for the same type, and if there isn't too many variables being sent or too little.

[Kweepa]

Erm, what are these variables that you want it to pass?
Why not just use globals instead?

[Wyz]

I guess he means function pointers like c has them. This can be useful for callback functions, lets you do stuff like this:

Code: ags

int CompareInt(int a, int b) { return (a-b); }

int array[];

// ...

Sort(array, CompareInt);

But again, you could just make a function SortInt.

[RickJ]

I've wanted to have function pointers forever as they can be very useful especially in the context of modules.  Currently there is no mechanism for a pre-written module to call user written functions.   Pointer to function would allow user defined functions to be assigned module events or to over-ride generic or virtual module functions.   It would also make jump tables, case functions etc possible.   

Currently AGS mechanisms do not provide for indirection or dynamic assignments of function calls making the above very difficult or impossible.

[Kweepa]

My question was not "durr, what is be function pointer?", but rather what would the parameters passed to the "Any click on character" callback be? The engine calls the callback, so the parameters have to be defined by the engine. You can't just add random parameters.

I'd certainly find a use for general function pointers.

[Ryan Timothy B]

My apologies. I thought it would have been understood quite well.

I didn't actually mean for it to be on "Any click on character" only, it was only used as an example. I meant for it to work for all buttons, objects, characters, etc.
One quick example I can think of, you have a 10 GUI buttons and you wanted them all to point to a single function with variables (I honestly don't know the correct terminology for this) you'd have to manually script them yourself.

Code: ags

function bButton4(GUIControl *control, MouseButton button)
{
  Whatever(1);
}

function bButton10(GUIControl *control, MouseButton button)
{
  Whatever(2);
}

function bButton17(GUIControl *control, MouseButton button)
{
  Whatever(3);
}

Instead you could just simply point the button OnClick to:  Whatever(x)
x being whatever you want. Whether it's a constant int, or a variable that changes within the game, like (a completely random example) Player.Y

It basically saves you from having to create possibly dozens of identical function which just points you to the same function anyway. It's not an incredibly important addition. You can argue it if you want, it's only a suggestion, what do I care.

[monkey0506]

You could simply link all the functions to the same click event handler (copy+paste or type in the name manually), and then do this:

Code: ags

function btnWhatever_OnClick(GUIControl *control, MouseButton button)
{
  Whatever(((((control.ID / 10) - 5) * 12) / 32) + 8);
}

[Ryan Timothy B]

You can point it to the moon and back, it still isn't as efficient as just placing: Whatever("Hello", 10, 84, player.x, player.y, eBlock) right inside the editor pane instead of actually creating a master function that points to another function. When instead you could manually change each item right inside the editor pane for that object, character, button, etc and in most circumstances they wouldn't be identical.

But even with your solution, you still need:

Code: ags

if (control.ID == 5) Whatever(16);
else if (control.ID == 12) Whatever(11);
else if (control.ID == 1) Whatever(27);

You'd still have to look up which ID that is revering to afterwards if you wanted to change something in the script. Of course you could just simply comment them, or you could just create multiple hundred functions if needed as I showed above to have it ultimately organized but very redundant in function count.

[monkey0506]

Or instead of referencing the ID you could treat the pointers as pointers and reference them as pointers:

Code: ags

if (control == btnWhatever1) Whatever(1);
else if (control == btnWhatever2) Whatever(2);
else if (control == btnWhatever3) Whatever(3);

Which makes the code significantly more readable.

What I'm trying to understand, which is also what Steve was asking about, is what additional data is it that you're realistically wanting to pass through to these handlers?

Short of doing something with a variable argument list, I don't see how you would expect to be able to pass random data like that into the event handler. Seeing as AGS doesn't allow direct memory modification (like C++), and doesn't have a foreach keyword (like C#), and doesn't have a way of generically checking the size of an array (dynamic or otherwise) then I don't see how you would be able to fetch the data back. So not only would the engine have to be modified to include "..." as the final parameter of every event callback, we'd also need further modification to actually be able to make use of that data, and all of it for what?

That's what we're getting at, is what is it that you're wanting to pass through to these event handlers??

[Ryan Timothy B]

I'm still believing that you're confusing what I'm saying with something much more grande. You're making it sound like you could pass a gigantic list of random parameters into a fake function or something. But I'm speaking of passing variables into a function that has parameters that are already defined with an already existing function created within the global script or imported to the header script of a module.

Global script:
function Whatever(int A, int B) { }

Then while typing in the editor pane for the OnClick function, as you type: Whatever   AGS pops up the: function Whatever(int A, int B)
and you can pass whatever variable or value into those fields. Having the same error checking as AGS has with scripting, it warns you if the function has too little or too many parameters or the data types are incorrect as you compile the game.

I don't have a very good example off hand at the moment for where this is ultimately handy, other than just avoiding function after function. And depending on how AGS stores the data in how it points to these functions that are entered into the event handler, that's where it's a fine line between difficult to add or nearly impossible. Sounds like fun doesn't it?

[Khris]

While I understand the request I, too, don't see the benefit, especially if weighed against rewriting that part of the editor.
And I, too, am having a hard time of thinking about an example where this would be useful.

All I can think of is for instance a keypad consisting of 11 or 12 GUI buttons, but if you create the buttons so that the ID reflects the label, you won't need 10 else ifs. One function is going to handle all the button clicks, and all it needs is the control pointer.
And what parameter would you like to include in a character's interact function or the like? Even if you came up with a situation where each of those needed some arbitrary parameter(s), why not put them in Custom properties?
Or if you wanted to really cut down the number of functions and coded your game so that a single function is going to handle all NPC interaction, again, what would you put in there? You can find out the character and mouse.Mode etc. perfectly fine using existing commands, what else do you need?

Basically, this discussion is entirely moot until you provide us with an actual situation where this would come in handy, IMO.

[RickJ]

@Steve:  Didn't intend to imply anything at all about your comments.   I just wanted to express my interest in having function pointers.  I agree that function pointers could be put to good use.

@Ryan Timothy:  What you describe would be very useful in creating modules that call user functions that are not known or knowable when the module is created.  Consider a module that generates or manages events or states.  When an event occurs or a new state becomes active then the module is to perform some action (presumably by calling  one or more functions).   The problem is that these functions are unknown when the module is written and would be different for every use of the module.  Module pointers would allow the user to tell the module which functions to execute when specific module events occur and which parameters arfe to be passed.

Personally I would like to have function pointers to recreate the Thread module I wrote a couple of years ago and lost to a HD crash.   This module allows one to create and execute concurrent threads in an AGS script.   To do this a byte code interpreter is required to execute AGS builtin functions so as to manage/emulate script blocking.   Function pointers would make the byte  code interpreter much cleaner and efficient.

@Monkey:  A better example of what Ryan Timothy is talking about would be something like the following.   He defines some arbitrary function with some arbitrary parameters.  The function knows what what the parameters and what they are used for but not the actual variable references.  

He wants to use a module that manages some kind of events.  He defines an event named "SomeEvent", assigns a callback function, and specifies the conditions under which the event is triggered.  

Code: ags

// Global or Room Script

// Some function for my current game
function SomeAction(int x, int x) {
    // Do something
   cEgo.Walk(x,y);
   cNonPlayer.Walk(x+10. y-10);
}

// Use a cool event module written by monkey years before
CoolEvent SomeModule;
SomeModule.Event("SomeEvent", SomeAction(160, 100), ...);