Messages

When you do Ctrl-S to give yourself all inventory items in "use hi-res mode", everything gets crunched up (I'm 800x600, 32bit color mode). This is part of the screen:



Outside of Ctrl-S mode, when you invoke the inventory window gui, it appears correct  (items spaced out ok EDIT: I spoke too soon -- they seem cramped too) except that the clickable area of each inventory item seems to be incorrect (I can only activate an item if I click in the top left half of it).  Do I have to change this manually somehow?

Ctrl-W doesn't place you on a walkable area any longer, or else uses an incorrect map.  Ctrl-A shows old lo-res walkable map.

Ctrl-D works great!

UPDATE:  the arrow keys seem to be broken -- do I have to load an updated keyboard module?

Region code seems to have got broken.  I can't draw a region using the blocky thing in the editor under 3.1 beta 3a using either resolution mode.  (check out the 640 x 400 hi-res roger buggy test, above).

Have been working on converting all coordinates (isn't going to be as bad  as I'd originally thought).  With the "use high res mode":

In my Darkdevil game (800 x 600, 32bit color, regions aren't responding to walk-on/off events.

Also, the text gui I'm using for dialogs didn't get scaled up, so everything wraps in a squished space. Is there a textbox width command I'm missing?

Is it my imagination, or are NPCs running more slowly?  I felt compelled to double the speed of the NPC on my opening screen (a bus that uses waypoints).

I have about 20 rooms of a 800 x 600 res game (Darkdevil County) more or less completed, some with a fair amount of scripting.  The "keep lo res" mode doesn't work the way I'd thought it would, however, since all screen coordinates settable in the room properties panes get converted.  In particular, even though on the screen hotspots look right, when you move the mouse over them or try to run an interaction, the coordinates aren't right. 

My little roger example I'd uploaded for my hotspot misunderstanding shows what's wrong immediately.  You can change object x,y and hotspot walkto points in script, but not the x,y of the real estate they cover in the room editor pane (which is always hi res).

This is the original demo -- if you open it and run it under any of the new 3.10 versions and toggle the hi/lo res feature you'll see what I mean, I hope.  The status line is supposed to update when over the hotspot, etc.  The program runs just fine if you switch to hi res coordinates, however, since there's no coordinate stuff happening in the scripts.

Buggy Test.zip

As to going thru and doubling everything in the Darkdevil game -- well, this is what you get by not listening when your mother told you never ever to hardwire anything!  Conversion program, anyone?

The new dialog option to run loops works great for me.  Doing stuff in actual screen coordinates is going to be great when I get everything converted.  Until then...

The character always chops off for me in this screen too -- it got fixed on one of the other character screens (the view screen), but not here yet.  The problem on the other screen had something to do with size of sprite and game resolution (my game is 32 bit color, 800 x 600 res).  Maybe here too.  You can work around it by looking at the character loops from the "view" menus rather than clicking on the "character" menu.

How do you call the new dialog feature?

I don't get that one (maybe I do, but I haven't created a new game recently), but the last line of sprites in the sprite display window always chops off the number of the sprite in a folder with a lot of sprites unless I fiddle around with scroll bars and resize windows, like things used to do with the dialog windows.  I'm a 120 DPI person. It's forced me to split stuff into folders, which is probably a good thing.

EDIT: Fixed in 3.03 Exam Profanity Edition

I have a room that uses a dynamic sprite with an alpha channel as part of an animation.  If while playing I save the game in that room, and then load it from a different room, the alpha channel transparency doesn't load back in.  The animation runs fine otherwise.  The sprite is the correct one, but the alpha channel didn't load, so everything is completely opaque.

I created my dynamic sprite using the "keep alpha transparency" option (ie, the "true" switch).  I assigned the dynamic sprite graphic it to the graphic of my animation frame for my object.  I haven't checked whether I get the same problem if I use an animated button on a gui.

The animation runs correctly before I save and if I change rooms and return.

The declaration of the dynamic sprite *variable (and the viewframe *variable) are local to the room but outside all the functions (I double checked, for once!).  The room is a state-saving room.

I'm using standard 3.02 without service pak 1, 32 bit color, 800 x 600 res.

It works!  I deleted a sprite, compiled, and it works.  Also works with adding a sprite and moving it into a different folder.  You are a genius

What ended up being the problem?

If I just edit room and global scripts, then rebuild the exe, everything works fine.  Once I remove a sprite, running the exe tosses up the same message consistently.

EDIT: Ok, I tried adding a sprite, and it gets the same message.  It looks like any time there's a sprindex.dat file present in the game directory the exe will fail.

So, to work around this right now I have to 1) compile exe 2) exit AGS editor 3) go to game directory and delete sprindex.dat file.  4) execute exe

