Hello guys,
For the last two days I've been playing with AGS and especially one issue has cost me a lot of time: I wasn't able to draw walkable areas.
Ok, now after hours it's clear to me how to use that feature...
1. My experienceI was told by a tooltip that "You are currently using the eraser. To draw new areas, change the selection in the list above the Properties Pane." Well, in all other tools I know you have to click an eraser icon or select that command from a menu in order to enter such an mode. I hadn't done that. Also I wasn't able to locate the walkable area ID selection list ???. This was probably due to the huge width of that control. I just wasn't able to identify it as a list control. Ok, maybe I'm stupid... :-[ But let me tell you that I've been a software engineer for seven years. And developing .NET user dialogs has been one of my tasks. The help or FAQ don't mention that problem. Finally, I was able to solve that issue by using the search feature of this forum: A post with a screenshot how to change the walkable area ID to something else than 0.
2. Why you have that problem following a tutorialI was watching the youtube tutorial by densming. So I started a new project with the default game and switched the background. I was notified that the new background had a different size and everything including the walkable areas would be deleted. Ok, the first time I didn't read that message box, but that wasn't the problem. The problem is: After deleting the background image of the only existing room and deleting the walkable areas due to the new background size, the walkable area ID is set to 0 and remains zero unless set to something else manually.
3. Two suggestions to remedy that problem.
- After assigning a background image with a different size and deleting the walkable areas make sure to set the walkable area ID to non edit mode. Note: That buggy behavior does only appear in case there is only one room! (repoduction is quite easy with a new project and the default game) Also it might be of help for beginners to change the selection text from "walkable area ID 0" to "walkable area ID 0 (eraser mode)"
- Walkable areas and other regions are not object oriented. Instead, they are internally implemented by using image files and color codes to code the different regions. From that (developer) point of view it makes totally sense to have an eraser mode assigning color code 0 to pixels. However, there are users not familiar with that part of AGS history, instead, they are familiar with object oriented tools. So, they first try to treat walkable areas as objects. The editor supports that thinking as every walkable area has properties assigned to it. So it seems naturally to have walkable areas overlap each other. But that's not possible as each walkable are pixel is only able to keep one color code. Also from an object oriented point of view it doesn't make sense to draw into one walkable area in order to delete other walkable areas. My suggestion is to change the selection list to a color pallet to make it more obvious that it's a actually a drawing tool for a 2D image. The colors could be arranged in two rows each of them keeping 8 colors. This way each color would be big enough to keep the ID of its walkable area as text. Also the Properties Pane could still be used as it would show the properties of the color currently selected.
I'm looking forward to getting feedback for suggestion #2. However, suggestion #1 describes a bugfix and should be implemented ;)
Regards
Marcus
In suggestion #1 I've claimed there is a bug that sets the walkable area ID to 0. This statement is incorrect! :-[ It seems that I've set the walkable area ID to 0 by myself. This has happend because I was "exploring" the walkable area feature by left clicking with my mouse. As the "Select area" tool is the default, the walkable area ID was set to 0 without me (unfamiliar with the feature) recognizing that.
Ok, it seems like it's a feature, but to be honest, I still think it's a usability bug. It could be solved by selecting a different tool than "Select area" as the default one.
Regarding suggestion #2 - Here's a mock example of how this could be implemented:
(https://dl.dropbox.com/u/50711377/suggestion.jpg)
I didn't place the pallet close to the properties area, but instead to the toolbar where you normally expect such a feature. Of course, the current selection and the walkable area selection list had to be synchronized in both ways. And if you moved the "Select area" tool from the left closer to the pallet it would be even better grouped in regards to functionality.
I support this suggestion, for I too found selecting regions in combo box not convenient.
BTW, there's something else I suggested a while ago regarding project tree and room editing mode:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46483.0
+1
I hate that darn combo box.
Not to mention very often I even forget about it and spend way too long remembering how to switch between areas.
I definitely agree with #1, this is definitely not user friendly.
Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.. If you come up with a way around that I'm on board (and feel free to code it since you've confessed to have experience in dot net ;) ).
And a bit unrelated, but I believe overlapping walkable areas is a useful feature that should be supported in the future.
Quote from: tzachs on Sat 29/12/2012 22:24:39
Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.
AGS currently supports only 15 areas per room.
Quote from: Crimson Wizard on Sat 29/12/2012 22:57:49
AGS currently supports only 15 areas per room.
However, AGS supports 50 hotspots. And the implementation of hotspots derives directly from walkable areas. So if you e.g. switch from walkable areas to hotspots the palette control has to deal with that. Of course, in such a case the palette control could be switched to being invisible. But due to the inheritance dependencies I found in the code, I think, the patch would be smaler, if the feature was implemented for hotspots, walkable areas, walk-behinds, and regions.
Quote from: tzachs on Sat 29/12/2012 22:24:39
and feel free to code it since you've confessed to have experience in dot net ;)
I've already had a look at it ;)
What I found was a nicely designed architecture with quite a learning curve. It would be a lot of effort to change the toolbar so that it could keep other controls than icons. From this point of view the palette control would be in better company close to the other non toolbar icon controls like the zoom and trans sliders. Any suggestions?
Btw. is there somewhere information about how to submit a patch and allowed namespaces? E.g. is it allowed to implement drawing routines for custom controls and mess with windows messages? I'm asking because future compatibility to mono seems to be important (in other threads).
Quote from: tzachs on Sat 29/12/2012 22:24:39
Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.. If you come up with a way around that I'm on board
I could imagine to start with e.g. one of the controls at http://www.codeproject.com/Articles/12327/Office-2003-Color-Picker and modify it for walkable areas etc. Suggestions?
Quote from: Milhouse on Sun 30/12/2012 02:47:01
Btw. is there somewhere information about how to submit a patch
How to submit a patch. (https://github.com/adventuregamestudio/ags#contributing)
Quote from: BigMc on Sun 30/12/2012 04:04:28
How to submit a patch. (https://github.com/adventuregamestudio/ags#contributing)
You seem to have many many repositories... And good that I asked because I've used used https://svn.adventuregamestudio.co.uk:7743/svn/ags/trunk/ instead of https://github.com/adventuregamestudio/ags. What's the reason for so many repositories and branches? I haven't found any sticky note explaining that "mess" (sorry for that) for someone new to the topic. Or is this intended to be some kind of adventure everyone has to complete before contributing similar to the forum registration quiz? (laugh) Just wondering ;)
I guess you mean the different branches. The master branch is what you want.
EDIT: And that everybodies personal ags repository is visible is just because github is awesome.
The svn repo is CJ's repo which matches the current 3.2.1 release but it's not the current repo in development.
All development should be done against the github version.
I think it's the time when we should define how we organize versions?
The github.com/adventuregamestudio/ags is constantly under development (mainly refactoring and fixes to the engine atm). It would be not wise to just get everything in the pile, because while editor may be fully working with these new features, engine may still have some issues.
I think what they did in original SVN was creating a separate branch for the new version when it was ready, while the "main" (or "master") branch could be changed further?
What about we do this:
- define goal for the next versions of both engine and editor;
- when those two approach their goals we create separate branch for it, like ags_3_3. All changes related to the version goals are made in the branch and copied (merged) to master afterwards.
- meanwhile the master branch could be changed further on its own without affecting planned version.
Also: Delete 64bit and refactory and rename main to legacy to avoid confusion.
EDIT: Here is a good example how to use branches: http://nvie.com/posts/a-successful-git-branching-model/
Quote from: Milhouse on Sun 30/12/2012 11:18:53
is this intended to be some kind of adventure everyone has to complete before contributing?
For the record: that's because the community brutally took over Chris Jones' code and 2 years later you can still feel the aftermath of this. While there is a lot of very good contribution, the whole process is not fully centralized yet (at least in appearance). But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!
Quote from: BigMc on Sun 30/12/2012 14:51:00
EDIT: Here is a good example how to use branches: http://nvie.com/posts/a-successful-git-branching-model/
Ah, so it's opposite: use master as a stable branch, and make development in a separate.
Quote from: Monsieur OUXX on Sun 30/12/2012 15:11:33
Quote from: Milhouse on Sun 30/12/2012 11:18:53
is this intended to be some kind of adventure everyone has to complete before contributing?
For the record: that's because the community brutally took over Chris Jones' code and 2 years later you can still feel the aftermath of this. While there is a lot of very good contribution, the whole process is not fully centralized yet (at least in appearance). But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!
In my perception he was fine with the community taking over, the thing just never happened in an organized way. One problem that persists is that the homepage still does not reflect the new situation (github repo, available ports, news regarding development, etc) properly.
Quote from: Crimson Wizard on Sun 30/12/2012 15:16:29
Quote from: BigMc on Sun 30/12/2012 14:51:00
EDIT: Here is a good example how to use branches: http://nvie.com/posts/a-successful-git-branching-model/
Ah, so it's opposite: use master as a stable branch, and make development in a separate.
You could replace master and develop in that text with stable and master. Depends on whether you expect develpers or users to clone more often.
EDIT: But I would make master the stable branch too once there is a stable version.
I just know SVN well and have always used the folder structure suggested by the SVN makers. That way it's also easier for a new member of the development team to be productive right from the beginning. GIT uses a more modern approach and if I had a new project I would go for it. Also I would stick to the suggested workflow of the git makers. There is an open source git book (http://git-scm.com/book) available at the git web site that also suggests branching work flows. I would be glad if I just had to learn from that source. No adventures ;)
If I had to decide, I would close the SVN repository as it's already hard enough to manage and have the overview of one repository. Just my two cents and own experience.
And I agree with Crimson Wizard that you should know how to organize versions. That's the task of a project manager or project manager team. Who has done that task so far?
Quote from: Monsieur OUXX on Sun 30/12/2012 15:11:33
But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!
I have noticed that and appreciate it very much. I hope you don't mind my jokes :)
The git book suggests the same branching model as the article I posted earlier (see "Branching Workflows"), the article describes it just in more detail.
Quote from: Milhouse on Mon 31/12/2012 00:01:43And I agree with Crimson Wizard that you should know how to organize versions. That's the task of a project manager or project manager team. Who has done that task so far?
Chris Jones. :D
Well, tzachs lately.
I feel like this is going more offtopic (this is a thread about walkable area ID, yes?), just want to mention that so far the Editor and Engine were developed separately, and engine development does not have strict short-term goals.
Quote from: Crimson Wizard on Mon 31/12/2012 07:52:24
I feel like this is going more offtopic
This might be off topic again...
I'm not able to compile the github version. For AGS.native the linker isn't able to resolve some external references (e.g. symbol __rgb_a_shift_32). As the editor depends on that assembly at compile time I get an error message (could not load referenced assembly). Might someone check the AGS.editor.full solution or provide me with information to solve that problem? Btw the editor of the SVN version I checked out earlier didn't depend on the native assembly. I'm using VS2010 Ultimate on a Win7 64 bit machine. Thanks.
Oops... wrong post... sorry
Quote from: Milhouse on Mon 31/12/2012 12:01:08
I'm not able to compile the github version. For AGS.native the linker isn't able to resolve some external references (e.g. symbol __rgb_a_shift_32). As the editor depends on that assembly at compile time I get an error message (could not load referenced assembly). Might someone check the AGS.editor.full solution or provide me with information to solve that problem? Btw the editor of the SVN version I checked out earlier didn't depend on the native assembly. I'm using VS2010 Ultimate on a Win7 64 bit machine. Thanks.
There are two solutions for the editor: AGS.Editor.Full and AGS.Editor.NoNative. But I see I made a mistake but adding an AGS.Native reference to Editor project (I think I did this to make sure it always keep AGS.Native up to date whenever I build Editor at the times I did big changes to the code, shared between Engine and Native). I may remove that reference (you may do that for your local copy meanwhile).
Second thing is that the Native project, as well as Engine, is not compatible as-is with MSVS 2010. I think certain fix could be made: open Project properties, "General" -> "Platform Toolset" -> should be set to v90. But you have to have at least 2008 Express installed. IIRC that worked for me.
Quote from: Crimson Wizard on Mon 31/12/2012 14:04:34
I may remove that reference (you may do that for your local copy meanwhile).
I tried that but there's code used in that project that depends on that reference!
Quote from: Crimson Wizard on Mon 31/12/2012 14:04:34
Second thing is that the Native project, as well as Engine, is not compatible as-is with MSVS 2010. I think certain fix could be made: open Project properties, "General" -> "Platform Toolset" -> should be set to v90. But you have to have at least 2008 Express installed. IIRC that worked for me.
That'll take a while getting it running. At the moment I'm short on time.
My apologies, I told a wrong thing.
Editor always had a reference to AGS.Native, of course. If you don't build one, you should just get one somewhere and put to the folder where Editor can find it during compilation (and run).
It looks like in past CJ has kept and updated the AGS.Native.dll under source control, in Editor/References folder. I seem to break this step in building process, so native lib is no longer put where it should be.
I made a commit, which fixes it, also uploaded recently built library there. Please tell, if this solves your troubles.
(Remember to use "AGS.Editor.NoNative" solution)