Editor Wishlist/Coordination

[Icey]

A few more Room transitions.

[Knox]

It would be nice to have a random field for view frame delays...as in, instead of putting a fixed number, the user can type in "1-3" or "33-55" and AGS will choose randomly a delay number from what is typed in (we can do this manually but it would be cool to have it in the editor already).

Also, I is it possible to have a checkbox for buttons that says "Always resize to new Sprite"...that way, if you have a button that is 30x30, and you change it's graphic to a 45x45 sprite, the values for the H+W will update to 45x45...right now you have to manually change those values after changing the sprite.

[monkey0506]

For buttons if ClipImage is false, doesn't it already resize if the graphic is changed, at least changed to a larger graphic? It..used to..I thought.

[Matti]

Yes, it does resize automatically.

[Knox]

Well when you set the sprite number the 1st time it does resize automatically, the 2nd + times, in my case (just retested), it doesnt resize automatically if the next sprite is smaller than the 1st

[monkey0506]

That's something that could probably be fixed in the editor, but for now if you're using a smaller sprite you could set it to sprite 0 first.

[Joe]

My suggestion: auto-scale characters when they are positioned in scaled walkableares in room editor

[tzachs]

My suggestion: auto-scale characters when they are positioned in scaled walkableares in room editor

I've looked into that some time ago.
It seems that we need to wait for open sourcing the native, since it requires changing the API to allow scaling to non-whole numbers.

[dbuske]

What the editor really needs is a way to test a room without having to go through every room.
For a long game it is a real pain testing.

[monkey0506]

"Testing a room" is not an editor process at all, it's a run-time process. Anything you do while your game is running (during run-time) is part of the engine, not the editor. The editor only deals with design-time and compile-time.

Also, I just answered this in the thread you created. I didn't look at the timestamps, and I'm on my phone so I won't right now, but this essentially constitutes posting the same thing twice. Either post by itself would have been sufficient, there was no need to do both without a response.

Okay..I looked and you posted here six minutes after creating the thread. Why would you assume that just because an answer wasn't provided within six minutes that the feature must not exist at all?

[dbuske]

I made a quick assumption and turned out correct. I searched everywhere and didn't find a function for running just one room.
I thought it would be a good thing for the editor to be able to do.

[monkey0506]

What do you mean you turned out correct? What you want to do is going to require work on your part, period.

I don't see why you think the editor having the capability to compile a single room, but compile it in such a way that it is based entirely on the game logic of the rest of the game is something that "would be a good thing". That's absurd.

If you need to simulate having played through the game in the script, then script it, but expecting AGS to do that for you is ridiculous.

Oh, and unless you're talking about compiling the room to a separate executable, this would still be an engine request more than an editor request.

[dbuske]

All I was talking about is just testing one room to save the time of having to go through every room.

[Snarky]

The debugger already lets you jump to any room, so you don't have to go through all of them, if that's all you want to do. The problem is that usually there's some setup that needs to be done so the game is in the right state, and that's not something the editor can telepathically deduce, it's embedded in the game logic.

[monkey0506]

Yes, and by "test one room" you mean play. The editor is for designing and compiling only. Not playing.

I know what you meant, and I'm saying that there's not really a lot that can be done to simplify the process. The Debug function allows you to teleport to any room by typing it in so you don't have to manually script it. Anything beyond that (such as simulating a certain game script state) would have to be manually script anyway. So this doesn't even make sense as an engine request either, because the Debug function already supports this (in so far as it is possible).

Edit: Snarky posted before me, and maybe he worded it a bit better than I have. To elaborate on what he said, your game logic is entirely customized, and controls the game script state. The script state is entirely dependent on the global and room variables that have been set as the user plays through the game. If you want to simulate the script state of a given point in the game, then you're going to have to script that manually because it is based entirely on custom code.

[tzachs]

Yes, and by "test one room" you mean play. The editor is for designing and compiling only. Not playing.

I know what you meant, and I'm saying that there's not really a lot that can be done to simplify the process.

Well, not necessarily.
Adding a button to the room editor "Test Room" can be a useful shortcut to the "teleport" debug function, which makes this a combined engine&editor feature.

[RickJ]

I'm too lazy to press a button on every iteration!  Wise up and just put a change room debug statement in Room0 like everyone else.   

Being even more clever why not add a test function to each room that would execute every time the player entered the room.  If a global variable called "Test" is set true then if would continue to execute and exit if "Test"  is false.   What would it execute?   "Whatever is necessary" to test the room such as giving inventory articles or setting other variable states.

Why doesn't it make sense to make this a feature of the editor?   As everyone explained above the essential part is the "Whatever is necessary to test the room" bit that can only be determined by the programmer and is likely to change quite often and on programmer whim.

IMHO what is being  proposed is in the same class of feature as the "Make my game" button.   

[cat]

tzachs, a special request for you: Would it be possible to make the search result/usages window resizeable like the projecttree/properites window on the right side? (btw, thanks a lot for these two features!)

[tzachs]

@RickJ: Let me ask you this:
* Wouldn't you say it's more intuitive for newcomers to have this button in the room editor, than having to use the debug function?
* Isn't it more convenient? If the button was there, wouldn't you use it?
I know I would use it on a daily basis.
And while it's true that some rooms will not work out of the box without some work on your part, a lot of times it would be perfectly suitable. If I just want to test walkable areas and scaling issues, then this for me is a productivity enhancer, and really not at all comparable to "Make my game" button.
Also, unlike the "Make my game" button, this feature is actually doable (while obviously not the most important feature on the list)...

@cat: Thanks, and it's possible. The reason I didn't do it in the first place was because I'm planning on adding docking capabilities to all windows which will also make them resizable. If I'll see that it's too complicated for me, then I'll do this as plan B.

[monkey0506]

tzachs, you actually make a reasonable argument for the "Test Room" button, but I think my points from before remain valid. I think that a "Test Room" feature would not be absurd as a debug-only feature (no standalone EXE). It essentially would compile the entire game, minus all other rooms except this one, and would automatically set the player to start in this room.

All sprites, global variables, scripts, dialogs, etc. would be available just like normal, you just wouldn't be able to use ChangeRoom for example.

I'd actually like to propose that in addition to this Test Room feature that rooms have a "roomX_debug.asc" or "roomX_test.asc" (or something along the same lines) that would only be compiled in the event of using the Test Room. It would have available any of the linked room functions, standard functions like on_event, and custom functions. Any functions in both the debug and normal room scripts would be merged with the debug script code on top.

Given this setup I'd say this could be a very useful feature. However, it's pretty drastically different from the situation that was previously described (at least insofar as I understood it).