(error continues if I try to run exe in editor without exiting) Then the exe appears to work (at least thru the first few rooms -- main character's walkcycles, a few inventory objects -- haven't tried playing thru to see if there's downstream problems yet.)

That fixed it for me, too.  Thanks.  I love you guys. 

My Darkdevil game, like Twinmoon's, was started using  the first 3.00.  I've upgraded to every beta you've posted along the way ever since.

Is interesting -- the game I created the other day for my hotspot misunderstanding and uploaded (probably using one of the beer releases, or latest Final RC1 -- you may still have it, if not, it's still online, including all source) does compile to an exe and runs.  I created it from the default game template and only used the default sprites (roger, the key) that came with.

AGS Demo Game.zip

The above link is the compiled exe of the current demo game, which gets the same error.  It was compiled using whatever defaults were in the demo source -- I didn't resave it or anything.

No, I didn't split resource files -- have played around with size of sprite files in the winsetup, but didn't do anything with the AGS Demo setup.

I have a Dell 5150 running xp service pak 3.0, with security patches as of the latest (the June 20th revised bluetooth patch), 512 memory, other specs you can see from the dump.

The only thing I haven't done is uninstall all versions of AGS and reinstall.  I'll try that if you suggest.

This was the first time I tried compiling an exe file since I uploaded Darkdevil County 1.01 (link in the "in production" thread), which works just fine -- exe is dated June 10, ver. 3.02.1024 .

Here's hoping it's something dumb I've done....if you need it, I'll upload the Darkdevil compiled folder.

Have been having no problem running my game from within the debugger, either full screen or windowed.  Went to compile (under Final RC2 -- just noticed you made it prod), file compiled, but when I ran the exe I got the following:



I rebooted, removed virus protection and anything else that might be running and taking up memory, and still get the same error.  It runs just fine within the debugger, even if I have my huge graphic program running in background.  What's the scoop?  Since releasing my demo a week or so ago, I haven't added a whole lot to the game -- in fact, I removed a lot of sprites I hadn't been using.

UPDATE:  I get the same message if I compile and try to execute the demo game outside of the debugger.

I seem to be good at coming up with bugs that aren't really bugs!

What confused me was that I got the parse error not just using the macro (which I know from C programming can have all sorts of side effects, etc.) but by using plain -5 as well.  I couldn't find anything in the doc about operator use and precedence (and the discussion of right to left/left to right) that would cause it.

I'll use the method suggested above for my constants.  Thanks.

Math bug  (Using latest Build 3.0.2.42)

Problem with negative numbers.  Example:

#define MY_CONSTANT -5

int a;
int b = 2;
int c = MY_CONSTANT;   //same result with c = -5

The following works:

a = b * c;

However, if I do the following,

a = b * MY_CONSTANT;  // same result with  a = b * -5;

I get a parse error:

Parse error: invalid use of operator '*'

However, if MY_CONSTANT is a positive number, I don't get the error.

(It doesn't matter which operator I use -- a negative constant generates
the same message whether it's *,+,-, or /)

Got the following while flipping between editing a room and editing the script for the room.  Was trying to use dropdown list for room to find code I'd just written for an animation.  Editor didn't exit, it just gave this message and let me go on with editing the room.

Error: startIndex cannot be larger than length of string.
Parameter name: startIndex
Version: AGS 3.0.2.41

System.ArgumentOutOfRangeException: startIndex cannot be larger than length of string.
Parameter name: startIndex
   at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
   at AGS.Editor.ScintillaWrapper.GetPreviousPathedExpression(Int32 startAtPos)
   at AGS.Editor.ScintillaWrapper.ParsePreviousExpression(Int32 startAtPos, String& charactersAfterDot, Boolean& staticAccess, Boolean& isThis)
   at AGS.Editor.ScintillaWrapper.GetFullTypeNameAtPosition(Int32 charIndex)
   at AGS.Editor.ScintillaWrapper.GetFullTypeNameAtCursor()
   at AGS.Editor.ScriptEditor.OnGetHelpKeyword()
   at AGS.Types.EditorContentPanel.get_HelpKeyword()
   at AGS.Editor.Components.HelpCommandsComponent.CommandClick(String controlID)
   at AGS.Editor.GUIController._mainForm_OnMenuClick(String menuItemID)
   at AGS.Editor.MainMenuManager.MenuEventHandler(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I understand now.  Thanks for spending so much time on this.  Am sorry I was beginning to sound a little nutty.

GOAL: He's trying to walk to an x,y (using the mouse walk mode) close to where the key is so he can be close enough to pick it up (roger and key are both on the same hotspot).  He can get close with the arrow keys but not the mouse (in walk mode, not hand mode -- hand mode of course makes him go to the hotspot walkto point.).

I can't make him walk close to the object (which is at a y > walktoy) once he's on the hotspot walkto point using mouse walk mode.  His walk cycle (which has diagonal loops) forces him in a diagonal path to either side of the hotspot x,y as he walks toward y>walktoy from his position at walktox, walktoy. (150,150 in the little game). If you try it without diagonal loops, the walk boundary goes across the x coordinate.  Walking toward y = 0 is always ok.

Is it possible it's just my computer?  (or me?) I apologize for taking up so much of your time.  I have an old dell laptop, running 120 dpi, XP Professional Service Pak 3.  This was done in the most recent 3.02RC2.  I also uploaded the 2 rooms if anyone wants to look at it.  Maybe I'm doing something wrong.

In my actual game I have a lot (like 20 hotspots) of stepping stones in a moving river my character must hop onto, some of which may have treasure on it, some traps.  I was getting frustrated trying to arrange the objects, which is how I found this.

If no one else has this problem, maybe it's some dumb nvidia thing.  I've come up with a couple of workarounds (with hardwiring and using object references instead), so it's not at all a priority with me.

Still.  I thought you Ought To Know.

I just found it strange that if I'm standing on a hotspot I can't walk around on it if I have a walktox,y set.  Since I can walk around on the hotspot for y-values lower than the hotspot x/y coordinate but not for y values greater than it, it felt like a bug.  If it's not, it's no big deal.  I posted the little roger example to show you what I meant.

Movement Test.zip

The above link shows the problem (2 little rooms with roger moving around trying to get at an object that's on the hotspot).  1 room is an animating room, the other non-animating -- both have the  same problem (I was wrong in prev. post).  Roger has diagonal loops set, so his movement goes off at an angle.

UPDATE: below is a link to all the files if you want to take a closer look.
Buggy Test.zip

The test actually makes for a challenging little game, since starting and stopping movement using the arrow keys can be tricky.  (this was unintended!).

It only seems to happen in the animated room -- I can walkto left,right and toward y=0 with the mouse, but can't walkto y=maxy for any y greater than the hotspot y.   I'm sure I have hotspots elsewhere that I walk to, but then can move around freely on and off of.