Messages

[Default GFX Driver DirectDraw/Direct3D]

This should be addressed by the new Preferences option in 3.0.1 beta 1.

I don't see the big deal here -- as monkey says, just use GUI.SetSize instead.

Using GUI.SetSize is an adequate solution for myself.   I don't mean to make a big deal of it an but the resulting error is confusing because the statement that causes it is perfectly valid.  IMHO, it's something that people will get hung up on in the future.  I suppose time will tell.

As monkey says, why not just right-click Move Up or Move Down as appropriate to re-order things? Or are you just saying that by default new modules should appear at the bottom rather than the top?

Sorry, I wasn't aware of the Move Up/Dn functions already built in.   Changing the default to insert at end of list (just ahead of the global script) would satisfy the remainder of my request/comment.

Hmm, I'm not sure about this one. To me, it seems more intuitive that when searching forwards, the text would display at the bottom of the screen, which also gives a better illusion of moving forwards whilst going through the find result matches...

IMHO, most people would like to see the context of each occurance of the found text (i.e. a few lines before and after).  That's why I suggested that the better solution would be to have a user settable preferences that specifies how many lines the found text should be above/below the bottom/top of the screen.   

That's a possibility, but double-click having different behvaiour to clicking the + could start to get confusing. I'll have a think about it.

The current behavior is fine with me.  I would also like to remind you of previous semi-related comments about using single inistead of double clicks here.   With regard to the latter, perhaps single clicks could just select the corresponding tab and bring that page to the front, if the file has already been opened.  Double clicking would then just do what it does now open the file in a new tab and display it. 

Default GFX Driver DirectDraw/Direct3D
When I tried the demo that is part of the installation I got an error because my little computer does not have Direct 3d.  Ok, so I just went and ran winsetup easily enough but what about brand new users?   I don't know if this is just the demo game or it new game also creates a similar default setup.  It's kind of a trival point but something I thought that may be of some interest.

Font Identification
This may not make it in this edition but I would find it handy if the font name, font file, and point size were retained when fonts are imported.  For example if a particular true type font was imported at one point size and later there was a need to reimport it at a larger size, for some other usage, then it would be possible to know which file to import and the prevuious point size would be the basis for guessing what the new point size ought to be.  Perhaps this info could be displayed in the property grid.

... thanks for reminding me...

CJ, thanks for all your hard work.   I'm sure you are well aware of this, but for those who haven't had the experience,  every software project of any size eventually gets to a point where it's more difficult to determine what's left to do than it is to do it.   Threads such as this one are very helpful in this respect, so even if a comment or suggestion isn't  adopted this time round doesn't mean that it wasn't helpful or that it lacked merit.   CJ is a very good listener and even though we don't always get what we want, we almost always get what we need.   

Hmmm, that last line is kind of catchy, maybe somebody will make it into a song one of these days ...   

[Validation of GUI Dimensions]

