AGS 3.0 Final - it's been a long road

[monkey0506]

I've gotten one of those from every game I've converted and had no problem with removing it because I never used the IE anyway (things with those initials are just the devil ).

Just to be on the safe side, you might try commenting out the import line in your script header and the variable itself in the global script. Next click "Build->Rebuild all files". That way it will recompile all your room scripts. So long as you don't get any compile errors then you're safe to remove the lines altogether.

[Cinfa]

@ Chris: Just a thought, though it should probably go in the 3.01 wishlist: I really like the tabbed scripts and rooms, but find it slightly annoying that I have to right click to close them. How hard would it be to implement an "X" close icon on the side of the tabs, like in Firefox?

You can close tabs with ctrl-F4 or ctrl-W, I think much faster than a dedicated button, but it's just my opinion.

[Pumaman]

However, I'm not absolutely sure, but it could be that the fast-forward runs into a set of dialog options if the cutscene is skipped at the right time where it's past the skip test but not yet past the options. I can script myself around this though, if it indeed is the case.

Ok, well do let me know if you can confirm whether that's the case.

When I click on file/preferences I get the following error:

Error: Value of '0' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'.

Hmm, did you set the Tab Size to 0 at all, maybe in 2.72? It shouldn't be able to get set to 0, but I'll add a check in to reset it to 2 if this happens.

I really like the tabbed scripts and rooms, but find it slightly annoying that I have to right click to close them. How hard would it be to implement an "X" close icon on the side of the tabs, like in Firefox?

Somebody else asked about this a while back, but there didn't seem to be much enthusiasm for it. As Cinfa says you can use Ctrl+F4 or Ctrl+W to close the tab, and there's an X button on the right hand side of the tab strip.

Oh, I've got one more question that's been nagging me, but I keep forgetting to ask. When I imported my game from AGS 2.72 to AGS 3.0, this script was added to the top of my global script:

// Automatically converted interaction variables
int IntVar_Global_1 = 0;
export IntVar_Global_1;

Well, as the comment says it's an automatically converted interaction editor variable. I believe the default game templates in AGS 2.72 come with a "Global 1" interaction variable so this will probably get imported into most people's AGS 3 games, but if you weren't using the interaction editor you can safely delete it.

As monkey_05_06 suggests, do a Rebuild All after commenting it out to make sure no room scripts are using it.

[NiksterG]

Ah, got it. I will try that. If anything goes wrong, I'll be sure to let you know. 

I didn't realize there was an X in the corner for closing tabs. I was looking at the tabs themselves for a close button, which IMO is more intuitive. However, I didn't know about the key combinations, which are definitely very helpful. Thanks for that info!

And one last note: I really appreciate how much work Chris is putting into this editor. I think this is the greatest game editor ever made! Keep up the great work, Chris!  8)

[RickJ]

Error Re-size GUI
When resizing a gui get invalid dimensions error.  I am setting the dimensions in a module and have tried hard coding the dimensions.  There are two guis and somewhere along the line the first one started working without giving the error.  The second one does however.   I reported this previously and you couldn't replicate the problem, so here is the game that has the problem.  Press the F1 key to open the second gui and cause the problem.

Ah, heh. The problem here is that your gLogin GUI is set up as being 321x300 in the editor. This doesn't get validated until this line of your script:

guix.Height = Game.SpriteHeight[guix.BackgroundGraphic];

at which point it validates both the width and height and finds that 321 is too wide. It's a bit misleading, so I'll try and make the error message more useful. The fix is to just change the GUI size in the editor to 320x200.

Hmmmm,   It's confusing because if there is no attempt to change the height there is no error and everything seems to work.  Why is it necessary or desirable to validate the old or previous height (or width) value anyway?   Why not just leave well enough alone, discard the old values and then do whatever is done using the new ones?

I am setting the gui height larger than the background graphic so that there is room to place gui  controls that are dynamic or programatically manipulated at runtime.  In this way they are visible at design time and do not interfere with the placement of the gui's visible/static controls.  When the gui is displayed it is resized to the dimensions of the background graphic to hide the dynamic elements.    There they remain hidden until a script moves them into view to implement some feature such as opening a drop down list or setting focus to a data entry field.   

