(Moderators, please do not sticky this thread)
Hello,
AGS 3.0 is the next version of AGS and has undergone significant changes.
It has been in beta for a long time, but is now almost ready to be released on the general public.
What I'd appreciate is if you guys that don't normally use betas could give the latest version (Release Candidate 3) a try and see what you think.
What I'm mainly interested in is if there's anything confusing or misleading that you can't work out how to use in the new version -- if so, I can either change the way it works or mention it in the upgrade guide.
You can download it from the first post in this thread:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31519.0
Please make a backup copy of your game to try it out on, otherwise you'll be permanently stuck with AGS 3 whether you like it or not ;)
Thanks for your feedback. As you can appreciate at this stage there isn't much scope to change things, but this is an opportunity to ensure that anything confusing is properly documented.
Cheers,
CJ
Sorry if this has been asked before, but this is my first time trying 3.0:
What happened to right-clicking to copy and paste coordinates to the clipboard? I hope it's not removed because it was a very useful feature. I can't figure out how to do it in the new version.
It's very impressive! I would consider myself as extremely familiar with the ins-and-outs of 2.7, so jumping into 3.0RC3 is going to take a little getting used to. I put in about two hours in the new editor today for the first time.
Aesthetically, I love the new editor. No complaints there.
It imported the game that had previously been built in 2.7 with no problems. Running it worked exactly as it had before.
Useability-wise, the ability to have multiple scripts open at the same time is very very appreciated and is the thing that stood out as the biggest improvement. Two comments about the scripts:
-I missed the old menu items that I used to use to jump straight to, for example, the repeatedly_execute or game_start section of the script. Likewise, I used to sometimes use the room-menu "i" button to jump straight to a specific section of the script rather than just opening the script and navigating down to where I wanted to edit. Maybe this functionality is in there, but it didn't jump out at me during my short use. This is minor, since I can just use the search function. Which brings me to:
-I liked the old search function better, automatically hilighting the first instance and closing the search dialog, then using F3 to go to the next. Now, when it highlights an instance of the search term, the dialog stays open and I can't scroll around the script to verify if this is the instance I'm looking for. I have to manually close the dialog, then scroll around, then open the dialog again if it's not what I was looking for. (I do this a lot since I rarely, if ever, comment code... my old CS teachers would be so disappointed)
Most of what I was doing today involved importing new sprites, and a few things bugged me about that:
-Importing with the "palette index 0" as the transparent color apparently no longer works with high color games. It used to, and was a convenient way to not have any transparencies on a sprite (when the sprite is meant to be a rectangle). I couldn't find a way to import the sprite with no transparencies, other than adding another row of pixels to the sprite, then importing it with that row being transparent, and then using the sprite cropping. That's way more steps than it used to be. Is there a way to do this that I missed? Can we go back to the old way? Or can there be an option for "no transparency" when importing in hi-color (replacing the non-functional palette index 0 option)?
-There's no longer a quick import from clipboard option when right-clicking on the sprite window. Now, to import from the clipboard, I have to go through the dialogue where all I do is click the "get entire image" button. When bringing in a bunch of sprites one by one from the clipboard, this slows me down. I liked the old option that skipped that window and just pasted.
-Losing the ability to drag sprites to rearrange them in a folder or to drag them to another folder is a big loss for me. Much harder to organize my sprites unless I give it adequate forethought, which I usually don't. Sorely missed.
In general, I found getting to the part of the Room editor that I was looking for a little confusing, but I'm sure I'll catch on quickly.
Also, when 2.7 would get to the point where my game took too long to compile for every test, I would start quick saving with ctrl-a and then running the engine straight from the game's folder to save time. I didn't see a quick save option, but I didn't have time to mess around with saving and compiling much, maybe there's a way to do something like this in v3. I hope so.
When I try to run the game in Direct3D mode, no matter what resolution I chose, windowed or no, it tells me that my computer doesn't support that resolution. But I usually don't have any problems running games or other programs in 640x480 full screen. I'm running it on a MacBook booted into Windows XP via bootcamp. Not sure what's up there.
Those are all the observations I have from my first couple hours with it. Hope it's helpful.
Imported a sample from 2.72 and it looks like a row of pixels is missing in my dialogs first row, whatever the first row may be. Had no problems with that in 2.72.
Problem dissapears when I disable "Use GUI for dialog options".
(http://www.tmk.edu.ee/~cino/ags/Clipboard01.png)
(http://www.tmk.edu.ee/~cino/ags/Clipboard02.png)
(http://www.tmk.edu.ee/~cino/ags/Clipboard03.png)
I'll look into it a bit more, maybe I did something wrong.
Thanks for the feedback so far.
QuoteWhat happened to right-clicking to copy and paste coordinates to the clipboard? I hope it's not removed because it was a very useful feature. I can't figure out how to do it in the new version.
Quote-There's no longer a quick import from clipboard option when right-clicking on the sprite window. Now, to import from the clipboard, I have to go through the dialogue where all I do is click the "get entire image" button. When bringing in a bunch of sprites one by one from the clipboard, this slows me down. I liked the old option that skipped that window and just pasted.
Quote-Losing the ability to drag sprites to rearrange them in a folder or to drag them to another folder is a big loss for me. Much harder to organize my sprites unless I give it adequate forethought, which I usually don't. Sorely missed.
Thanks for the feedback with these. These are all things that I do plan to add back, but just haven't got to it yet -- so far, I haven't really had any feedback bugging me for the first two so they haven't got done. There will of course be a 3.01 release afterwards, so it might well be that if you really value these features you choose to stick with 2.72 in the meantime.
Quote-I missed the old menu items that I used to use to jump straight to, for example, the repeatedly_execute or game_start section of the script.
At the top of the script editor window there's a drop-down list box which you can use to jump to any function in the script, which is the replacement for this functionality.
Quote-I liked the old search function better, automatically hilighting the first instance and closing the search dialog, then using F3 to go to the next. Now, when it highlights an instance of the search term, the dialog stays open and I can't scroll around the script to verify if this is the instance I'm looking for.
Interesting, perhaps the dialog could be made non-modal so that you could still scroll around without having to close it. Does anyone else find this an issue?
Quote-Importing with the "palette index 0" as the transparent color apparently no longer works with high color games. It used to, and was a convenient way to not have any transparencies on a sprite (when the sprite is meant to be a rectangle).
I wasn't aware that people used the feature in this way. A "no transparency" import option is certainly on the agenda and something I'd like to implement relatively soon.
QuoteAlso, when 2.7 would get to the point where my game took too long to compile for every test, I would start quick saving with ctrl-a and then running the engine straight from the game's folder to save time. I didn't see a quick save option, but I didn't have time to mess around with saving and compiling much, maybe there's a way to do something like this in v3. I hope so.
The Test Game feature in 3.0 has been optimized so that you shouldn't find it slowing you down any more. There's a separate F7 Build EXE option for when you want it to build the Compiled folder for you; and the normal F5 Test Game option effectively automatically does what you were doing manually before.
QuoteWhen I try to run the game in Direct3D mode, no matter what resolution I chose, windowed or no, it tells me that my computer doesn't support that resolution. But I usually don't have any problems running games or other programs in 640x480 full screen. I'm running it on a MacBook booted into Windows XP via bootcamp. Not sure what's up there.
Do your graphics drivers support Direct3D? Not sure what bootcamp is, but does it have D3D support? Some basic gfx drivers (like the ones businesses use) claim to support D3D but then don't actually support any resolutions.
QuoteImported a sample from 2.72 and it looks like a row of pixels is missing in my dialogs first row, whatever the first row may be. Had no problems with that in 2.72.
Problem dissapears when I disable "Use GUI for dialog options".
If you have a sample of this problem that you could upload, that'd be appreciated; I'd like to investigate it further.
Chris I'll give it a shot.. For you. I wasn't planning to download AGS until it was off beta testing but since I know I might help or not improving AGS somehow I can forget my ideas for a while.. I 'll edit this when I find something disturbing.
EDIT: I tried to put LC2(Built on AGS2.72) on AGS 3.0
And I got an error. Variable 'new' is already defined..
I tried to figure out what wasn't working on assuming that
you probably have changed many things.. So I was expecting to double click
on the output part and then a new window with the script where the error was would show up. But you've changed sth...
I'm missing the dialog that showed you all the modules you've imported. Though
I gave to agree it is more functional without it..
QuoteVariable 'new' is already defined..
This is mentioned on the "Upgrading to AGS 3.0" page in the manual. I'll paste it here:
1.
new is now a reserved word. This means that if you had any variables
called "new" then your script will fail to compile. Just rename the variable
to something else.
Quote from: Pumaman on Sat 22/12/2007 20:49:39
Quote-Importing with the "palette index 0" as the transparent color apparently no longer works with high color games. It used to, and was a convenient way to not have any transparencies on a sprite (when the sprite is meant to be a rectangle).
I wasn't aware that people used the feature in this way. A "no transparency" import option is certainly on the agenda and something I'd like to implement relatively soon.
I've used that for ages. I'd like to see it back in some form, too.
Quote from: Ishmael on Sat 22/12/2007 23:01:13
Quote from: Pumaman on Sat 22/12/2007 20:49:39
Quote-Importing with the "palette index 0" ... to not have any transparencies on a sprite
I wasn't aware that people used the feature in this way.
I've used that for ages.
Me too. (OK, "ages" for me is only a few weeks). "No transparency" is a common need when creating buttons (for example).
Quote from: Pumaman on Sat 22/12/2007 20:49:39QuoteNow, when it highlights an instance of the search term, the dialog stays open and I can't scroll around the script to verify if this is the instance I'm looking for.
Interesting, perhaps the dialog could be made non-modal so that you could still scroll around without having to close it. Does anyone else find this an issue?
I actually find this rather annoying. Now that we have a 'Replace' feature as well I don't have to open and close the dialog every time I want to do a copy and paste replacement; I can just use 'Replace' instead. However, I would still find it useful to be able to scroll around this box.
Quote from: Pumaman on Sat 22/12/2007 20:49:39Quote-Importing with the "palette index 0" as the transparent color apparently no longer works with high color games. It used to, and was a convenient way to not have any transparencies on a sprite (when the sprite is meant to be a rectangle).
I wasn't aware that people used the feature in this way. A "no transparency" import option is certainly on the agenda and something I'd like to implement relatively soon.
I too would like to show my support for the 'no transparency' option and admit now that I am also guilty of using the palette index 0 in high res games. 8)
Ok, the transparency issue is now addressed by the new RC 4 version which introduces a "No transparency" option to the sprite import.
Ok, I have no variables named new..
Checked em every where... in each room ..in global script...
And most important I don;t have nothing near line 68 in any script
(It says Line 68 variable new is already defined.)
Maybe I'm doing sth room.
Anyway, I imported a game I'm working on early stages and it had no problem...
I think you shouldn;t worry about my case.. I've realised LC2 on AGS 2.72 and I'm releasing LC3 with 2.72 as well.
I tend to draw all the frames of an animation in the same file, so I can look at previous movements when drawing the current one. So I am often importing ten-twenty sprites from the same file. In older versions if you right-clicked and chose "Import Sprite from File" it would return to the previous file automatically (at least if you had just imported from that file). With 3.0 it wants me to select the file from a menu each and every time, which is slightly slower but more importantly I find I lose my place with the extra action in between.
Otherwise it's looking pretty good. I'm making a quick year-in-review slideshow over the next couple of days and I've decided to test-drive 3.0 to make it. I'll report back if I find anything major along the way.
Baron
Quote from: BaRoN on Mon 24/12/2007 04:49:01
I tend to draw all the frames of an animation in the same file, so I can look at previous movements when drawing the current one. So I am often importing ten-twenty sprites from the same file. In older versions if you right-clicked and chose "Import Sprite from File" it would return to the previous file automatically (at least if you had just imported from that file). With 3.0 it wants me to select the file from a menu each and every time, which is slightly slower but more importantly I find I lose my place with the extra action in between.
Another thing I, aswell, would like to see return from 2.72.
Another thing I noticed: the baseline tool, is it gone or just hidden? I think I can get used to typing in a number for it, but I found the old method faster, since I apparently tend to work with only the mouse a lot.
As a total newbie to this (I last picked up AGS a few years ago but never finished anything), I find this new interface rather irritating and confusing. The addition of scripts such as looking at a hotspot for instance seems to have become more complicated than it used to be. I seem to remember the old version letting you select options from a list, which was great. Now it seems you have to manually type into the scripts themselves, which may not seem a great problem to experienced people. But to a beginner who just want's to try to get a few rooms together it is rather intimidating, and offputting. Also I have looked and looked but cannot see how to run the game in full screen mode as default! All I get is a miniscule 320x200 window on my big widescreen monitor...
Sentient: Build the game, go to the Compiled folder, run winsetup, switch the Graphics filter to x2 and check full screen. Then run the game.
I'd love to be able to do mouse.IsButtonDown(eMouseMiddle). Any chance this could be implemented in a future release? Sorry, just realized this belongs in the wishlist thread.
Ahh, thankyou. I was wondering if I could do it from a build. This then runs in full screen when testing from ags too? Oh, found that ctrl+F5 will run it in full screen from the editor :)
Quote from: sentient on Tue 25/12/2007 15:41:05I find this new interface rather irritating and confusing. The addition of scripts such as looking at a hotspot for instance seems to have become more complicated than it used to be. I seem to remember the old version letting you select options from a list, which was great. Now it seems you have to manually type into the scripts themselves, which may not seem a great problem to experienced people. But to a beginner who just want's to try to get a few rooms together it is rather intimidating, and offputting.
You refer to AGS 3.0's lack of an
Interaction Editor as it was called in the 2.72 and earlier versions of AGS. It has been discussed though I believe the consensus was that it wouldn't be too great a loss, even from the eyes of a "newbie" who could use the manual (http://www.adventuregamestudio.co.uk/manual/), BFAQ (http://americangirlscouts.org/agswiki/Category:AGS_Beginners%27_FAQ), forums, and wiki (http://americangirlscouts.org/agswiki/Main_Page) to find an answer. There was also discussion of an editor plugin for generating scripts (written by a forum user), which though I have heard is in development, have yet to actually see a release of.
Regarding the other issue, the new editor also includes a script debugger which, while debugging (whether there are actually any break-points or not) will always run in windowed mode. You can also run the game without the debugger (Ctrl+F5) as you found which (as far as I recall) defaults to the game's settings with regard to windowed/full screen mode.
You don't actually have to 'Build' the game to be able to test it full-screen though.
I'm slowly getting into it. Got the hang of very basic scripts now. Just seemed weird that the version I used years ago allowed the fairly basic commands which just a mouse click, and the newer version has done away with it. Still, I am sure I will get the hang of it.
Alright I've used 3.0 for all the basic things, and overall I must say I like the new format, especially the tabs. There are a few areas where I find it a bit slower than previous versions (other than the one mentioned above):
1) On the Main Menu tree (upper right) you see the room you want to edit, and the temptation is to right click it (since that's how you get a new room). This produces the obvious option to edit the room, but when I click that nothing happens and the option disappears.
2) When you are editing a property of a frame in a view, for example, you have to click an extra time: once to select that property (say "flipped") and once to change it. In previous versions you could just click once and it would change. Same thing in the room properties for "player is initially visible" and object properties for "object is initially visible", and probably any other option that was just a radio button on previous versions.
3) There is also an extra click required with 3.0 to import sprites to view frames. In previous versions you would click "create new frame" and the new frame would be automatically selected. Now you have to click again to select it and then double click to change the graphic, meaning a lot of extra clicking for long animations.
4) When, as with the previous example, you get the sprite folder that lists your sprites, they are displayed in a narrow window (3 abreast on my monitor), whereas in previous versions it would automatically expand to full screen with 8 sprites per row. I can expand the window, but that requires an extra click, and it won't repeat with that size the next time, again meaning an extra click or a lot of extra scrolling.
5) Also in the sprite list, I find the "previously used sprite" indication very faint, whereas in previous versions it was much more apparent which one you used last.
6) This is not so much a problem as a preference, for it has not been implemented in any AGS version hereto. Is it possible when displaying sprites (for importing to frames) to list the previously used one in the top row, instead of the bottom? I often find I'm scrolling down to see the next row, but there is rarely a reason to scroll up.
Otherwise the changes are time/effort neutral, or an improvement, so far as I can tell. Oh -is there a button I'm missing that will jump me right to the room script, instead of having to click the interaction lighting bolt and then a random interaction (i.e. the old "{ }" button)?
BaRoN
Quote from: BaRoN on Sat 29/12/2007 21:36:59Oh -is there a button I'm missing that will jump me right to the room script, instead of having to click the interaction lighting bolt and then a random interaction (i.e. the old "{ }" button)?
When you expand the room item you will see "Room script" which you can double-click to open:
Room->#: DESC->Room script (# is room number, DESC being the room's description).
Ah, you know I've actually done that several times, but I still instinctively look for the button ::) .
I'm with BaRoN on the issue of the extra clicks related to view spriting and such options. Too much clicking to be done :\
I think the new editor is great. Though it does have a few extra clicks in some places, that really helps the organization, in my opinion.
Just give the editor a chance. After a while, those few little things that bug you at first vanish.
The greatest force in the universe is human resistance to change. ;)
Quote from: NiksterG on Sun 30/12/2007 21:10:38
The greatest force in the universe is human resistance to change. ;)
I don't resist change for the better. There just are certain things that used to be better than they are now, in my opinion.
More clicks for adding sprites for a character? Impossible. ::)
QuoteAlright I've used 3.0 for all the basic things, and overall I must say I like the new format, especially the tabs. There are a few areas where I find it a bit slower than previous versions (other than the one mentioned above):
Thanks for your feedback, it's really useful. I'll see what I can do.
QuoteI seem to remember the old version letting you select options from a list, which was great. Now it seems you have to manually type into the scripts themselves, which may not seem a great problem to experienced people. But to a beginner who just want's to try to get a few rooms together it is rather intimidating, and offputting.
I appreciate this, but actually the old interaction editor wasn't that friendly. To display a message you had to create a "Display message" interaction from the menu, then create a global/local message, then set the text, then link up the message numbers. I think it gave an illusion of ease which doesn't necessarily reflect the reality.
The equivalent script for the simple things that the interaction editor supported (like displaying a message) is quite simple so hopefully people can get into it fairly quickly and not be scared of scripting.
Quotethe baseline tool, is it gone or just hidden
Yeah, that is gone, and I can appreciate typing a number in isn't an improvement over selecting it graphically. I'm not sure if there'll be time to bring it back for 3.0 though.
QuoteImported a sample from 2.72 and it looks like a row of pixels is missing in my dialogs first row, whatever the first row may be. Had no problems with that in 2.72.
Problem dissapears when I disable "Use GUI for dialog options".
I've looked into this, it's due to game.dialog_options_y being set to -2, and 3.0 doesn't work properly if you use a negative number for the dialog_options_x/y. I'll get it fixed.
I retract this message, my liking with 3.0 has improved.
Since I can't be bothered downloading to check one feature.
But in 2.72 there was an option to pop up a GUI if the mouse was above a certain y coordinate. This should be usable for "bottom-GUIs" aswell (if I'm missing something, beat me up or something).
Teeny possibly redundant or already implemented suggestions aside, easing out case-sensitivity might be a wise decision for the future, it would avoid alot of stupid errors and typing time, I can't think of any negative reason at the moment.
Quote from: Crazy on Tue 08/01/2008 22:43:56
Teeny possibly redundant or already implemented suggestions aside, easing out case-sensitivity might be a wise decision for the future, it would avoid alot of stupid errors and typing time, I can't think of any negative reason at the moment.
The autocomplete is there for a reason, and without case sensitivity both it would be lost, and soon you might be lost in your code.
If the autocomplete didn't work then it would obviously not be entirely case-unsensitive.
Okay, I have worked now for a while with RC4 and 2.72 in comparison. A lot of things that I considered to be "bugs" were actually errors or warnings that cropped up because I was set in my 2.72 ways, and did things "wrong" in RC4.
It works nice. The extender functions are a great addition, and after getting used to the new debugger/exe functionality, it was also very useful. It is true that there is some "getting used to" involved, but I think it's mostly for the better.
I can live with the additional clicks and I can totally live with the absence of the Interaction Editor (I always only used to to make "run script" anyway).
What nags me are two purely cosmetical things. I totally understand if the are never included.
1) I *hate* the crosshair selction for hotspots. It just was so much more convenient to have an actual "pixel square" marking the hotspot of cursors and inventory items.
2) Could we have a "remember outlay" feature? Each time I launch RC4 the tree and settings windows are reset to their default states, and I need to enlarge the tree view a good deal to have all entries visible (You may remember I'm one of those old-fashioned 800x600 users).
Apart from that, and I said so before, the new look's great, the added functionality totally functional, and the new templates (Rui's extended Default and Elektro's Verb Coin) just the icing on the cake.
Quote from: Crazy on Tue 08/01/2008 22:43:56
Teeny possibly redundant or already implemented suggestions aside, easing out case-sensitivity might be a wise decision for the future, it would avoid alot of stupid errors and typing time, I can't think of any negative reason at the moment.
It can be considered a large change though, as removing case sensitiveness would possibly break stuff in projects started with earlier versions (among which inevitably saying good-bye to old string compatibilities and mouse/Mouse, etc.). So it should be included in a HUGE update version instead, that means people working with a game with a previous version of AGS are not advised to upgrade (unless they're experienced users who are ready to make changes).
I didn't say V3.0 was not a huge update, but V3.0 focuses mainly on the new editor, most part of old projects should still work after the update.
Possibly, it has always just felt a bit outdated and overly stringent (I break up words in variables with underscores so it's "big_gas_tank" instead of "BigGasTank" in other languages), plus I just find it alot faster to process, but
I guess if noone else is overly bothered then I can live with it.
I think it is absolutely essential that the install wizard detects if .NET framework 2.0 is installed or not.
I had the issue (I had installed it previously but it had been disabled by some development tool that I had installed), a friend of mine had the issue, and also a friend of my friend
--> everytime you say "hey, give a try to AGS, it's great" the other person answers "I tried it but it crashed at startup for some random DLL reason"
Well, i guess that one of the most wanted tools for it is the Eraser for the room hotspots, so then we dont have to erase the whole hotspot if we fuck a little pixel out
Use Color 0.
Quote from: dkh on Wed 09/01/2008 21:15:49
Use Color 0.
thankz for helping unn00bing me >.>
also, why the fuck theres no more support of the .PCX format? it will be a pain in the ass to convert all that content...
No moderator, me, but: Easy on the f word.
AGS has lost pcx but gained other, probably more versatile formats. And there are programs out there that can auto-convert whole batches of files with a mere two clicks.
Quote from: Crazy on Wed 09/01/2008 16:31:02Possibly, it has always just felt a bit outdated and overly stringent (I break up words in variables with underscores so it's "big_gas_tank" instead of "BigGasTank" in other languages), plus I just find it alot faster to process, but
I guess if noone else is overly bothered then I can live with it.
So long as you're always defining your own variables this way, then I don't see why it would be such a big issue other than simply having to conform when using the built-in variables.
IMHO case-sensitivity in the language actually forces users to conform to a cleaner and more standardized scripting style. Consider the following:
gUitYPe* myGuI = GuiTypE.getaTscReeNxY(mOUse.X, MoUSe.y); // the GUI-class would have to be renamed to prevent confusion with the gui array
iF (MygUi != NulL) mYGui.cONtRolS[5].viSIbLe = fALsE;GUI* myGUI = GUI.GetAtScreenXY(mouse.x, mouse.y);
if (myGUI != null) myGUI.Controls[5].Visible = false;The case-insensitive version is probably a bit extreme, but if we're going to do away with case-sensitivity, let's do it up right! :=
The case-sensitive version is more clearly legible and it also provides for reasonable collisions like the
GUI type vs. the
gui array or the
String type vs. the
string type. There are obviously occasions where collisions could cause confusion, but IMO the built-in collisions have always been very reasonable.
Furthermore, removing case-sensitivity would break virtually every AGS script ever (including built-in headers and things of that nature).
Personally I don't think that removing case-sensitivity is a good move for AGS, and I'm fairly certain CJ will side with me on this one. But of course this is just my two cents. Which unfortunately...just broke my bank. Damn. :P
I absolutely concur. E.g. I usually name my struct "Tile" and the corresponding array "tile". Very clean and convenient.
Ditching case-sensitivity is baaad! No twinkie!
QuoteTeeny possibly redundant or already implemented suggestions aside, easing out case-sensitivity might be a wise decision for the future, it would avoid alot of stupid errors and typing time, I can't think of any negative reason at the moment.
I have no plans to do this at the current time.
QuoteBut in 2.72 there was an option to pop up a GUI if the mouse was above a certain y coordinate. This should be usable for "bottom-GUIs" aswell (if I'm missing something, beat me up or something).
That's a possibility, but it's so easy to script it that so far it hasn't really been worth adding as a built-in feature.
Quote1) I *hate* the crosshair selction for hotspots. It just was so much more convenient to have an actual "pixel square" marking the hotspot of cursors and inventory items.
2) Could we have a "remember outlay" feature? Each time I launch RC4 the tree and settings windows are reset to their default states, and I need to enlarge the tree view a good deal to have all entries visible (You may remember I'm one of those old-fashioned 800x600 users).
Does anyone else have any strong feelings about the cursor hotspot marker in 3.0?
As for remembering the window position -- it should remember the position and size of the overall editor window, and the tree defaults to a reasonable width so that you can see a reasonable amount. What's the problem here, exactly?
QuoteI think it is absolutely essential that the install wizard detects if .NET framework 2.0 is installed or not.
Is this not working at the moment? The current AGS 3.0 installer should detect this and warn you if it's not there.
Quotealso, why the fuck theres no more support of the .PCX format? it will be a pain in the ass to convert all that content...
Well since you asked so nicely, I'll get right onto it ::)
Quote from: Pumaman on Sun 13/01/2008 18:03:33
Quote2) Could we have a "remember outlay" feature? Each time I launch RC4 the tree and settings windows are reset to their default states, and I need to enlarge the tree view a good deal to have all entries visible (You may remember I'm one of those old-fashioned 800x600 users).
As for remembering the window position -- it should remember the position and size of the overall editor window, and the tree defaults to a reasonable width so that you can see a reasonable amount. What's the problem here, exactly?
I think what he means is that when opening AGS, the tree where you can find GUIs, Characters, Views, etc. goes back to the default, where everything is un-extended. I think what he would prefer (and I as well) would be if AGS could remember what was open so that we wouldn't have to click on those tiny plus signs everytime in order to see the subfolders.
QuoteDoes anyone else have any strong feelings about the cursor hotspot marker in 3.0?
Yes, I prefer the crosshair exceedingly to the old format, though perhaps having a missing pixel at the center (like many art programs or the old SCUMM cursor) might help precision slightly, like:
(http://members.cox.net/progzmax/curtype0.gif)
or even
(http://members.cox.net/progzmax/curtype1.gif)
Both let you better see the plotting position of the pixel. Simply enlarging it may help with this, however, since for me the crosshair is quite small even at 1024x768 (it's resolution seems higher than the actual backgrounds)?
Quote from: NiksterG on Sun 13/01/2008 18:13:11
Quote from: Pumaman on Sun 13/01/2008 18:03:33
Quote2) Could we have a "remember outlay" feature? Each time I launch RC4 the tree and settings windows are reset to their default states, and I need to enlarge the tree view a good deal to have all entries visible (You may remember I'm one of those old-fashioned 800x600 users).
As for remembering the window position -- it should remember the position and size of the overall editor window, and the tree defaults to a reasonable width so that you can see a reasonable amount. What's the problem here, exactly?
I think what he means is that when opening AGS, the tree where you can find GUIs, Characters, Views, etc. goes back to the default, where everything is un-extended. I think what he would prefer (and I as well) would be if AGS could remember what was open so that we wouldn't have to click on those tiny plus signs everytime in order to see the subfolders.
Yes, that *and* the size of these panels, too is what I meant. Also the size of the sprite panel, and so on. Basically, remember the position of the splitters (if that's what they are called)- the lines you move to resize parts of the editor.
I don't mind dragging the splitters around, but the window doesn't seem to remember it's size for me for some reason... Tho my computer seems messed up enough already that it might be just me there.