• Validation of GUI Dimensions - It appears that both height and width are validated if either height or width are changed.  It the GUI is initially purposely set larger than the screen dimensions to host dynamic controls, since both dimensions can't be set at the same time, a runtime error is generated when the GUI is resized.    Perhaps it would be better to validate only the property that is being changed.   Also, how about instead of compile warnings, just pop a message when someone enters an invalid  dimension in the property grid.   Someone who had made a mistake would get immediate feedback and someone who had done it on purpose would only get nagged once instead of repeatedly.
  
  
• New Game From Template - When creating a game from a template a dialog pops up displaying the template.txt file.  If the template.txt file is too long the OK button that closes this dialog is in accessible and off screen.   I believe in the previous version of AGS, display of the template.txt file was truncated so that the complete dialog box fit on screen.
  
  
• Game Locations - I ran the whole installation and the Demo game got installed in c:\Win\All Users\Application Data\AGS Demo and it took awhile to find it.  I think this is somewhat related to the comments above about new games being created in MyDocs in that there may be a common solution.   Couldn't we please have the ability specify a games folder where we can do our development.   The installer could ask for a location where new games are to be created.  MyDocuments could be the default so the uninitiated could just click through.  This would also be specified via File->Preferences menu.   I believe many of us would be grateful and that this would also satisfy Vista's needs.
  
  
• New Game - The initial dialog box that comes up when creating a new game requires that the descriptive text be read each time to determine which is the title and which is the folder name.  While this may be nice for new users, it's annoying for the rest.   Perhaps words similar to "Folder:" and "Title:" could be displayed to the left of the entry fields.   It appears that there is enough room to shift the fields right to accomodate the additional text.
  
  
• Module Script Order - Currently when new modules/scripts are created or imported they are prepended to the script list so that the global script remains at the end of the list as it should be.  This however, makes it difficult to manage module dependencies.  For example, suppose you wanted to have a module that defined some things that future modues or scripts would use.  With the current scheme, whenever a new module is added, it and all preexisting modules would have to be exported, deleted from the game, and then re-imported in the correct order.  A better and more intuitive scheme would be to insert new modules just before the global script so that the first module is always the first module, the second is always second, etc.  This is the way it used to work in 2.72
  
  
• Script Editor Search - When searching in the forward direction the found text is displayed in the last line in the window and searching in the reverse direction the found text is displayed in the first line of the window.   For me this seems backwards in that when searching forward I would prefer to have the found text displayed near the top of the window.   I think it was suggested in another thread that the found text be displayed in the middle of the page.   This is an acceptable compromise but perhaps a better solution is let the user specify a search margin of X lines in File->Preferences.    So when searching forward, for example, the found text would be displayed X lines from the top (or bottom if it's easier or clearer to define it this way).
  
  
• _blank.crm - This was really useful and is sorely missed.  However, I would be willing to wait if a NewRoom/NewModule templating system is on the books.
  
  
• Tab Update Feature -  Someone mentioned in another thread that if a lot of changes have been made to a script file and the bookmark and auto complete features are a bit out of synch with the current file, they can be updated by switching to another tab and then back.  Perhaps the update could also be performed just by clicking on the currently open tab, eliminating the need to switch back and forth. 
  
  ===========
  
  

  
  

  
  *Stick the header and main script of script files into their own node, similar to how the rooms work.
  

  I haven't done this because it would mean you'd need an extra click to expand the node and get to the header. However, if people want it to work like this I can look into it.
  

  For me, it's ok the way it is but if you wanted to do something to make things more consistent but not add extra clicks then perhaps something like the following could be considered. 
  
  Room Edit - Combine "edit room"  with the node  so that clicking on the node text does the same thing that clicking on "edit room" does now.   The property grid is displayed and the room background is displayed and the area editor is active.  Clicking on the
  [ + ] box would then reveal only the "room script" branch.
  
  [-] 1: Splash Screen
  |
  +----() Room Script
  
  
  Scripts - Make Module.asc into a node.  Clicking on it opens the *.asc file and displays the proiperty grid.  Clicking on the [ + ] box would then reveal only the *.ash header file.
  
  [-] Module.asc
  |
  +----() Module.ash
  
  Yeah I know,  I'm not being much of a purist here and shame on me for thinking like this.  But it's just food for thought about how to achieve both results, albeit in an impure manner.     

1.  DemoQuest is an example game that shows what a typical script looks like and how to do some of the basic things.

2. The main game download includes executables for the mini-games.  You can run them separately or from the mini-game.   If you want to see the source code then you can download the source distribution which would be labeled something like DqSci0-S0100-B02.   You would know this is the file you want because it's executable would be labeled something like DqSci0-S0100.exe or DqSci0.ags.      This particular one is a SCI0 style GUI example; the is also an AGI style GUI example and there are "point and click"   PnC variations as well.   I don't know what the AGI of SCI0 acronyms stand for either perhaps some one else can answer that.

I should also say that I have great respect for the maintainers of the DemoQuest game- without their effort I'd probably not have lasted very long here.

Ghost, thanks for the kind words they are greatly appreciated ...

I don't remember DemoQuest making use of any of the 256 colour features like pallet cycling etc

The intro screen and the "advanced" room leading to the arcade both use pallette cycling.

As a side note, what's happening with DemoQuest development? Its something I'd be interesting in contributing towards, though I don't know if my programming ability/creativity is up to it, or if I have enough time...

The development has kind of stagnated because of lack of help and feedback.  lately it has consisted of mainly keeping it updated to the latest flavor of the AGS scripting language.   Maintaining it is a lonely thankless task.   What usually happens is that people enthusiastically offer to help, do a few things, and then quickly loose interest.    Anyone, regardless of skill level,  is welcome to contribute provided they make a commitment contribute a certain amount of effort.   I don't mind mentoring novice programmers or working with novice artists as long as they are willing to put in the time and effort.

If they tried importing any new graphics they would have to make sure the graphics were at 8-bit. They would also then have to work with the existing palette, which could definitely cause confusion: "Why are my graphics messed up?"

Or they could just change the game's color depth first and then import their background.

16-bit would also allow the possibility of showing the graphical capabilities of the engine. It's been discussed several times that one of the apparent "flaws" with AGS is that it apparently doesn't support "superior graphics", and only does "old-school pixel games". Perhaps if we included a higher-res example in the demo we could show that AGS can be used for more advanced graphics as well

I would think that to show off AGS's graphics capabilities it would be necessary to draw new backgrounds and characters.  Converting the existing graphics to 16bit color will have no visible effect; they will look excatly the same and so then what exactly is the point of doing it?  Curiously enough I proposed this change many moons ago when I first started working on this and was quickly shot down . 

I think CJ's comments are reflective of the fact that the current demo looks outdated.  To remedy this situation, would require all new graphics, sounds, music, etc done with high color, high resolution, high quality mp3 music, etc.    Form there other technical requirements can be discussed.  For example we could limit the main demo to say 5 or 6  rooms and then the rest could be done as  mini-games.  The main demo could be easily distributed with the editor and the min-games could be maintained by different individuals.    Anyway, just a penney's worth of my thoughts

[edit]

I have personally been working with the existing DemoQuest files to try and provide a "more complete" version as currently much of the 'Quest is non-functional, or just plain missing.

monkey,  we should communicate about what you're doing.  I believe I have all the backgrounds and graphics either extracted or in a photoshop or other source format.  I also have new hosting space to support a development effort.   Also anyone else that is interested in helping out please send me a PM.

From what I can tell Rick has had somewhat of a time trying to maintain the demo largely by himself, doing a lot (if perhaps not all) of the work in the port to 2.7, then 2.71, 2.72, and I believe he has been working to port the code to a more compatible 3.0 version.

Just for historical perspetive, the biggest and most difficult task was conversion from the original DemoQuest II code base to the current form of DemoQuest III.  The two arcade games and all the GUI examples shared the same global script file which made it a tangled mess to organize.   This is not to disparage those who contributed to DemoQuest II.  When that version was produced there was no such things as modules or mini-games and so the only choice was to include everything into one global script.   

The second most difficult aspect of porting involved the conversion from old style strings to new style strings.  this affected the GUI example mini-games.  Litteral code translation just wasn't adequate in many cases and several of the gui examples just plain broke.  I was left with broken code that I couldn't determine what it was meant to do in the first place so the only other option was to remove  the unknown functionality.  I believe that much of what was removed were features from out of date game templates  that are not usebale with recent versions of AGS. 

I don't anticipate much difficulty in getting the current DemoQuest version to work with AGS 3.0.   However, adding code to demonstrate all the new features is another matter because they are many and I am not.     Seriously though, this is where a little feedback and some help could go a long way.

Surely one of the things that has always made working on the DemoQuest difficult has been the matter of source control; but perhaps if we could accumulate a dedicated team (that's not to say a team devoted to putting 8 hours a day in; but perhaps at least a few hours each week) then using the new AGS 3.0 and its source control capabilities we could find ourselves much closer to realizing this goal.

The difficulty here is that fact that AGS likes to keep everything in "one big file" and that makes it difficult for multiple to work simultaneously on the game.  With 3.0 things have gotten much better, with only the sprite being the one remaining bottleneck.  Mini-games and modules help out this situation quite a bit as well.  A manual source control system is in place where files are given revision numbers and ZIP archives are made for every major and minor release.  It's not  difficult to keep track of at all.   I suppose if there were 100s of developers I would be singing a different tune. 
=======

Again, my opinion is that the current demoquest should be made compatible with AGS 3.0.  Further I think we should be thinking about it's replacement with a more modern looking version some time in the near future.  When the current demoquest is retired we should make one last effort to make it as complete as possible and make one final release for posterity. 

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.

Can you be more specific?  Which room and which door?   

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.

The main thing that is unfinished is the story which isn't really necessary for it's purpose.  The story was invented in an attempt to generate some developer interest and encourage artistic contributions.   Other than that I think the script is pretty clean and serves it's purpose (at least in my opinion).   The GUI Example mini-games are outdated and should be redone so that they are based on usable templates, otherwise there is not much sense in changing them.  Also I've not gotten any comments or feedback in a long time so I have been just going on my own.

Maintaining DemoQuest is pretty much one of those thankless jobs that has to be done.  I don't mind doing it and happy to continue but I am kind of burnt out and if someone else would like to take over I have no objection  .

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.   

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.   

Ok, first of all I haven't coded anything yet I just  have a a couple of Visio drawings and the API documentation in the initial post.  So I'm open to suggestions of what ought to be done or what people would like to see in this module.

@Rui
I don't think we can prgramatically move or create hotspots, walkbehinds, and other areas so I was thinking that they would be duplicated.   I believe objects can be moved around so if the concenus here is that they should be transported then I can implement that.  I really don't see how we can get out of actually duplicating the walkable and walkbehind areas.  If you have to do that you may as well do regions and hotspots too.   

@KhrisMUC
I had a slightly different algorithm in mind where the entire background is active.  Mouse clicks would be processed in the usual way but objects and areas would have to be duplicated.   It seems your method better eliminates the need to duplicate objects and areas.   I am rethinking my algorithm, taking into account your insight;  any suggestions or opinions are welcome. 

Here is a sequence of drawings showing the PC walking to the left and then being transported to the other end when he reaches the left screen edge.

[Abstract]

Abstract
This module contains the script required to implement a continuously looping room such as the one in DemoQuest, which will eventually be upgraded to use this module.

Description
This module requires that a portion of the background image, beginning from the left edge and continuing for max_viewport_width pixels be mirrored on the right hand side of the image.   The following public methods and properties are provided buy this module

LoopRoom.Init(int max_viewport_width)
This function initializes the looping mechanism by performing a number of calculations based on the actual viewport and background image widths.  The parameter, max_viewport_width, specifies how much of the background image is repeated on the left and right ends of the image.

LoopRoom.LeaveLeft()
This function is called when the player character attempts to exit the left end of the screen.  The viewport is switched to the equivalent position on the right hand side of the screen.  Any NPCs are also transferred to their equivalent positions on the other side of the screen.

LoopRoom.LeaveRight();
This function is called when the player character attempts to exit the left end of the screen.  The viewport is switched to the equivalent position on the right hand side of the screen.  Any NPCs are also transferred to their equivalent positions on the other side of the screen.

The following public  provided buy this module

LoopRoom.X0      - Left edge of background image
LoopRoom.X1      - TransitionRight viewport new position
LoopRoom.X2      - Begining of non-mirrored portion of background image
LoopRoom.X3      - End of non-mirrored, TransitionLeft viewport new position
LoopRoom.X4      - Right edge of TransitionLeft viewport
LoopRoom.X5      - Right edge of background image
LoopRoom.Wv     - Viewport width
LoopRoom.Wa     - width of mirrored portion of background image
LoopRoom.Wb     - width of non-mirrored portion of background image
LoopRoom.W       - width of background image

Example Usage
// *** Room Script ***

LoopRoom    Loop;

// Player enters room first time
function room_FirstLoad() {
   Loop.Init(426);
}

// Player walks off left edge of screen
function  room_LeaveLeft() {
   Loop.LeaveLeft();
}

// Player walks off right edge of screen
function  room_LeaveRight() {
   Loop.LeaveRight();
}

I have searched for "loop room", "looping room" "looping" etc and have not found a pre-existing form of this module.  I am aware of SlideRoom and Panaorama modules but this one does something slightly different.  If there is a pre-existing version of this or if you have some comments or inputs please reply to this thread.

As a little bonus press the esc key, fill out the form, and check out this url -- I think you'll enjoy seeing this ...
http://typo.i24.cc/rickj

Well, I got an error that plugin ags_filenet was missing, but if it's what I think it is that's pretty cool! Wink

Here is a link to a copy of Dorcan's plugin ags_filenet.dll
[http://demo.agspace.ws/project/plugins/ags_filenet.dll

Once I get it working, it will be made available to everyone as open source.

Template Text Problem
When creating a game from a template, if the template.txt file is too long, the OK button on the dialog, that pops up showing the template.txt file, is off the bottom of the screen and can't be pressed.  In earlier versions I believe you limited the number of lines displayed in the dialog.

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.

http://demo.agspace.ws/project/archive/BluBug.zip

As a little bonus press the esc key, fill out the form, and check out this url -- I think you'll enjoy seeing this ...
http://typo.i24.cc/rickj

Bump for more radiohead news ...

http://latimesblogs.latimes.com/extendedplay/2008/01/radiohead-juno.html

Remake his bed so that the sheet only goes half way down the bed.  You know, lay the sheet on the bed so that the foot of the sheet is at the head og the bed.  Tuck this end way under the matress so it can't come out.   Then take the head of the sheet and draw it up to the head of the bed where it would normally be.  Tuck the bottom layer of sheet under the matress so that everything looks normal.  Put the top blanet(s) back on like normal.   When he comes hom keep him up late drinking or whatever so that when he does go to bed his mind is a bit foggy.  The wait for the confusion when he tries to get under the covers

My LinkSys Wireless-G Router allows me to block 4 URLs and/or websites containing any of six keywords.  I'm not sure if the 4 URLs can contain wild cards or not.   You can have up to ten different access restrictions such as this and enable them at specific times/days, etc.   I think you could have all ten active all the time so that would give you something like 40 urls that are blocked or any websites containing any of 60 keywords.   You can also block specific PCs, so if the other person is doing this from a specific PC you can also focus in on that as well.  Since this is all in the router and password protected it would be pretty difficult to hack.   

When I first read the subject of this post I wondered to myself if you were asking for a band pass filter or a band reject filter.   

PS:  If you don't have a router you could probably find on for around 50 bucks.   

I think it's pretty common practice to create new games for various reasons as monkey, subspark, and rui have said.   The only thing that is in my MyDocuments directory is default crap other application installers have dumped in there.   I honestly don't understand the resistance to implementing user configurable default paths for the various AGS files/entities (i.e. games, fonts, sprites, modules, etc).   It seems to me that the number of programmers and engineers here at AGS are increasing and so likely an increased demand for this.   

First of all stop trying to come up with a game idea, if you try too hard it will never come to you.  You hve to kind of let it come to you.  Start by trying  to get some inspiration.   Take a note book with you and go have lunch somewhere where there are people.  Watch the people around you.   Pick out a really old looking guy and try to imagine how he looked when he was 14 years old.  Ask yourself what kind of life's journey brought him to where he is now.  Pick out other people that have some interesting characteristic and make up stories about them.   Pick out some interesting scenery and make up a story about it as well.  Imagine that it is somewhere in the past, future, another country, or another world, etc.   Or just pick out some of the elements and use them to imagine another place.

Next use some of the above inspiration to start developing characters.   Start with one character and start telling yourself stories about that person.  Give them names, nationalities, strenghts and weaknesses of character, personality, physical traits, etc.   I find that once I have a collection of good characters that the stories tend to tell themselves.

If you get this far you should be well past writer's block...

First you need edit the Gui as follows.

1.  Open the desired GUI and give it a script name, something like gStatusline.

2.  Add a label contol to the GUI.  There should be some toolbar buttons above the GUI window in the editor, you can mouse over them to see a tool tip "Add GUI label".  Click on the button and then move your mouse to the GUI and drag a rectangle there.   

3.  Give a script name to the label something like gStatusLineXp. 

Next you will need to add some code to the repeatedly_execute() function in the global script.

function repeatedly_execute()  {

   // Write a value to XP
   gSTatuslineXp.Text = String.Format("%d", GetGlobalInt(2));

}

That should be it!

I cam across this article in wired.com magazine in which David Byrne and Thom York are interviewed about their latest album and how it worked out for them selling on the net for a name your own price.   

It turns out the gambit was a savvy business move. In the first month, about a million fans downloaded In Rainbows. Roughly 40 percent of them paid for it, according to comScore, at an average of $6 each, netting the band nearly $3 million. Plus, since it owns the master recording (a first for the band),

FullArticle

And for anyone who thought I was perhaps being insincere in voicing my concern over the erosion of "Fair Use" in copyright you can read this Washington Post article where a man is being sued by the RIAA for having copies of his legally purchased CDs on his computer.

... In legal documents in its federal case against Jeffrey Howell, a Scottsdale, Ariz., man who kept a collection of about 2,000 music recordings on his personal computer, the industry maintains that it is illegal for someone who has legally purchased a CD to transfer that music into his computer. ...

FullArticle

Happy New Year

BUG: Changing GUI dimensions

Executing either of the following statements causes a run-time error "Error SetGUISize Invalid dimensions.  I tried various values all with the same result.  The game resolution is 320x200x8.

   gReport.Height = 100;
   gReport.Width = 50;

Take the semicolon off the end of the #define line. Larry Values!!11

What a dufus I am!!!   Thanks Steve...