When working with 320x240 resolution gui's tend to take up most of the screen so it would be useful be able to create guis with dimensions greater than the screen width/height so that there is a place for dynamic controls as described above.   It would be great if AGS could accomodate this technique in some way.   

[Pumaman]

When working with 320x240 resolution gui's tend to take up most of the screen so it would be useful be able to create guis with dimensions greater than the screen width/height so that there is a place for dynamic controls as described above.   It would be great if AGS could accomodate this technique in some way.   

Hmm yes, I can appreciate this. The reason the size is validated is to stop people accidentally setting the size to 640x480 (which would be easily done because of AGS's somewhat confusing co-ordinate system) and then ending up with a huge off-screen GUI taking up memory and resources without them realising it.

I'm not sure what the best way to balance this is against the fact that sometimes it's useful to have the GUI slightly bigger so that you can host off-screen controls or scroll it around the screen.

[El_Yind]

Hi.

This are some bug/modifications that would be nice to do

*When you change the description of a room, it doesn't update the list
*When you create new subfolder in sprites or views you can't move the existents views into the new folder, some kind of copy/cut/paste would be nice
*When you are editing a room, and you change to do some walkeable areas or walk behinds all the objects hide and you can't see where they are, it'd be nice if there were a checkbox where you could hide or show them.
*Add 5 Ctrl+Z level (I made doble click and I lost all because I fill the screen twice) it should have a few more undo levels
*Add windowed mode the posibility of zoom like 1x, 2x or 3x I have a 1280 resolution and I work with windowed because it's easier but.. it's really small and I can hardly recognaize the things
*Add editing room zoom, it can't be so hard, just a + button and a - button.
* (I don't know if you are working on it but...) I don't know what is the use of the break point in AGS it should allow you to see a value when you stop the code at least that is what I do when I program in VB.NET and It helps a lot when you are looking for an error or just seeing what a function return in a easier way.


Well that's all for now. If I figure out something else I will tell you.

Thanks for the great new version!

[Cinfa]

• When you create new subfolder in sprites or views you can't move the existents views into the new folder, some kind of copy/cut/paste would be nice
• Add 5 Ctrl+Z level (I made doble click and I lost all because I fill the screen twice) it should have a few more undo levels
• Add editing room zoom, it can't be so hard, just a + button and a - button.

I totally agree.

EDIT:
ok, the zoom thing is a bit tricky, but the folder thing could be really useful.

[Rui 'Trovatore' Pires]

Well, yes, of course, everybody knows zoom is as easy as adding a + and - button, just add them and you get instant zoom. I did it in AGS once - a button with "+" as text, and another with "-" as text, and you know what? In-game, whenever I clicked them, the main screen zoomed in and out. Amazing. It's like the "Make my Game" feature, except this one really works.

[Gilbert]

This are some bug/modifications that would be nice to do

Please don't post the same thing in two threads. My suggestion is that you modify these two post so the one here contains only bug reports, as V3.00 is close to a release and I think feature requests are not very appropriate now, while the post in the other thread should contain only suggestions. If you want to keep their contents this way I may delete one of these posts so only one is kept.

[RickJ]

Hmm yes, I can appreciate this. The reason the size is validated is to stop people accidentally setting the size to 640x480 (which would be easily done because of AGS's somewhat confusing co-ordinate system) and then ending up with a huge off-screen GUI taking up memory and resources without them realising it.

I'm not sure what the best way to balance this is against the fact that sometimes it's useful to have the GUI slightly bigger so that you can host off-screen controls or scroll it around the screen.

Presummably you are thinking about making an additional validation at game start since the current method of validating the property grid dimensions only when attempting to change to new dimensions does not prevent the above situation from happening nor does it make much logical sense either.   

Perhaps the validation routine could just clamp the GUI size to the screen resolution instead of generating a runtime error.   This would have no visible effect except that less resources would be unknowingly used or wasted.   

[Shane 'ProgZmax' Stevens]

I'm not sure what the best way to balance this is against the fact that sometimes it's useful to have the GUI slightly bigger so that you can host off-screen controls or scroll it around the screen.

Well, one option I see is just to trust users of ags to deal with GUIs themselves (and the consequences for being dumb and having a massive gui floating offscreen).  Alternatively, you could just have the engine auto-invisible any guis that are COMPLETELY beyond the viewport visible area (simple rect comparison)?  Surely no one would object to making a gui no one can see invisible, and it would be a simple matter for the user to set it back to visible when they move it within a viewable area.

[SSH]

How about an "expert mode" that turns off some checks like that one?

[Shane 'ProgZmax' Stevens]

Something I noticed yesterday:  why did you change the palette 0 option in sprite importing only to work on games < 16-bit?  I can no longer import my 8-bit sprites that have no transparent areas as a result (rectangular inventory items, gui components,etc), which is rather daunting.  Items like this:



no longer import properly.

I design all my games in 16-bit mode by default so I can take advantage of transparencies/lighting and such (I'm sure I'm not the only one).  Could you please reset this so it works even in the higher color modes again ?

[OneDollar]

Isn't that what the "No transparency" transparent colour option is for?

[Rui 'Trovatore' Pires]

Re whole GUI thing, I tend to agree that it's best left for the user to decide. After all, the great thing about AGS is it's versatility, and too many fool-proofs like this might, in the long run, hinder some of that versatility. Warning is good, checks is good, but in the end AGS has to trust that the user knows what he's doing. And if he doesn't, it's his own fault, really.

[Shane 'ProgZmax' Stevens]

OneDollar's post made me go back and check my version, and I discovered something odd...it was still listed as RC3 even though I uninstalled BOTH rc3 and rc4 to get rc5.  I was installing them back to the same folder, however, so there must have been some lingering files left over.  Now that I have uninstalled ags again and reinstalled to a new folder, the option OneDollar describes is there and it works wonderfully - so false alarm, I guess!  There must have been some lingering problem with rc3 or rc4's installer, but hopefully that's fixed now.  Sorry about that!

[Pumaman]

*When you change the description of a room, it doesn't update the list

This seems to work fine for me, what exactly are you doing?

*Add windowed mode the posibility of zoom like 1x, 2x or 3x I have a 1280 resolution and I work with windowed because it's easier but.. it's really small and I can hardly recognaize the things

That's what the Graphics Filter options in Setup are for. You can choose a 2x or 3x graphics filter to provide this.

Thanks for your other suggestions, however I'm not really taking suggestions for 3.0 any more. For now, please post these in the wishlist thread instead.

How about an "expert mode" that turns off some checks like that one?

As the behaviour we're talking about hasn't changed from 2.72, I'm not going to risk breaking things by messing with it now. But it's certainly something I can consider for the next version.

[Pumaman]

Right, 3.0 Final is now uploaded.

Please try this out guys and make sure it's stable.

Assuming there are no major problems, in a few days I'll make it official and publish it to a new thread, to the website and make a ZIP version available.

[Rui 'Trovatore' Pires]

Wow. 6/7 months around this new engine.

Time sure does fly. And in the meantime CJ has been listening paitently do our every word, and putting everything in its place.

CJ, you, sir, are "da" proverbial "man".

EDIT - BTW, there's this oldish issue -

I'm working with larger than normal character sprites 591 tall by 351 wide (temp size for testing purposes) and when I go to preview the animations, the preview window is not able to show the whole view at once. Here's a picture of what I'm seeing:

It's a reasonable point, 2.72 did this as well. I guess ideally it should scale down the sprite to fit the preview window.

I'd just like to point out that this is noticeable in the demo game - not very good form to present a demo game where you have an animation of a closed door opening it's hatch and upon previewing find you can't see the hatch, which is what is animating.

Then again, the Demo Game is unfinished, and that's not very good form either. I feel tempted to suggest replacing the DemoGame with OpenQuest.