This is the pre-release final version of AGS 2.7. This means that this is effectively the final release, but due to the extent of the changes in this version it's likely there may still be bugs outstanding. But it should now be safe to try out (remember to back up your game before upgrading) and see if you get any problems.
The main difference of 2.7 to previous versions is object-based scripting.
If you're trying it out for the first time, please read the upgrading guide (http://www.adventuregamestudio.co.uk/manual/UpgradingTo27.htm) to get you started.
Changes from Pre-Final 3 to Final:
* Added Character.Speaking property.
* Changed Test Game behaviour to hopefully fix problems with it hanging.
* The mouse.x/y variables are now updated for rep_exec_always.
* Auto-number speech lines now does global and room messages if Narrator speech is selected.
* Auto-number speech lines now tells you which room the error was in, if there is a compile error when re-compiling.
* Updated Intro to Scripting Tutorial to mention OO-style.
* Fixed RunAGSGame crashing if called from a custom script function.
* Fixed interactions getting disconnected and other problems after deleting an object.
* Fixed free disk space crash on game startup on some Win9x systems.
* Fixed clickable z-order of GUI controls to be the same as the visual z-order.
* Fixed occasional animation glitch if the previous loop in the view had no frames.
* Fixed speech animation not playing if DisplayMessage was used with a room message set to display as character speech.
* Fixed dialog scripts not recognising character names with numbers in them.
Changes from Pre-Final 2 to Pre-Final 3:
* Significantly improved script compile speed.
* Added enum for CDAudio first parameter.
* Added GP_NUMINVITEMS to GetGameParameter.
* Fixed pixel-perfect click detection not always working properly with flipped sprites.
* Fixed compile error if you had more than 500 functions in the global script.
* Fixed potential memory overrun crash error in script editor.
Changes from Pre-Final to Pre-Final 2:
* Added Character.Tint/RemoveTint
* Added GUI button Clip Image option, along with corresponding Button.ClipImage script property.
* Fixed single-word words not being compatible with multi-word words that started with the single word in the text parser (ie. "pick" and "pick up" can now both be used successfully)
* Fixed < and > with floats giving spurious compile errors.
* Fixed Auto-number speech lines to work with .Say as well as DisplaySpeech; and also added an option to number Display() lines for the narrator.
Changes from RC3 to Pre-Final:
* Double-clicking a GUI or GUI control now edits its script, rather than it being done via editing the name of the script function.
* Added option to select the transparency and palette settings for the Quick Import options.
* DisplaySpeech no longer changes the mouse cursor if the cursor mode is already the Wait mode.
* Fixed #defined names so that they are not replaced if preceded by a dot.
* Fixed script editor not saving changes if you typed a comma early on while editing an interaction script.
* Fixed GUI Editor allowing you to add controls to a text window GUI.
Changes from RC2 to RC3:
* Added read-only Character.NormalView property.
* Increased max overlays from 10 to 20.
* Any warning messages encountered while loading a game or a room are now written to log file agsedit.log in the game folder to enable easy reviewing.
* PlaySound now returns the channel number that the sound is playing on.
* An error message is now displayed if you try to change an object's X/Y position while it is moving.
* Fixed Character.AddWaypoint not working.
* Fixed ClaimEvent not working with nested events (eg. NewRoom inside on_mouse_click).
* Fixed error message if you had more than 6 script modules.
Changes from RC1 to RC2:
* Global variable enums can now be initialized with enum values.
* Global variable names can now be used as parameter names for 'import' definitions (fixes plugins using an "int object" parameter and so forth).
* Importing a new background with a different size to the old one now gives you an opportunity to cancel.
* Script modules now support on_event and repeatedly_execute_always.
* GUI Control script names can now contain digits 0-9.
* goto-previous dialog command now stops the dialog if there is no previous topic, rather than aborting the game.
* Enabled Quick Import sprite options in 256-colour games.
* Renamed the manual to "ags-help.chm" to make it more obvious what it is when accessing it externally from the editor.
* Fixed PlayMusicQueued skipping some tracks if crossfading was enabled.
Changes from Beta 18 to RC1:
* Added plugin API functions NotifySpriteUpdated, SetSpriteAlphaBlended, QueueGameScriptFunction, RegisterManagedObject, AddManagedObjectReader and RegisterUnserializedObject.
* Added mouse.ChangeModeView function.
* Changing a character's script name now forces a re-compile of the dialog scripts.
* Script names can now contain the digit 0-9 after the first character.
* Enum variables can now be initialized using the enum options.
* Fixed SetChannelVolume not working properly with the ambient sound channel.
* Fixed solid characters not blocking properly bug, introduced in an earlier beta.
Changes from Beta 17 to Beta 18:
* Added script module support for game_start, on_key_press, on_mouse_click and repeatedly_execute.
* Added Left-to-right operator precedence option, along with LRPRECEDENCE define to allow you to check whether it's ticked.
* Added File.ReadRawLine method to enable you to easily process text files.
* Added current room number to Room Areas pane.
* Compiler now checks that array size defined in header matches that defined in the global script.
* Renamed intro.crm to room0.crm, so that it causes no further confusion.
* Improved accuracy of GetMP3PosMillis and voice lip-sync with OGG speech files.
* #define-type lines can now be indented with tabs as well as spaces
* Added short manual page describing script modules.
* Changed shortcut key for Freehand tool in Room Areas to Ctrl+D to stop it conflicting with Edit Script (Ctrl+E).
* Fixed autocomplete not working if a variable's name was a substring of its type.
Changes from Beta 16 to Beta 17:
* Added export/import single GUI function.
* Added #error directive to script language.
* Added Crop Sprite Edges Symmetric option, to leave the central pivot point of the sprite unchanged.
* Added script o-name to characters tab.
* Added enums for parameters to StartCutscene, SetDialogOption, SetSpeechStyle and SetVoiceMode.
* Updated Text Script Equivalent Code in interaction editor to new OO standards.
* Fixed misleading line numbers being given if an error occurred just after returning from a function.
* Fixed tooltips for Diagonal Loops and Solid in Characters tab.
* Fixed object and hotspot o-names not being available in the script editor if you had only just created them.
* Fixed slider background image not being exported as part of Export GUI.
* Renamed "Anti-alias scaled sprites" to "Smooth scaled sprites" in the game Setup program.
Changes from Beta 15 to Beta 16:
* Added back on_event eEventGUIMouseUp and eEventGUIMouseDown.
* Added Object.StopAnimating command.
* Added game.show_single_dialog_option to specify that the dialog option should be displayed, even if only one is available.
* Improved game startup speed and room loading speed.
* Changed script editor Discard Changes shortcut key to Ctrl+E, because Ctrl+D was already used for Duplicate Line.
* Dump Text feature now dumps module scripts, where permissions allow.
* Fixed InventoryItem::IsInteractionAvailable not working.
* Fixed custom inventory window drawing too many columns or rows in hi-res mode.
* Fixed BlinkView and ThinkView giving an error if they were set to -1.
* Fixed Paste From Clipboard sprites getting given an alpha channel if you previously imported an alpha-channel sprite from a file.
* Fixed rare crash which could occur with MoveObject.
* Renamed Talking View to Speech View in Characters tab of editor; renamed Can Be Walked Through to Solid, and renamed No Diagonal Loops to Diagonal Loops.
* Renamed Character.DiagonalWalking property to DiagonalLoops.
* Renamed eEventEnterRoom to eEventEnterRoomBeforeFadein
* Renamed Label.Color property to Label.TextColor
Changes from Beta 14 to Beta 15:
* Converted remaining character variables to properties (AnimationSpeed, Frame, Loop, WalkSpeedX, WalkSpeedY, x, y, z)
* Added GUI OnClick handler to provide a more intuitive way to handle clicks on the GUI background.
* Added autocomplete for enums when using = or == with an enumerated type.
* Added Button.TextColor property.
* Added optional index parameter to AddInventory; and added InvWindow.ItemAtIndex[] property.
* Added EventType enum for on_event
* Added confirmation prompt in script editor if you choose "Discard and exit"; and added Ã, shortcut keys for the exit options.
* Increased max custom properties from 20 to 30.
* Renamed GUI "Foreground color" property to "Border color" since that's all it does.
* Renamed "No interaction" character checkbox to "Clickable" (and thus reversed its behaviour) to make it consistent with the script.
* Move Up/Move Down in script module manager now cause the scripts to be recompiled.
* Fixed autocomplete behaviour with "GUI" vs "gui", "Object" vs "object" etc
Changes from Beta 13 to Beta 14:
* GUI control event functions now take a GUIControl* parameter, representing the activated control. This allows you to use the same handler function for multiple controls, and distinguish which was clicked. Note that if you have any existing event handlers they will no longer work -- you need to add a "GUIControl *control" parameter AS THE FIRST PARAMETER.
* Added ability to use a sprite as the inventory cursor hotspot dot.
* Added enum values to the normal autocomplete list.
* Added Visible property to GUI controls.
* Added AbortGame function to allow script modules to perform checks on their parameters and easily give an error.
* Added Introduction to Pointers section to the manual.
* Updated Default Game and Empty Game templates to object-based scripting.
* Fixed "address too high" error which could occur on some computers.
* Fixed custom inventory windows, which I broke in beta 13.
* Fixed editor crash if you saved the game after creating a script module but without editing its script.
Changes from Beta 12 to Beta 13:
* Added script module support, so that you don't have to cram everything into the global script. This also allows you to easily share code with other people by exporting the module.
* Added script call stack when an error occurs, rather than just the current line number.
* Added support for arrays of pointers.
* Added editor warning message if you Save Room As to a filename that's not roomX.crm or intro.crm
* Added BlinkWhileThinking character property.
* Local variables are now automatically initialized to 0.
* Renamed SaveUntilLocationChange to SaveCursorUntilItLeaves
* Obsoleted GetPlayerCharacter since it is now done with player.ID
* Fixed SetInvDimensions not overriding things properly for backwards compatibility.
* Fixed compile error if one of your GUIs was named "GUI".
Changes from Beta 11 to Beta 12:
* Added 'writeprotected' keyword to allow you to have public read-only member variables.
* Objectised the custom InvWindow (ie. game.top_inv_item becomes invWindow.TopItem), and in the process improved it so that each inv window can display inventory for a specific character, and the inventory item order for each character is remembered.
* Objectised GetTime and GetRawTime since the old way that GetTime worked was horrible.
* Objectised dynamic sprite functions in order to allow automatic disposal of the sprites when the instance is freed. Added DynamicSprite.CreateFromScreenShot as a way of allowing you to get the current game position for a Save with Screenshots GUI.
* Dynamic sprites are now persisted in save games.
* Converted character.inv[] to Character.InventoryQuantity[] property, and added read-only Object.View property.
* Renamed GetXXXXAtLocation to static function XXXX.GetAtScreenXY
* Renamed structs from GameCharacter and GameObject to Character and Object respectively, to make it more intuitive.
* Changed the following functions to take Character* and Object* parameters rather than ints: Character.FaceCharacter, Character.FaceObject, Character.FollowCharacter, Character.IsCollidingWithChar, Character.IsCollidingWithObject, Character.ActiveInventory, Object.IsCollidingWIthObject
* Character.SayBackground now returns an Overlay* rather than the overlay int id.
* Ctrl+Space now allows you to pop up the autocomplete list at any time, like in Visual Studio.
* If Split Resources Files is checked, the sprites are now put into the .001 resource file to stop the EXE getting too big (since it could cause performance problems due to anti-virus software).
* Put some of the most commonly used buttons back on the Room Settings and GUI panes for people who don't like shortcut keys.
* Fixed FollowCharacter not working on two NPC's if Hide Player Character was ticked in the room.
* Fixed editor crash if you deleted a sprite folder whilst editing its name.
Changes from Beta 10 to Beta 11:
* Added support for global pointers in script, so that you can declare a global variable as a pointer. But, consequently:
* SaveGameSlot/SaveGameDialog are now delayed-response functions, just like the RestoreGame ones. This means the game won't actually be saved until the script function finishes.
* Object-ised Overlay functions now that global pointers are supported.
* Added GUI.ControlCount and GUI.Controls[] property, to give you access to the GUI's contained controls.
* Added GUIControl.AsButton/AsLabel/AsListBox/etc to enable you to convert a generic pointer to a specific type.
* Added pathing support to script, so you can doÃ, lstList.OwningGUI.IDÃ, orÃ, gui[3].Controls[2].AsListBox.AddItem();Ã, and so on.
* Added GUI.Width/Height and GUIControl.Width/Height properties.
* Added [ to Display/Say/etc, to enable you to display the [ character rather than it doing a line break.
* Added "Built in enumerated types" page to the manual, listing all the built-in enums.
* Added enum for GetLocationType return value.
* Objectised IsButtonDown into Mouse.IsButtonDown (almost forgot this one!)
* Changed editor terminology from "GUI objects" to "GUI controls" to stop any confusion.
* Fixed FloatToInt not working properly with negative numbers.
* Fixed IsKeyPressed(13) not working with the numeric keypad Enter key.
Changes from Beta 9 to Beta 10:
* Object-ised hotspots, regions and inventory items. Added script names for hotspots and inv items.
* Changed Character.AddInventory/LoseInventory to take the inventory item object rather than the number. For example:
player.AddInventory(iSmallKey);
* Object-ised GetHotspotAt/GetCharacterAt/GetObjectAt/GetRegionAt/GetInvAt to work like GetGUIAtLocation does.
* Added character.ID, object.ID, GUI.X, GUI.Y, GUIControl.X and GUIControl.Y properties.
* Changed MOD music player from JGMOD to DUMB, and consequently:
Ã, Fixed some previously unsupported S3M's music files not playing.
Ã, IT Impluse Tracker format mod files are now supported (music*.it)
* Removed various buttons on the Room Settings and GUI panes, and moved them to new Room and GUI menus, respectively.
* When upgrading an old game, you can now proceed without upgrading the room files (to allow you to just look at, but not actually upgrade, an old game).
* Fixed GUI editor not allowing you to set a label text longer than 25 characters.
* Fixed multi-word words not being allowed in text parser if you changed an existing word.
* Fixed MoveCharacter error messages if a character was following another character and neither were in the current room.
So what's this all about?
Well, I've been having a jibble with the script language lately, and this is its latest state. The main feature here is member function support -- meaning, structs can have functions within them.
What's the point?
It's more intuitive, and more elegant. It also reduces the chances of making mistakes.
Consider this, for example. At the moment, to move the player character you'd do this:
MoveCharacter(EGO, 100, 50);
That's fairly simple -- but you don't always know which functions work on a Character. For example, "StopMoving" stops a character moving but its name doesn't imply that.
So, consider the previous scripting line with the new system:
character[EGO].Walk(100, 50);
With the script editor's autocomplete now supporting struct members, this also means that you can type "character[EGO]." and it will pop up a list of valid methods that you can call on the character.
Where's all this going?
My long-term goal for the scripting language is to bring it up to an object-based standard, on a par with Visual Basic 6. This is in no way fully object oriented, but should be plenty good enough for AGS's purposes.
So am I going to have to change all my scripts?!?!?
No, don't worry - the old MoveCharacter commands will still work as well. But once this new approach has fully matured (hopefully by the 2.63 2.7 Final release), I'll be recommending that all new script is written in the new way.
So er, what's the point of this beta again?
EDIT for beta 2: This beta now implements the complete set of Character functions. They should all work identically to the old MoveCharacter-style functions, so please do try them out.
Because the script language has been changed fairly extensively, I'm basically after people testing it and making sure it doesn't break or crash or anything like that.
Can I create my own member functions?
Yes! To do this, declare a struct in your script header, in the usual way. Then, just add a function import inside it. For example:
struct TestStruct {
Ã, Ã, int total;
Ã, Ã, import function AddToTotal(int amount);
};
Then, in the global script, add this:
function TestStruct::AddToTotal(int amount) {
Ã, this.total += amount;
}
What else do I need to know?
This beta also implements array bounds checking in the script. This should mean that if you do this:
int myArray[5];
myArray[7] = 2;
the engine will generate an error message, rather than leading to the sometimes mysterious results that can otherwise occur.
To emphasise the different nature of this beta, only the essential changed files are included. You can get the missing ones from the 2.62 distribution:
REMEMBER, BACK UP YOUR GAME BEFORE TRYING OUT A NEW VERSION
http://www.adventuregamestudio.co.uk/ags27final.zip
Sweetness, I'll have to test it.
Wow, incredible. I will look at it the best I can.
JD
This is nuts.. but also it's awesome because my scripts were getting a little too complicated to look at. I'm just going to have to wait for 2.63 final to polish my game.
... but I'll test it with BJ Source! ;) I unfortunately cannot test performance, because I have a Pentium 4 2.0 ghz and ags runs like it's notepad :P
Simply wonderful!
I think that OO scripting will be a giant step forward for AGS.
Thankyou CJ!
I'll try the "experimental" beta as soon as I have a bit of spare time (sigh)
:D YES! finally!
as it's going more to the VB6 way will you be getting rid of the ;'s at the end of each line??? if not maybe make some kind of thing that does it by itself????
No let the ; stay. For all of us that program in C or Java it's comfortable to end a line with a semicolon.
And nice work with the objectorientation. It's certainly the right way to go with the scripting-language. Great work as usual, CJ!
Quote from: fovmester on Sun 14/11/2004 09:21:46
No let the ; stay. For all of us that program in C or Java it's comfortable to end a line with a semicolon.
And nice work with the objectorientation. It's certainly the right way to go with the scripting-language. Great work as usual, CJ!
how about an option in the general settings to have old-style AGS scripting OR new. that way both sides will win (but'd prob take longer and harder to make updates :-\ )
Quote from: Dan2552 on Sat 13/11/2004 23:12:33
as it's going more to the VB6 way will you be getting rid of the ;'s at the end of each line??? if not maybe make some kind of thing that does it by itself????
Perhaps I should clarify -- I am in
no way intending to make the scripting language more like VB; it has a horrible syntax that is prone to mistakes.
The comparison I'm drawing with VB6 is the level of object-orientation I am aiming for.
Yay... I hope this new feature will in the future generate some cleaner code for my interface's... :)
Quote from: Pumaman on Sun 14/11/2004 13:34:41
Quote from: Dan2552 on Sat 13/11/2004 23:12:33
as it's going more to the VB6 way will you be getting rid of the ;'s at the end of each line??? if not maybe make some kind of thing that does it by itself????
Perhaps I should clarify -- I am in no way intending to make the scripting language more like VB; it has a horrible syntax that is prone to mistakes.
The comparison I'm drawing with VB6 is the level of object-orientation I am aiming for.
ok. so the only thing being changed to like VB is the easyness of blah.blah = "blah"
i guess it wouldn't work too well without the ;'s. but still maybe one day an option to try and add all the semicolons itself? that would be hard to code though..
I think the C-style scripting is here to stay, which I think is much much easier than the BASIC-style scripting, which should have died like 1000 years ago.
Chris, since you mentioned having suggestions for the new names, I'd like to dedicate this reply to it.
First of all, I think it's a good time to develop the whole naming conventions thing that has been talked about before, and maybe rename some of the functions to something standard and more intuitive. For example, NewRoom, and NewRoomNPC would be character[CHARID].ChangeRoom() or something like that, or maybe just leave it NewRoom.
A concern I have is that with all of these name changes, will the newer version be backwards compatible? and wouldn't that clutter the engine like all backwards compatibility things do? Maybe you should have three versions of the interpreter: Strict (New scripting form only), Transitional (both), and Classic (the one up to 2.62)
I would really say that the whole scripting thing would even derserve the 3.0 stuck to the AGS.
One more question, can there be overloaded functions? that way if you have NewRoom for NewRoom and NewRoomEx, for example.
Quote from: Pumaman on Sun 14/11/2004 13:34:41
Quote from: Dan2552 on Sat 13/11/2004 23:12:33
as it's going more to the VB6 way will you be getting rid of the ;'s at the end of each line??? if not maybe make some kind of thing that does it by itself????
Perhaps I should clarify -- I am in no way intending to make the scripting language more like VB; it has a horrible syntax that is prone to mistakes.
The comparison I'm drawing with VB6 is the level of object-orientation I am aiming for.
i think i'm getting your point now. maybe delphi would have been a better example... that still uses like
blah.blah and uses a semicolon
dont bother explaining it if i get it wrong :-\ you must spend as much time as you can actually updating rather than telling me i'm stupid. ;)
Quote from: netmonkey on Sun 14/11/2004 21:52:15
thing that has been talked about before, and maybe rename some of the functions to something standard and more intuitive. For example, NewRoom, and NewRoomNPC would be character[CHARID].ChangeRoom() or something like that, or maybe just leave it NewRoom.
Good idea, I think ChangeRoom is more intuitive than NewRoom. In fact, I was thinking of scrapping NewRoomEx and instead having a character[].SetPosition(x, y) function. Although, that would mean two lines of script instead of one for room changes, so do give me your thoughts, people.
Another thing in terms of naming conventions is to do with the blocking functions. The current system is rather disjoint (some are blahblahBlocking, others have blocking as a parameter, etc); what do people prefer? Or would you in fact prefer to have some sort of character[].blocking attribute, which would then affect all future Move/Animate/etc calls, until you changed it again?
Quote
A concern I have is that with all of these name changes, will the newer version be backwards compatible? and wouldn't that clutter the engine like all backwards compatibility things do? Maybe you should have three versions of the interpreter: Strict (New scripting form only), Transitional (both), and Classic (the one up to 2.62)
The engine clutter is minimal -- internally, both MoveCharacter and character[].Walk point to the same engine function, so it's not much overhead to support.
However, I am planning on a Strict option in the editor, which will only allow you to use the new command names.
Quote
I would really say that the whole scripting thing would even derserve the 3.0 stuck to the AGS.
Well, perhaps 2.7, depends on how extensive the changes turn out to be.
Quote
One more question, can there be overloaded functions? that way if you have NewRoom for NewRoom and NewRoomEx, for example.
That's a possibility -- I'm not sure if they would turn out to be more confusing than useful though.
Personally, I would prefer blockingness to be a parameter to the function. I think the function parameter syntax could be more consistent, it doesn't matter much to me which way you make the consistency.
Maybe you could do 'default' parameters? As in the C++ syntax, MoveCharacter (int charid, int x, int y, int blocking = 0, int direct = 0), would that be a viable solution?
Good work CJ. It's nice getting more towards object orientated, as I now understand it from learning C++ at uni. When I get around to making a game it will be great to use this style of coding.
Ok, I think the easiest way forward is if I list my proposed changes to the Character functions, then feel free to reply and disagree if there's anything you'd like changed:
AnimateCharacterÃ, --> (deleted, use the one below instead)
AnimateCharacterExÃ, --> Character[].Animate(loop,delay,repeat,direction,blocking)
AreCharactersCollidingÃ, --> Character[].IsCollidingWithChar
AreCharObjCollidingÃ, Ã, -->Ã, Character[].IsCollidingWithObject
ChangeCharacterViewÃ, --> Character[].ChangeView(view)
FaceCharacterÃ, Ã, -->Ã, Character[].FaceCharacter(chartoface)
FaceLocationÃ, Ã, --> Character[].FaceLocation(x,y)
FollowCharacterÃ, Ã, (deleted, use the one below instead)
FollowCharacterExÃ, --> Character[].Follow(charid, dist, eagerness)
GetCharacterPropertyÃ, -->Ã, Character[].GetProperty
GetCharacterPropertyTextÃ, -->Ã, Character[].GetPropertyText
MoveCharacterÃ, --> Character[].Walk(x,y,direct,blocking)
MoveCharacterBlockingÃ, (deleted, use the one above)
MoveCharacterDirectÃ, Ã, (deleted, use the one above)
MoveCharacterPathÃ, Ã, -->Ã, Character[].AddWalkPath(x,y)
MoveCharacterStraightÃ, --> Character[].WalkStraight(x,y)
MoveCharacterToHotspotÃ, --> Character[].WalkToHotspot(hotspot, blocking)
MoveCharacterToObjectÃ, --> Character[].WalkToObject(object, blocking)
MoveToWalkableAreaÃ, --> Character[].PositionOnWalkableArea
NewRoomÃ, Ã, -->Ã, Character[].ChangeRoom(room, x, y)
NewRoomExÃ, Ã, (deleted, use the one above)
NewRoomNPCÃ, (deleted, use the one above)
ReleaseCharacterViewÃ, -->Ã, Character[].ReleaseView()
RunCharacterInteractionÃ, --> Character[].RunInteraction(mode)
SetCharacterBaselineÃ, --> Character[].SetBaseline
SetCharacterBlinkViewÃ, --> Character[].SetBlinkView
SetCharacterClickable --> Character[].SetClickable
SetCharacterFrame --> Character[].SetFrame
SetCharacterIdle --> Character[].SetIdleState
SetCharacterIgnoreLight --> Character[].SetIgnoreLight
SetCharacterIgnoreWalkbehindsÃ, --> Character[].SetIgnoreWalkbehinds
SetCharacterProperty --> Character[].SetOption
SetCharacterSpeechView --> Character[].SetTalkView
SetCharacterSpeed --> Character[].SetSpeed(x,y)
SetCharacterSpeedExÃ, Ã, (deleted, use above)
SetCharacterTransparency --> Character[].SetTransparency(amount)
SetCharacterView --> Character[].SetView
SetCharacterViewEx --> Character[].SetViewAligned
SetCharacterViewOffset --> Character[].SetViewOffset
SetPlayerCharacter--> Character[].SetAsPlayer
SetTalkingColor --> Character[].SetTalkColor
StopMoving --> Character[].StopMoving()
DisplaySpeech -->Ã, Character[].Talk(message)
DisplaySpeechAt -->Ã, Character[].TalkAt(x,y,width,message)
DisplaySpeechBackground -->Ã, Character[].TalkBackground(message)
DisplayThought -->Ã, Character[].Think(message)
SkipUntilCharacterStops -->Ã, Character[].SkipUntilDone
AddInventoryToCharacter -->Ã, Character[].AddInventory
LoseInventoryToCharacter -->Ã, Character[].LoseInventory
Question:
Is the whole SetView vs ChangeView thing confusing? It does seem to have caused problems in the past -- is there a better name for Change vs Set to better get across what they do?
real quick, for those that are being deleted for a more versitile version such as
animatecharacter for animatecharacterEx, can we drop the ex part, and just have animatecharacter like you did with newroomex and newroom?
None of the new names have an "Ex" in them :)
Oh, jeez, I wasn't thinking, I suppose, when I wrote that.
I will say that I very much agree with everything you've done carrying outÃ, with this idea. This will be quite an addition to AGS.
Will the "SetCharacterClickable --> Character[].SetClickable" allow for those who wan't to disable the clickable-ness of a character?
character[].ChangeRoom(room,x,y)
Are the x and y needed parameters? I hope not, because I've got used to moving the character to the appropriate location in the destination room, depending on the room the character came from. This way I can elimate the character ending up stuck outside a walkable area and all.
I like the new object oriented thing that's going on here. I do have two questins though:
1. Will there be any new written documentation to explain all of these new commands?
2. Seeing how the 1-letter word bug was fixed with the text parser, is there a chance that the two-word synonym feature will be added in 2.63 or will it be a later release? (e.g. "pick up" will be acceptable as a synonym for "get"). Right now, it simply looks like spaces are not accepted in words.
Thanks for all of your wonderful work, Chris!
Rich
Silly question, I suppose, but will "player" still be a substitute for "character[]"?
Oh, and is there no way to update "player" whenever the main character changes?
I think player is just internally defined like
#define player character[EGO]
Have you tried defining it yourself, like
// Main header script
#define player character[GetPlayerCharacter()]
?
Quote from: Ishmael on Mon 15/11/2004 21:13:42
character[].ChangeRoom(room,x,y)
Are the x and y needed parameters? I hope not, because I've got used to moving the character to the appropriate location in the destination room, depending on the room the character came from.
This sort of thing is exactly why I'm having this consultation. If you think it would be useful to keep a ChangeRoom command without co-ordinates, that can be arranged. :)
Quote1. Will there be any new written documentation to explain all of these new commands?
The manual will be updated to list the new commands before the Final is released.
Quote
2. Seeing how the 1-letter word bug was fixed with the text parser, is there a chance that the two-word synonym feature will be added in 2.63 or will it be a later release? (e.g. "pick up" will be acceptable as a synonym for "get"). Right now, it simply looks like spaces are not accepted in words.
I cannot make any guarantees about which suggestions will get into the next version and which will not, I'm afraid.
QuoteSilly question, I suppose, but will "player" still be a substitute for "character[]"?
Oh, and is there no way to update "player" whenever the main character changes?
Ideally I'd like to add this, but it's not a priority feature. We'll see how things go.
About blocking in Move commands, coordinates in ChangeRoom, etc.
I think the clearest thing is that ChangeRoom takes one parameter, the room number. Then SetPosition moves the character. Shoehorning multiple functionality, however related, into a function call is ugly, and unreadable.
Similarly, moving blocking out into a separate function means that you don't need multiple versions of every possible action. So I'm for it.
As for direct, I think that should be in the function name, so you've got Walk() and WalkDirect(). Much more readable than Walk(x, y, 1);
Looks like some great changes for AGS. It may make it more confusing for newbies, but they'll be learning...
Cheers,
Steve
Quote from: Ishmael on Mon 15/11/2004 21:13:42
character[].ChangeRoom(room,x,y)
Are the x and y needed parameters? I hope not, because I've got used to moving the character to the appropriate location in the destination room, depending on the room the character came from. This way I can elimate the character ending up stuck outside a walkable area and all.
couldn't that be just
character[EGO].ChangeRoom(1,character[EGO].x,character[EGO].y)
i cant remember if thats how AGS works. but if you think about it it should.
Very interesting changes!
I do have some suggestions on consistency, and clarity to new users...
How about LockView and UnlockView, rather than set and release?
Considering what it does, SetIdleState should be named SetIdleView.
This one is nitpicky, but I would like 'talk' renamed to 'say'.
I think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof. Come to think of it, it isn't entirely logical that 'char[].ChangeRoom' also changes the visible room if the char specified happens to be the player character, but I can't think of a good workaround.
If you're going consistent in removing 'Ex' and other related functions, then you should consider removing TalkBackground, and instead, making the backgroundness a parameter to Talk. And also maybe to Think and TalkAt.
Shouldn't MoveStraight have direct and blocking parameters?
AddWalkPath might be renamed to AddWayPoint, since that's what it actually does, and it might need a 'direct' parameter.
It doesn't really bother me, but this is inconsistent:
character[EGO].z = 10;
character[EGO].SetTransparency (10);
(e.g. logically, both would be a function or a member var; the advantage of making the latter a member var is that reading it or doing math on it is easier; that's just my preference, I know C canon states that you should use Set and Get functions).
Same thing applies to Add and Loseinv; I tend to use 'char
- .inv[y] = z' sometimes, so if you're making that read-only I would like to have a SetInv function.
For consistency, there is a FaceChar and FaceLoc, but no FaceObj. There is a MoveToLoc and MoveToObj, but no MoveToChar.
By the way, it would be nice to have a 'blocking' parameter to FaceCharacter / FaceLocation, since then you can use it in rep_ex_always to have an NPC keep watching the player character.
MoveToWalkableArea might be nice with a parameter that states if the character 'teleports' there (as it does now), or simply walks there.
Is it an idea to use 'default' parameters with functions (e.g. if the user doesn't specify a function's last parameter, a default value is used, like in C++)? Or would that be too confusing, or too annoying to code?
The three basic behaviors in AGI games (other than standing still) are chase, wander and avoid. Chase is obviously implemented, and I believe that Avoid isn't actually used in any AGI game anyway. However, it may be nice to add a function 'character[].Wander (int walkable_area_number, or maybe region_number instead)' that makes the character wander around randomly. Of course it's easy to put this in a script instead, but newbies might appreciate it.
Would it be possible to have SetCharView an option to also lock into a certain loop? So that it won't get changed to a direction loop if you move the character.
Unrelated to this, I believe GetTextWidth() should have a maximum width parameter. Why? Suppose I have a string that has no line breaks. If its GTW is larger than the screen's width, or it's put on a GUI label or something, it will get wrapped. But you can't tell in advance where exactly it will be wrapped.
QuoteI think the clearest thing is that ChangeRoom takes one parameter, the room number. Then SetPosition moves the character. Shoehorning multiple functionality, however related, into a function call is ugly, and unreadable.
I agree, to some extent. However, the reason that NewRoomEx was added in the first place was that people wanted a quick way to change room and set position in one go. Perhaps it would've been better never to introduce it, I don't know.
QuoteAs for direct, I think that should be in the function name, so you've got Walk() and WalkDirect(). Much more readable than Walk(x, y, 1);
I'd like to avoid having duplicate functions that do very similar things. However, what I will do is provide some defines (eg. BLOCKING=1, NON_BLOCKING=0) so that the function call is more readable in the script.
QuoteIt may make it more confusing for newbies, but they'll be learning...
Actually, I think it'll make it easier to learn. Just typing "character[EGO]." and being given a list of things you can do is easier to pick up than guessing which functions operate on a character :)
QuoteHow about LockView and UnlockView, rather than set and release?
Considering what it does, SetIdleState should be named SetIdleView.
This one is nitpicky, but I would like 'talk' renamed to 'say'.
LockView is a good idea -- I think that could still be partnered with ReleaseView, though I can see the argument for it to be called Unlock.
As for "Say", I agree actually that it's a better verb to use for the situation. If nobody objects, I'll use it.
QuoteI think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof.
Yeah, I thought the same thing. However, otherwise it becomes the only function that still takes a CHARID as a parameter, which I'm sure would confuse people who would try and use "character[EGO]" as the parameter, and so on.
So I'm not sure about this one.
QuoteIf you're going consistent in removing 'Ex' and other related functions, then you should consider removing TalkBackground, and instead, making the backgroundness a parameter to Talk. And also maybe to Think and TalkAt.
I did consider this, but I think Talk is one of those functions that should be as simple to use as possible, so I don't really want to add an extra parameter to it. I can see your point though.
QuoteShouldn't MoveStraight have direct and blocking parameters?
Well, there'd be no point in a "direct" parameter because then it would do the same thing as MoveCharacterDirect. A blocking parameter would be possible just for consistency's sake, although I can't see it getting used in this context.
QuoteAddWalkPath might be renamed to AddWayPoint, since that's what it actually does, and it might need a 'direct' parameter.
Good idea, I like how that sounds.
QuoteIt doesn't really bother me, but this is inconsistent:
Code:
character[EGO].z = 10;
character[EGO].SetTransparency (10);
I agree -- and in fact, one thing I have added since the beta is support for Properties. These are basically functions disguised as normal variables, which will mean that instead of doing
SetCharacterTransparency(EGO, 10);
you can do:
character[EGO].Transparency = 10;
It still actually generates code to make the function call so still works as it should, but is far more intuitive to use.
QuoteFor consistency, there is a FaceChar and FaceLoc, but no FaceObj. There is a MoveToLoc and MoveToObj, but no MoveToChar.
FaceObject is a definite possibility.
As for the MoveToXXX functions, I'm not sure whether to remove them completely ... all the co-ordinates can be obtained and then used with Walk anyway.
I don't think these really get used -- probably because of the somewhat arbitrary location that the character is moved to relative to the object. But do correct me if they're useful.
QuoteIs it an idea to use 'default' parameters with functions (e.g. if the user doesn't specify a function's last parameter, a default value is used, like in C++)? Or would that be too confusing, or too annoying to code?
That's something I'd like to add, yes. So that Walk, for example, would be non-direct and blocking by default, but you could specify the extra parameters if you wanted to.
QuoteHowever, it may be nice to add a function 'character[].Wander (int walkable_area_number, or maybe region_number instead)' that makes the character wander around randomly. Of course it's easy to put this in a script instead, but newbies might appreciate it.
This is certainly something to consider as a future feature -- but it doesn't directly affect this renaming exercise and can always be added as an additional function later on.
QuoteWould it be possible to have SetCharView an option to also lock into a certain loop? So that it won't get changed to a direction loop if you move the character.
I've wanted to actually stop movement affecting the sprite at all while the view is locked, but this would have caused too many backwards compatibility problems. This may be a good opportunity to re-visit this, however.
QuoteUnrelated to this, I believe GetTextWidth() should have a maximum width parameter. Why? Suppose I have a string that has no line breaks. If its GTW is larger than the screen's width, or it's put on a GUI label or something, it will get wrapped. But you can't tell in advance where exactly it will be wrapped.
I can appreciate that, but let's try to concentrate on one thing at a time ;)
About the whole room changing matter... I'd just like to say that I, myself, have never used NewRoom. I ALWAYS use NewRoomEx, and wouldn't like to see that ability go, myself.
Quote from: Pumaman on Tue 16/11/2004 19:20:28
QuoteI think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof.
Yeah, I thought the same thing. However, otherwise it becomes the only function that still takes a CHARID as a parameter, which I'm sure would confuse people who would try and use "character[EGO]" as the parameter, and so on.
Good point. But, it would fit in better with StartCutscene etc. At least you should rename the function, as the character itself doesn't skip. Maybe something like WalkAndFastForwardGame.
Quote
I agree -- and in fact, one thing I have added since the beta is support for Properties. These are basically functions disguised as normal variables, which will mean that instead of doing
SetCharacterTransparency(EGO, 10);
you can do:
character[EGO].Transparency = 10;
What about char[ego].transparency ++ ?
Quote
As for the MoveToXXX functions, I'm not sure whether to remove them completely ... all the co-ordinates can be obtained and then used with Walk anyway.
I don't think these really get used -- probably because of the somewhat arbitrary location that the character is moved to relative to the object. But do correct me if they're useful.
I never use MoveToChar, since it causes the two chars to overlap (for conversation, for instance, you'd want the two chars to end up face to face near each other, but not overlapped). I do occasionally use MoveToObject, specifically if the object is an inventory item that can be picked up. I wouldn't really miss it if it were removed though.
Quote
QuoteIs it an idea to use 'default' parameters with functions
That's something I'd like to add, yes. So that Walk, for example, would be non-direct and blocking by default, but you could specify the extra parameters if you wanted to.
Ah, but then you could to char[ego].say ("Hello", BLOCKING); :)
One more thing, all the functions for characters refer to 'moving', but the variable that can be checked if the character is still moving, is called 'walking'.
By the way you mentioned #IFDEFs as a feature... are these compile-time or run-time? Specifically, an #IFDEF LINUX would be useful at runtime to filter out some things that aren't possible in Linux, e.g. non-existent plugins.
Am I correct to assume that, other than char[].* functions, there will be Object[2].Transparency = 5, and stuff like that?
QuoteBut, it would fit in better with StartCutscene etc. At least you should rename the function, as the character itself doesn't skip. Maybe something like WalkAndFastForwardGame.
Alright, I think I'll just leave it as is for now, it won't become a member function of Character. We can consider what to do with it later.
QuoteWhat about char[ego].transparency ++ ?
Funny you should ask; the ++ and -- operators are the only ones that will not work with Properties (because of the way they optimise memory reads and writes). But everything else will work as usual, eg:
Character[EGO].Transparency += 1;
or
Character[EGO].Transparency = Character[EGO].Transparency + 1;
would accomplish the same thing.
QuoteI wouldn't really miss it if it were removed though.
What about everyone else -- who would miss the MoveToHotspot/MoveToObject functions if they were removed?
QuoteAh, but then you could to char[ego].say ("Hello", BLOCKING);
Aye, but then the problem is it would lose its %d/%s support. So the question is, would you rather have a Say command with an optional Blocking parameter, or two different Say and SayBackground commands, but both supporting %d and %s?
QuoteOne more thing, all the functions for characters refer to 'moving', but the variable that can be checked if the character is still moving, is called 'walking'.
As you can see, I am renaming the MoveCharacter functions to Walk. This is also to make way for a new Character.Move command which will do the same as Walk, but not play the walking animation.
QuoteBy the way you mentioned #IFDEFs as a feature... are these compile-time or run-time? Specifically, an #IFDEF LINUX would be useful at runtime to filter out some things that aren't possible in Linux, e.g. non-existent plugins.
They are compile-time. It's not really possible to have run-time #ifdef's, because the code has already been compiled and you can't suddenly remove half of it.
QuoteAm I correct to assume that, other than char[].* functions, there will be Object[2].Transparency = 5, and stuff like that?
In the long term, yes. I'm starting with characters because it's the biggest job and should give the system a proper testing before moving on to the other stuff. The way I look at it, if it all works with characters, it should have no problem with the rest.
Thanks for the info!
Quote
QuoteAh, but then you could to char[ego].say ("Hello", BLOCKING);
Aye, but then the problem is it would lose its %d/%s support. So the question is, would you rather have a Say command with an optional Blocking parameter, or two different Say and SayBackground commands, but both supporting %d and %s?
Good point. I do suppose the %d/%s support is very useful with Say.
That just leaves a possibility of mering SayAt with SayBG, into one SayWithExtraParameters (note that in the old system, you can't do a SayAtBackground anyway)
Quote
As you can see, I am renaming the MoveCharacter functions to Walk. This is also to make way for a new Character.Move command which will do the same as Walk, but not play the walking animation.
That sounds a bit confusing... Move is kind of a synonym of Walk. Maybe you could name it something like WalkNoAnim or something.
Quote
QuoteBy the way you mentioned #IFDEFs as a feature... are these compile-time or run-time? Specifically, an #IFDEF LINUX would be useful at runtime to filter out some things that aren't possible in Linux, e.g. non-existent plugins.
They are compile-time. It's not really possible to have run-time #ifdef's, because the code has already been compiled and you can't suddenly remove half of it.
True. But I did notice that some errors in a room script don't trigger unless the player character enters said room. Anyway the reason I'm asking, is that I would like to have some way of running a game that has plugins, in Linux where those plugins don't exist. And since you're working on #directives anyway, would something like this be possible? It would already work if it was just restricted to a single function (e.g. SystemCall, that consists of a windows part and a linux part, and only the part appropriate to your machine gets parsed).
I didn't want to mention this earlier, because I thought it was my machine, but it seems it may have happened to others...
There seems to be trouble importing templates into the editor.
Here's the current topic that is hinting at it: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=17747.from1100645999#new
I wanted to test something real quick with the latest release, and dropped in Proskrito's MI2 template into the beta folder. Then when I tried to create a new game, the template did not show up. I closed ags and opened it again, and no luck. I added the default template and the blank template, and those showed up. Then I closed ags again, and dropped in all templates I had, 4 proskrito and the 2 normal ags ones. only 2 of proskritos showed up and the 2 default ones showed. I assumed my computer was slow or was low on memory, but gave up.
Quote from: Scummbuddy on Wed 17/11/2004 16:34:32
I didn't want to mention this earlier, because I thought it was my machine, but it seems it may have happened to others...
There seems to be trouble importing templates into the editor.
Here's the current topic that is hinting at it: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=17747.from1100645999#new
I wanted to test something real quick with the latest release, and dropped in Proskrito's MI2 template into the beta folder. Then when I tried to create a new game, the template did not show up. I closed ags and opened it again, and no luck. I added the default template and the blank template, and those showed up. Then I closed ags again, and dropped in all templates I had, 4 proskrito and the 2 normal ags ones. only 2 of proskritos showed up and the 2 default ones showed. I assumed my computer was slow or was low on memory, but gave up.
i thought that was only me too :P
Ok, I've been looking into the templates problem.
There is indeed a bug, which has in fact been there ever since templates were added, but has only surfaced recently due to other changes.
Basically, when you create the template, if you give it a filename longer than 15 characters, it will not always load back into the editor properly.
The workaround for now is simply to make sure that when you create a template, you give it a name of 15 characters or less.
Unfortunately, for templates that are already out there, the user cannot simply rename the file -- this will not work. Therefore, any template authors who this affects, please re-make your templates with a shorter name.
And before anyone asks, the 15 characters excludes the ".agt" extension.
My apologies for the inconvenience.
Ok, beta 2 is now available.
This adds the complete set of Character functions and properties. Don't bank on the names all being permanent, because if anyone suggests and useful changes before the next beta I'll probably make them.
As for the Say/SayAt/SayBackground, I've left them as 3 different functions because I couldn't think of a neat way to combine them. If anyone has any bright ideas, do shout.
The new Properties look like normal attributes, but start with a capital letter. For example:
character[EGO].Clickable
is a property, whereas
character[EGO].room
is still the old variable.
One difference you'll notice with properties is that they use the correct view number, NOT the view number minus 1.
For the Animate and Walk functions, the Direct, Direction and Blocking parameters are no longer 1 and 0, there are constants instead:
ANYWHERE / WALKABLE_AREAS for Direct
FORWARDS / BACKWARDS for Direction
BLOCKING / IN_BACKGROUND for Blocking
Finally, I should probably mention default values. For Animate, the defaults are FORWARDS and BLOCKING; for Walk, they are WALKABLE_AREAS and BLOCKING. For WalkStraight, it is IN_BACKGROUND.
Again, these are open to change if appropriate.
Anyway, have a play and let me know your opinions. Remember, there's still time to change things, but this might be your last chance!
Okay. To avoid confusing people, maybe you could add a Property 'Room' as well? Because having everything capitalized is kind of neat.
And am I correct to assume that ANYWHERE and the other stuff are actually #defined to boolean values? Because personally, I prefer using 1 and 0 (or TRUE and FALSE) to lengthy text strings.
This may be radical, but how about EGO->Clickable as a shorthand for character[EGO].Clickable?
The only useful thing I could think of for the Say trilogy is SayEx, which might combine SayAt and SayBackground. Not sure if that's useful though. The alternative is naming SayBackground 'Whisper' and SayAt 'Ventriloquate' :)
WoooooHoooo!
Thanks CJ!
I'd prefer Walk not being blocking by default, but I guess I can get used to set the value if others find it better the other way...
The reason here is that my current interface does not include any MoveCharacterBlocking commands, nor do the interactions apart from room changes and such where it's neccesary to avoid the player from getting thrown back into the previous room or something.
Quote from: Pumaman on Sat 13/11/2004 21:02:00
Where's all this going?
My long-term goal for the scripting language is to bring it up to an object-based standard, on a par with Visual Basic 6 ...
ARRG. NO!
To quote grumpy smurf; I hate object orientated programming.
(I'm gonna do some SQL now)
QuoteOkay. To avoid confusing people, maybe you could add a Property 'Room' as well? Because having everything capitalized is kind of neat.
Yeah, it'd be nice to clear all that up. I'll see what I can do.
Quote
And am I correct to assume that ANYWHERE and the other stuff are actually #defined to boolean values? Because personally, I prefer using 1 and 0 (or TRUE and FALSE) to lengthy text strings.
No, they are #defined to various different numerical values. This is because people tend to get the parameters mixed up where there is more than one TRUE/FALSE parameter. Therefore, by having a completely different definition, it should eliminate any confusion since the engine can give a useful error message.
It also makes the script more readable:
character[EGO].Animate(3, 5, 1, 1, 0);
vs
character[EGO].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);
However, I know what you mean about being able to use 0 and 1 ... anyone else got any thoughts on it? I might make allowing 0/1 an optional feature.
Quote
This may be radical, but how about EGO->Clickable as a shorthand for character[EGO].Clickable?
That is something I'd like to do, but implementing pointers into the script language introduces various complexities, not least of which would be how to handle them in saved games. I'm still considering how to do this and whether it's worth the hassle.
Quote
The only useful thing I could think of for the Say trilogy is SayEx, which might combine SayAt and SayBackground. Not sure if that's useful though. The alternative is naming SayBackground 'Whisper' and SayAt 'Ventriloquate'
SayEx seems a very messy thing to do, since the functions arne't really related. Ideally the normal Say would have a Blocking parameter, but that would lose its %d/%s support so I'm not sure what the best plan is.
QuoteI'd prefer Walk not being blocking by default, but I guess I can get used to set the value if others find it better the other way...
Good point -- how often is Walk used in a blocking way, and how often non-blocking? Whichever is the most regularly used way should become the default.
QuoteARRG. NO!
To quote grumpy smurf; I hate object orientated programming.
Oh, but this is hardly object-oriented. I'm not making you write all your functions inside a class, and inherit things and so on.
That can come later :=
The only think I can think of what should be in the next update is they should creat a button called "Import a Jpg sprite pictures" and it should also be a "Import jpg Background" button in the room section. And "view screenplay room" button should also be there so I don't have to click "Test the game" everytime I want to check if the screenroom I was working on is ok.
And it would be better if all of the MS paintbrush option are there too. It is so painful to draw with that thin pencil when I am drawing for a walkable grounds lines as you know so if would be better if I can make choose how thick the line should be.
I know there is a button where I can see the preview how the backgrounds looks but I want to see how the action in the same room I am working looks like in that room with all the objects and gameplayers. That would be great.
a) this is an odd beta thread, but suggestions dont typically go in beta threads.
b) since you are making a game, you should still be in debug mode. just use the code to go directly to the room you want, or you could change your characters start room number to be the room number you want to try. just make sure their start coor's are correct.
c) we've discussed adding some more tools to the walkable areas and such. he claims that we can just as easily import walkable areas after drawing them in our paint program. so he cant justify making the tools that are already available to you.
d) I believe we dont allow jpeg because its a lossy format, plus you shouldnt worry about filesize since ags uses its own compression format, so importing jpeg wont matter.
Ok and thank you for the reply.
Using default parameters would be a great improvement because:
-The syntax is easy (for defining and using them)
-The number of instructions is reuced (bye to all the __Ex functions) so the manual would be more searchable.
-The code is more readable (you only specify the things you want to make "in a different" way)
I must have ESP or something. I remember CJ mentioning something about this a long time ago and was thinking about asking about it the other day. Good thing I read this thread first. Anyway here are some of my comments about the above discussion.
Set vs Change
Regarding the question about using "Change" instead of "Set" in function names, probably "Set" should be used when there is a corresponding "Get" function. If there isn't a corrsponding "Get" then using "Change" instead of "Set" is probably satisfactory. I prefer "Set" because it's easier to spell. (hehe)
Function Overloading
This is one of my favorite things. It makes things easier to code and easier to read. It would also resolve most of the AgsFunction vs AgsFunctionEx issues and reduce the function clutter . Should character[].ChangeRoom() include coordinates or not? Function overloading gives both; Include coordinates and a NewRoomEx() is performed, leave them out and NewRoom() is performed.
So I hope function overloading makes the final cut.
#define Constants
I understand the need for readability but I also understand the desire for brevity. So perhaps comprimise could be reached by using abreviated terms as follows:
ANYAREA / WLKAREA instead of ANYWHERE / WALKABLE_AREAS
FWD/BCK instead of FORWARDS / BACKWARDS
BLK/NOBLK instead of BLOCKING / IN_BACKGROUND
A proliferation of english words as #define system terms is problematic. For example suppose BLOCKING and RUNNING are defined to have a value of 1. Since both terms have the same value it would not be possible to use them in the user's script to enumerate the state of a character, object or other entity. If these terms were given unique values then they could be used for other things but then it wouldn't be possible to substitute 0 or 1 in AGS function calls.
Again using abbreviations/mnemonics instead of actual words, as much as possible, seems, to me, to be an acceptable way to resolve this situation. Another possibility is to use enumerated data types instead of #define constants.
I appolgize about being a bit off topic but one last thing about #define, I use it quite often and the current editor highlighting, with the grey backgound, drives me crazy. Is there something that can be done in the way of an option or something. Please ...
Character Names
Wouldn't it be a lot easier to read if we could write:
Roger.Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);
instead of
character[Roger].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);
So I guess AGS could define "Roger" as "character[1] instead of defining "Roger" as "1". This can be a "can of worms" because there are plenty of things that want to see the character ID of "Roger" (i.e. "1"). If we were to go down this road likely the charcter array would give way to character objects with "Roger" being the object name in this case. I guess this ends up being almost the same as the EGO=> question above. What do you thingk CJ?
Broader OO Issues
The scope of the discussion so far is limited to the script language (appropiate since that's the subject of the beta) and using characters as objects. As mentioned earlier in the discussion, it is intended that the other game entities have a similar fate.
It seems to me that a character object (or any other game entity), in addition to it's properties and inherited methods as discussed above, would also be comprised of it's interaction methods, sprites, animation views, loops, etc. Is there a plan to reorganize AGS's internal structure, at some point, to more closely correspond to this kind of paridigm?
The reason I ask is that something like this would make it possible/easy to import/export complete game entities; or maybe even game entities would just be stored in seperate files. IMHO, the weakest part of AGS is the dificulty multiple developers have in simultaneously working on the same project. This is primarily due to so many things being inseparably stored in the main game file. OO's inherient modularity offer hope in this regard.
I wanted to bring this up now to avoid locking-in on somthing that would preclude these kinds of future capabilities. I am curious as to your thinking on this CJ.
P.S. CJ, I appologize for spamming your beta thread; feel free to take me to the woodshed. Nice work with the OO script.
Quote from: Pumaman on Thu 18/11/2004 19:15:19
Quote
And am I correct to assume that ANYWHERE and the other stuff are actually #defined to boolean values? Because personally, I prefer using 1 and 0 (or TRUE and FALSE) to lengthy text strings.
No, they are #defined to various different numerical values. This is because people tend to get the parameters mixed up where there is more than one TRUE/FALSE parameter. It also makes the script more readable:
character[EGO].Animate(3, 5, 1, 1, 0);
vs
character[EGO].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);
I can understand that people would find the lower of the two more legible - however it does require that the coder looks up the exact syntax of the possible parameter values every time (especially since most functions use different parameters). So I would really appreciate a 0/1 feature. Maybe using something equivalent to an 'enum' would be the answer? C++ would give a warning like 'conversion from int to enum'.
Unrelated bug report... if you do a DisableCursorMode on the current cursor mode from within the dialog_request function, the cursor mode does indeed change - but the cursor's shape does not.
Ok, I got a gripe.
I want to write "int number". Right? So I write "i", then "n", then "t".
When I press "space", however, it autocompletes to InterfaceOff. I have to delete it, type "int", hit the LEFT arrow key, and THEN the right arrow key and space.
Very inconvenient.
QuoteSet vs Change
Now that properties have replaced most of the Sets, this is less of an issue. There is however a bit of an inconsistency remaining:
ChangeRoom
ChangeView
SetIdleView
SetSpeed
I prefer Set, but then I don't want to rename ChangeView to SetView because people will confuse it with SetCharacterView which is actually now LockView. If you see what I mean :)
So this is a bit messy, but the best plan is probably just to leave it as is.
QuoteFunction Overloading
This is one of my favorite things. It makes things easier to code and easier to read. It would also resolve most of the AgsFunction vs AgsFunctionEx issues and reduce the function clutter .
At this stage, I'm not implementing function overloading. However, the support for default parameters means that your examples are now neatly handled that way instead. ChangeRoom simply has an optional X and Y parameter, which you can supply but you don't have to. Almost as good as function overloading ;)
QuoteI understand the need for readability but I also understand the desire for brevity. So perhaps comprimise could be reached by using abreviated terms as follows:
Yeah, I like the idea of abbreviating them. Ideally I'd like to add proper Enum support, but realistically I don't think I'll have the time to do so.
So in the meantime, I propose some slightly longer abbreviations:
ALLAREAS / WALKAREAS
FORWARDS / BACKWARDS
BLOCK / NOBLOCK
LOOP / NOLOOP (a new one for Animate's third parameter)
The problem is as you say that it takes a while of getting used to, and having to keep looking up what the names are. Autocomplete of #defines would help here, and I'll try and get that added.
An advantage of adding proper enum support would be that autocomplete could become smart enough to offer the valid options for an enum parmaeter, but as I say I don't think it'll make it.
QuoteI appolgize about being a bit off topic but one last thing about #define, I use it quite often and the current editor highlighting, with the grey backgound, drives me crazy. Is there something that can be done in the way of an option or something. Please ...
The grey background was deliberate, mainly because of the #sectionstart / #sectionend lines, to make them obviously different to the rest of the code.
What would your preference for preprocessor directive colouring be?
Quotewe were to go down this road likely the charcter array would give way to character objects with "Roger" being the object name in this case. I guess this ends up being almost the same as the EGO=> question above.
Yeah, this is the same as the question above. I'd like to add it, but it raises various issues with save games once pointers enter the equation.
It could be done with a load of #defines, but I'd really rather not do that -- for starters, autocomplete would no longer work and it's prone to mistakes when the macro gets used elsewhere by accident.
QuoteIt seems to me that a character object (or any other game entity), in addition to it's properties and inherited methods as discussed above, would also be comprised of it's interaction methods, sprites, animation views, loops, etc. Is there a plan to reorganize AGS's internal structure, at some point, to more closely correspond to this kind of paridigm?
Well, the reason it's split up as it is at the moment is so that sprites, views, etc can be shared between different characters and different objects, which adds a degree of flexibility and stops you having to load duplicate copies of graphics.
I do understand the difficulty of team working on a project, and I'm hoping to add some sort of rudimentary diff/merge support at some stage. It is currently possible to work as a team, so long as people work on individual room files and only one person modifies the main game file.
QuoteUnrelated bug report... if you do a DisableCursorMode on the current cursor mode from within the dialog_request function, the cursor mode does indeed change - but the cursor's shape does not.
I'll take a look at some point.
QuoteOk, I got a gripe.
I want to write "int number". Right? So I write "i", then "n", then "t".
Hehe yes, I've noticed this too. It's because I added the space bar as an autocomplete confirm key, and it is quite annoying.
So what I've done for the next version is simply remove InterfaceOff/On from the autocomplete. You shouldn't be using them anyway, because they were replaced by GUIOff/GUIOn a long time ago.
QuoteLOOP / NOLOOP
Why not name them REPEAT / NOREPEAT (or ONCE) to avoid confusion with view loops?
QuoteHehe yes, I've noticed this too. It's because I added the space bar as an autocomplete confirm key, and it is quite annoying.
So what I've done for the next version is simply remove InterfaceOff/On from the autocomplete. You shouldn't be using them anyway, because they were replaced by GUIOff/GUIOn a long time ago.
Er, not a good idea, I'm afraid. First, there still remains the issue of trying to define a string (and I get autocompleted to StringToInt), and defining a char, which I use a lot (and get ACMPLTD to character).
Second... space bar an autocomplete key? How come? After the function people either use ( or [, and rarely some other symbols, but never space bar.
EDIT - Actually, there are MORE keys that make autocomplete VERY annoying. It's VERY annoying to type in, say, "if (interface == SKIP" and then type ")", triggering autocomplete and putting in "if (interface == SkipUntilCharacterStops)". Autocomplete isn't very tolerant of these things. Maybe it would be better if autocomplete didn't get triggered by quite so many keys. Me, I find it very, VERY annoying and even frustrating in parts.
I added the extra keys because Visual Studio allows them and I tend to rely on them when coding.
However, there is the difference that Visual Studio doesn't autmoatically pop up the autocomplete list, it only does it if you press Ctrl+Space.
So which is the preferable option? Stick with the autocomplete window popping up automatically, but disable space bar and ) from being fillup keys; or allow these keys but make the window require manual popping-up?
My vote goes for the former, naturally.
Oh, BTW - you said you were interested in this - I suffer from very, very slight slowdown with the "new" autocomplete. It's there, but not very noticeable. I have a Celeron.... something or other, and 128Mbs of ram. And apart from that, I can't tell you any more specs of mine.
Okay, I had the same problem as redruM, but with MANY other things, variables like 'objectA' etc. Is there a way to make an option for spacebar to be autocomplete? If there was, I would turn it off, myself. I'm used to enter working well enough. Or at least an abort key that would add a space without the autocomplete kicking in.
I second redruM's motion.
Also I believe I have pointed this out before, but the automatic alignment of closing braces doesn't work the way it should, and this is rather annoying if you're trying to add code below a line that has a closing brace.
Ok, beta 3 is up.
I've removed space and ) from the autocomplete, cos yeah it was annoying.
Most importantly, the manual is now updated. Because it was a huge job (probably took longer than actually coding the changes ;) ) there are bound to be mistakes, so please point out any errors, broken links, etc in the new Characters section.
QuoteOh, BTW - you said you were interested in this - I suffer from very, very slight slowdown with the "new" autocomplete.
Is the slowdown there all the time, or only when the autocomplete list is visible?
QuoteAlso I believe I have pointed this out before, but the automatic alignment of closing braces doesn't work the way it should, and this is rather annoying if you're trying to add code below a line that has a closing brace.
Hmm, does anyone actually find the de-denting behaviour useful? If not, I might just remove it completely.
I like it, I'm not sure what Radiant is mentioning, I've never had a problem with that part. The one thing I wish worked right is that the editor allows indenting selected 'blocks' of code, but it only works in a standard 'tab' size, about 7 spaces.
That's my only other gripe. I'm thoroughly happy with the progress you're making. Someday this engine might make a VERY useful resume piece.
"Name: Chris Jones
Reason we should hire you: I programmed the well-known Adventure Game Studio, all by my self. :) "
Kidding...
QuoteIs the slowdown there all the time, or only when the autocomplete list is visible?
Only when the list is visible. By slowdown, I mean it takes slightly longer than it did to find a probable command (like, I can write GetObjectP and it takes a bit longer than it used to to get to GetObjectPosition). But it doesn't bother me at all.
QuoteHmm, does anyone actually find the de-denting behaviour useful? If not, I might just remove it completely.
It allows for neater layout... me, I think it's all the same. I don't find it to be a very big difference.
EDIT - One little question that's been bothering me... I know that one of the things AGS is known for is it's "compatibility" in a way (ie, recently-made-useless commands take a looong time to quit the scene so people don't have to re-script the whole thing, like InterfaceOff or the PlayerStandsOnHotspot interaction). But I'll ask anyway. How much longer AFTER 2.63 is out can the old commands be expected to work, do you think? Meaning, should we start changing our scripts already or will we live with the two styles for some time (like the Euro)?
EDIT 2 - The small slowdown isn't there anymore with the new beta. Maybe it isn't related, but the result's the same.
QuoteI think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof.
I agree with Radiant.
Now, for testing purposes, I've converted my CCS script to v2.63 Beta 3.
I really like the object-based approach and the new names. It's easy to code and makes the script more readable.
Only two minor things I've noticed:
- Autocomplete doesn't properly display struct members if they are indented with tabs within the declaration.
- The context-sensitive help for the old SetActiveInventory doesn't point to the new ActiveInventory property.
Some thoughts:
I think the ALLAREAS define for the Walk command is slightly confusing. I like Rick's ANYWHERE better.
And shouldn't StopMoving be called StopWalking? Or do you intend to use it later for stopping animationless movement as well?
I propose to rename SetSpeed to SetWalkSpeed since we also have animation speed.
Will you eventually rename (capitalize) all character variables like .walking and move them into the appropriate section in the help file? I was just wondering why you only chose .Room for this beta.
I think it's good we're discussing function names and the like. Since so much is changing anyhow, now's our chance to make it right from the get-go.
I also had an idea, but I don't know how feasable it is:
Would it be possible to have members default to the struct the current function is called by, so you could do
character[EGO].FaceLocation(.x - 10, .y);
for example?
Just a thought as it would help shorten some lines.
I like the closing brace handling as it is in the newest version. Don't change it, is my opinion.
Apparently I'm the only one who frequently adds new code below a line containing a closing brace } (because if you press enter from that line, that line gets de-dented regardless of where the { was). Could you please do an option to turn if off anyway?
We've been discussing overloading a bit... would this be workable...
character[EGO].Face (charid)
character[EGO].Face (x, y)
(you can tell from the # of parameters whether it's FaceChar or FaceLoc)
(also if you're doing lots of constants anyway, Face (LEFT) may be useful (although it's easy to code yourself, of course ))
I haven't programmed extensively since high school, and even that was a (non-visual) C++ compiler, so I'm a bit lost here. Anyway, BUG REPORT:
I am using RawDrawImage like a crayon for drawing. What its set up to do is every 10 game cycles, it RawDrawImage([crayon object X], [crayon object Y], GetObjectGraphic[crayon object]) (pseudocode)
Now this object is animating, so the frame changes. It looks like the engine has got the right image, just not the right colors. I'll post a demo if you like.
Quote from: Radiant on Thu 25/11/2004 10:55:17
Apparently I'm the only one who frequently adds new code below a line containing a closing brace } (because if you press enter from that line, that line gets de-dented regardless of where the { was).
I got used to the 2 char diffrences right from the start.. that's why it doesn't bother me..
QuoteI know that one of the things AGS is known for is it's "compatibility" in a way (ie, recently-made-useless commands take a looong time to quit the scene so people don't have to re-script the whole thing, like InterfaceOff or the PlayerStandsOnHotspot interaction). But I'll ask anyway. How much longer AFTER 2.63 is out can the old commands be expected to work, do you think?
I have no plans to remove support for the old commands. Before doing so, I'd want to make sure that a tool was available to automatically upgrade old-style scripts. People have invested a lot of time in writing their game scripts, and I don't want to suddenly go and render them all useless.
Quote- Autocomplete doesn't properly display struct members if they are indented with tabs within the declaration.
- The context-sensitive help for the old SetActiveInventory doesn't point to the new ActiveInventory property.
Well spotted, I'll get those fixed.
QuoteI think the ALLAREAS define for the Walk command is slightly confusing. I like Rick's ANYWHERE better.
Yeah, I'm not sure about this one either. My personal preference would be for eWalkAnywhere and eWalkAreasOnly, if enum support gets added.
QuoteAnd shouldn't StopMoving be called StopWalking? Or do you intend to use it later for stopping animationless movement as well?
Aye, I left it as StopMoving because it will cover both walking and any future Move command as well.
QuoteI propose to rename SetSpeed to SetWalkSpeed since we also have animation speed.
Good idea.
QuoteWill you eventually rename (capitalize) all character variables like .walking and move them into the appropriate section in the help file? I was just wondering why you only chose .Room for this beta.
I'm not sure about this one. The reason I did .Room and .PreviousRoom was because I made them read-only, but I didn't want to break old scripts by making the normal variable read-only; therefore the new readonly properties were added.
I'm not sure what to do with the rest -- comments welcome.
QuoteI think it's good we're discussing function names and the like. Since so much is changing anyhow, now's our chance to make it right from the get-go.
Indeed -- this is a rare chance to actually change things, because once people have started scripting with the names then they become much harder to change.
QuoteI also had an idea, but I don't know how feasable it is:
Would it be possible to have members default to the struct the current function is called by, so you could do
character[EGO].FaceLocation(.x - 10, .y);
for example?
Like the VB With block thing? Sounds kinda handy; but if pointers are added it would only be Ego.FaceLocation(Ego.x, Ego.y) which wouldn't be such a handful anyway. I'll leave it on the backburner for now.
QuoteApparently I'm the only one who frequently adds new code below a line containing a closing brace } (because if you press enter from that line, that line gets de-dented regardless of where the { was). Could you please do an option to turn if off anyway?
Remind me once all the actual scripting engine changes are done. I'll probably re-visit the script editor and add a Preferences dialog for options such as tab size, auto-indent, etc at that time.
QuoteWe've been discussing overloading a bit... would this be workable...
character[EGO].Face (charid)
character[EGO].Face (x, y)
That would be possible, but I'm a bit nervous because it's rather prone to error. I'm not sure if the benefits outweigh the confusion factor in this case.
QuoteI am using RawDrawImage like a crayon for drawing. What its set up to do is every 10 game cycles, it RawDrawImage([crayon object X], [crayon object Y], GetObjectGraphic[crayon object]) (pseudocode)
Are the room background and the crayon image the same colour depth?
Right, beta 4 is now up.
This updates the object functions to the new way. There's a new global array "object" that works just like "character". So you can do stuff like:
object[2].Move(100, 50, 5);
and so on.
Also added is Enum support along with autocomplete for it -- so the horrid BLOCK/NOBLOCK defines are now gone completely, and have been replaced with nicer eBlock-type enums.
Because autocomplete now shows you the possible values, you don't have to remember anything so is there any point allowing it to accept 0/1 as well?
Finally, type checking has been significantly enhanced. You used to be able to do stuff like this:
int i;
i = character[EGO];
which was highly illegal and would cause strange results at run-time; it shouldn't now be possible to compile a script like that.
Anyway, as far as the object-based functions go, I'm not sure whether to change over anything else. The characters and objects were the main reason for doing this -- can anyone see a benefit in object-ising any other parts of the script functions?
One possibility I'd like to do would be the GUI objects, but realistically that would require pointer support, because asking people to do stuff like gui[3].listbox[4].Add() would be rather messy.
Anyway, comments on the naming and behaviour of the newly converted object functions would be welcome. I'm still open to changing things there.
On the character functions front, I'd like to freeze the new names now so that people can start to use them and test them out. So if anyone has any last-minute issues with the character function/property naming, now is the time to shout.
Is it now legal/possible to give a struct as an argument to a function? I seem to remember being told some time back that that was not allowed.
And what about passing arrays as arguments?
No, neither of those is possible. However, the difference is that in previous versions it would appear to work, but actually just corrupt bits of memory. Now, the compiler stops you from doing it.
Quote
* (...) When calling a function which takes an enum parameter, autocomplete has been enhanced to pop up with the valid options.
* Improved function calltips so that it highlights the current parameter.
This rocks!
But:
object[1].B // does suggest "Baseline"
object[1].Bs // closes pop-up
[BACKSPACE]
object[1].B // does NOT suggest "Baseline" anymore
Also, with object-based scripting enforced, how do I return a character's current view? character[CHARID].view is not allowed.
Edit:
Another suggestion: I've noticed you have an internal define NARRATOR -1 so you could update the manual to propose that for the game.narrator_speech game variable.
Does this mean, for instance, that object movement is analogous to character movement? Specifically, can objects use anti-glide mode? Ideally a character should be a superset of an object.
For consistency, it may be useful to create structs for rooms, regions, areas and hotspots - for all the functions GetHospot*, SetRoom* etc. Then again I don't see a very high need for this.
And thanks for all the good improvements!
Wowee! Am I a couple of versions behind. CJ thanks for kindly reading my previous lengthly post, I'll try to be a bitmore to the point this time round.
Quote
The grey background was deliberate, mainly because of the #sectionstart / #sectionend lines, to make them obviously different to the rest of the code.
What would your preference for preprocessor directive colouring be?
I would be happy with any color as long as there wasn't a backgound color.
Quote
Well, the reason it's split up as it is at the moment is so that sprites, views, etc can be shared between different characters and different objects, which adds a degree of flexibility and stops you having to load duplicate copies of graphics.
I do understand the difficulty of team working on a project, and I'm hoping to add some sort of rudimentary diff/merge support at some stage.
I understand the need to avoid unnessary copies of graphics, sounds, music, and other entities that consume relatively large amounts of disk space. I have some ideas how a degree of modularity can be achieved while maintaining the use of shared resources and would make a diff/merge or import/export functionality easier to implement. This is obviously not the time or place to have a discussion about this so I'll leave it for another day.
Quote
Anyway, as far as the object-based functions go, I'm not sure whether to change over anything else. The characters and objects were the main reason for doing this -- can anyone see a benefit in object-ising any other parts of the script functions?
One possibility I'd like to do would be the GUI objects, but realistically that would require pointer support, because asking people to do stuff like gui[3].listbox[4].Add() would be rather messy.
There are a bunch of Get/Set functions, and never-ending request to add more, for game and room that would perhaps be better/easier handled as object properties?
Do you mean for just for this release or forever? Eventually, I think you would want to objectise everything that lends itself to an OO paradigm.
As for the GUI stuff I agree that it would logically be the next biggest one to change over. It seems like you are still pondering the possibilty of adding support for pointers at some point. If so then add the GUI stuff next time around, otherwise just do it now, IMHO.
Quote
Also added is Enum support along with autocomplete for it ..
Yeah....
Great work CJ ...
Me, I'd say leave the rest as it is... with characters and objects it was fine, but the rest might turn out a bit too confusing/messy, methinks.
EDIT - Just read this:
QuoteBecause autocomplete now shows you the possible values, you don't have to remember anything so is there any point allowing it to accept 0/1 as well?
Yes, allow it to accept 0/1. I ALWAYS use numbers unless I can't help it.
EDIT 2 - Ok, here's an issue I found.
So I have 11 objects that animate at random times, like flashing stars, yes? Therefore, I used to have the following code:
if (IsTimerExpired(1)==1) {
SetTimer(1,Random(14)+1);
randomizer=Random(10)+1;
if (IsObjectAnimating(randomizer)==0) AnimateObject(randomizer,4,4,0);
}
(and yes, the timer WAS set previously). And this worked wonderfully. But with the NEW code, which is:
if (IsTimerExpired(1)==1) {
SetTimer(1,Random(14)+1);
randomizer=Random(10)+1;
if (object[randomizer].Animating==0) object[randomizer].Animate(4,4);
}
what happens is each object WAITS UNTIL ALL OBJECTS HAVE FINISHED THEIR ANIMATIONS before animating, giving an undesirable effect. Now, I have tried switching back and forth between these two snippets of code - the 1st ALWAYS works, the second NEVER does. What's happening?
BTW, I can upload the thing if necessary (accourse).
Quote from: Rui "Puss the Boots" Pires link=topic=17697.msg219014#msg219014quote]Because autocomplete now shows you the possible values, you don't have to remember anything so is there any point allowing it to accept 0/1 as well?
Yes, allow it to accept 0/1. I ALWAYS use numbers unless I can't help it.
Quote
I second that.
QuoteBut:
Ã, object[1].B // does suggest "Baseline"
Ã, object[1].Bs // closes pop-up
[BACKSPACE]
Ã, object[1].B // does NOT suggest "Baseline" anymore
This has always been the case -- if you start to type "baseline" again, autocomplete will reappear. Basically, backspace doesn't check for autocomplete; do you think it should?
Quote
Also, with object-based scripting enforced, how do I return a character's current view? character[CHARID].view is not allowed.
Hmm oops, good point, I'll add a property. If there's anything else like this that's accidentally dropped off, do let me know.
Quote
Another suggestion: I've noticed you have an internal define NARRATOR -1 so you could update the manual to propose that for the game.narrator_speech game variable.
Well spotted, I'll update that.
QuoteDoes this mean, for instance, that object movement is analogous to character movement? Specifically, can objects use anti-glide mode? Ideally a character should be a superset of an object.
No, objects can't use anti-glide mode. Since animation and movement are two completely seperate things for objects, this seemed the best way to have it.
QuoteFor consistency, it may be useful to create structs for rooms, regions, areas and hotspots - for all the functions GetHospot*, SetRoom* etc. Then again I don't see a very high need for this.
Yeah, I thought about that. I don't really think the benefits are great enough to merit obsoleting more functions though.
QuoteDo you mean for just for this release or forever? Eventually, I think you would want to objectise everything that lends itself to an OO paradigm.
Ideally I would like to completely OO-ise it, but practically speaking I don't think I will. Global functions like SetScreenTransition, while you could argue should be a static member function like Game.SetScreenTransition, doesn't really bring any benefit in doing it that way; whereas things like characters, objects, GUIs, etc really lend themselves intuitively to OO.
Quote
As for the GUI stuff I agree that it would logically be the next biggest one to change over. It seems like you are still pondering the possibilty of adding support for pointers at some point. If so then add the GUI stuff next time around, otherwise just do it now, IMHO.
Yeah, I am still pondering pointers... I definitely would like to add them once I've worked out how to take care of the technical issues.
QuoteYes, allow it to accept 0/1. I ALWAYS use numbers unless I can't help it.
Hehe. I guess my hatred for 0/1 stems from seeing things like this:
AnimateObjectEx(0,2,0,0,0,1);
I mean, seriously, what the hell does that do?
Anyway, I'll re-instate it for Blocking, WalkWhere and Repeat. However, for Direction I don't think having 0/1 is appropriate, because there's no obvious meaning to whether forwards is 1 or 0; so unless you have any strong objections I might leave it banned for that parameter.
Quotewhat happens is each object WAITS UNTIL ALL OBJECTS HAVE FINISHED THEIR ANIMATIONS before animating, giving an undesirable effect. Now, I have tried switching back and forth between these two snippets of code - the 1st ALWAYS works, the second NEVER does. What's happening?
Animate is blocking by default. You need to supply the optional blocking parameter and set it to eNoBlock.
QuoteHehe. I guess my hatred for 0/1 stems from seeing things like this:
AnimateObjectEx(0,2,0,0,0,1);
I mean, seriously, what the hell does that do?
Anyway, I'll re-instate it for Blocking, WalkWhere and Repeat. However, for Direction I don't think having 0/1 is appropriate, because there's no obvious meaning to whether forwards is 1 or 0; so unless you have any strong objections I might leave it banned for that parameter.
Fine by me.
QuoteAnimate is blocking by default.
Er, that so? I'm not sure that's a handy default... maybe it's just me, and maybe I've just gotten used to the old non-default-blocking AnimateObject... but I do think it shouldn't be blocking per default... especially since it's a bit of a (truly minor, however) bother to set the "No Repeat" parameter (already a default in it's own right) just to change the blocking parameter... but that tiny, tiny issue aside, I do believe that object animations should be kept non-blocking per default.
QuoteQuoteAnimate is blocking by default.
Er, that so? I'm not sure that's a handy default... maybe it's just me, and maybe I've just gotten used to the old non-default-blocking AnimateObject... but I do think it shouldn't be blocking per default...
That's fine, this sort of thing is precisely why we're having these betas. At the moment it is a bit inconsistent with Walk being non-blocking but Animate blocking by default.
What does everyone else think? Do you tend to use Animate more often in a blocking or non-blocking manner?
QuoteBasically, backspace doesn't check for autocomplete; do you think it should?
I think so, yes. I often start typing beyond the first letter, only to lose the pop-up when I mistype... :P
QuoteWhat does everyone else think? Do you tend to use Animate more often in a blocking or non-blocking manner?
Personally, I use most functions non-blocking but I think they should be consistently blocking by default to make them easier to use for newbies.
I agree with strazer. However, it seems to me that any default value should be zero, for clarity's sake - so the parameter may have to be called 'background' rather than 'blocking'.
I mean, Function (a,b) sounds similar to Function (a,b,0) right?
I don't care whether you allow 0/1 parameters in place of enums as long as it doesn't interfere with anything else. It doesn't affect me. But if we're talking about renaming parameters to accomodate it, I say get rid of it.
I don't want to have to care about whether TRUE is defined as 0 or !0, or which value of an enumeration comes first. The whole point of abstraction is to get away from that level of detail.
Any parameter of boolean or enumeration type should have the simplest, most intuitive name possible, and its default value should be whatever value corresponds to the desired default behavior, whatever that may be. All default boolean parameters must be FALSE? Please no.
While on that subject: now that we have enums, what about providing a bool enum with entries True and False? Actually, that's a bad idea. Forget about it. I was just looking for a cheap way to "typecheck" boolean arguments, but "bool.true" is inelegant, and people who prefer 0/1 should probably be allowed to go on doing that.
Quote from: Snarky on Tue 30/11/2004 01:22:51While on that subject: now that we have enums, what about providing a bool enum with entries True and False? Actually, that's a bad idea. Forget about it. I was just looking for a cheap way to "typecheck" boolean arguments, but "bool.true" is inelegant, and people who prefer 0/1 should probably be allowed to go on doing that.
Actually, this is already implemented.
You can use true/false for several things, including:
.Clickable
.DiagonalWalking
.IgnoreLighting
.IgnoreScaling
.IgnoreWalkbehinds
.ScaleMoveSpeed
.Solid
.TurnBeforeWalking
P.S.: I'm posting this from Linux, woo! Gonna test some AGS games later.
But true/false are just #defines for 1 and 0, right? There's no boolean data type.
I'd rather there be NO specific boolean type, I never have problem with non-zero being true and 0 being false, I just don't wanna script with a language too restricted by its format and rules.
No, they're enums.
Just open the roomedit.clb file in a text editor and scroll down to view all the goodness.
Ok... sorry for the Kudos... but Damn... I go to Iraq for awhile and Puma gets all OO on me... not that I mind... now if I switch from Java to AGS (which I do often, I get bored with one code snip, then switch to another)...
I have a tendoncy to not be able to pull my brain out of OO mode heh...
But good stuff Chris, I may wait to start back work on STR to use all the goodies in here (sure it means recoding... but hey... who has never done a little recoding in their lives)
MUAHAHHAAHHAH
Thanks again... you made my life livable again.... Not that it wasn't before.... I just wanted to give you a warm feeling inside.
Quote
Ideally I would like to completely OO-ise it, but practically speaking I don't think I will. Global functions like SetScreenTransition, while you could argue should be a static member function like Game.SetScreenTransition, doesn't really bring any benefit in doing it that way; whereas things like characters, objects, GUIs, etc really lend themselves intuitively to OO.
As people get acustomed to the OO way of doing things there are sure to be future requets for more. A Game object would make more sense if one could do something like Game.ScreenTransition = eDisolve or myvar = Game.ScreenTransition. It would be a clean way of handling the GetGameParameter() type of items that seem like are always requested and would eliminat need for many Set/Get functions. What do you think?
Quote
Yeah, I am still pondering pointers... I definitely would like to add them once I've worked out how to take care of the technical issues.
From some of your previos comments I am guessing that you probably will need to use pointers to entries in some sort of symbol table rather than memory pointers to the actual variable or object. When I worked at GE I helped develop a Relay Ladder Language, a script language of sorts as it was byte code interpreted. Pointers were handled in a manner that was simpler and somewhat more restrictive than in C/C++
- There was only one type of pointer, pointer to variable implemented as an offset into the symbol table.
- There wasn't a reference operator. A simple assignment statement such as pointer_var=myvar would assign the reference to the pointer variable.
- There wasn't a dereference operator. The language consisted of asm function library and a handful of boolean operators. Dereferencing and other pointer operations, were done within the library asm functions.
- The command line monitor program, when asked to display or modify a pointer variable, would automatically convert variable table offsets to symbol names so that the end user would work with symbol names. This seemed to make the concept of pointers easier to grasp and their use less error prone for factory electricians and other non-programmeres.
I don't meam to suggest that the above is an optimal, complete, or even an apporpiate solution for AGS. I thought that perhaps a different perspective would be of some help to you in your efforts with pointers.
I'm looking forward to updating BlueGui using the new methodology. Can't wait ...
Quote from: Radiant on Mon 29/11/2004 23:38:19
it seems to me that any default value should be zero, for clarity's sake - so the parameter may have to be called 'background' rather than 'blocking'.
Personally, I disagree with this ... I think the default value should simply be whatever people are most likely to use. The default value should cater for the majority of calls to the function.
Yes, there is a "bool" enum with "true" and "false" values. Currently they just map to 1 and 0, and I'm not planning on doing a Java-style strictness where you can't convert int to bool.
QuoteOk... sorry for the Kudos... but Damn... I go to Iraq for awhile and Puma gets all OO on me...
Hehe, hope you get to come home soon, you've been out there quite a while now ;)
QuoteAs people get acustomed to the OO way of doing things there are sure to be future requets for more. A Game object would make more sense if one could do something like Game.ScreenTransition = eDisolve or myvar = Game.ScreenTransition.
Oooh good point, why didn't I think of that? A better example then is probably a function like DeleteSaveSlot or GetTime, which doesn't really map to object-ness in any way, and I can't see a benefit from trying to do so.
QuoteFrom some of your previos comments I am guessing that you probably will need to use pointers to entries in some sort of symbol table rather than memory pointers to the actual variable or object.
Thanks for your ideas. Yeah, I think it'll have to be some form of quasi-pointer because of the need to save the game. If there was no need for save/restore, pointers would be an easy matter of just storing the memory address, but no such luck ;)
Java and .NET have good ideas on how to do pointers -- they're actually stored as memory handles which get resolved to the actual memory address at runtime, and that sort of approach can probably work with AGS.
Anyway, I'll have a tinker at the weekend.
Quote
Java and .NET have good ideas on how to do pointers -- they're actually stored as memory handles which get resolved to the actual memory address at runtime, and that sort of approach can probably work with AGS.
Just a bit more thingking about pointers. You already have characters and objects in a table format. Why couldn't you implement pointers using somthing like the following construct?
struct POINTER {
int type; /// OBJECT, CHARACTER, GUI, USER, ....
int id;
}
The "type" component would identify which table to look into and the "id" component would be the offset. So you have a situation like so:
POINTER ptr;
ptr = object[7];
would result in:
ptr.type == eOBJECT
pty.id == 7
AGS would, of course, need to use this info to get at the actual mem pointers... hmmm, or would it? I mean internally wouldn't it just be a couple of extra steps to decopose such a pointer into object[7] and then just continue as is done currently.
This may also may be a sensible way to deal with pointers in the script. Everyone is fairly familiar with the concept of things having id numbers. So for them a pointer would just be the id number bundled with the type of thing it is.
I'll be interested in seeing what you come up with this weekend. Cheers!
CJ,
Tried converting some of my current stuff and got the following error message when trying to test the game.
An exception 0xC0000005 ...
ACWIN.EXE at EIP = 0xBFF8C158 ...
program ptr is -189
ACI Version 2.63.786
I have a safe copy so I'm not in a bind or anything. Thought you might want to know about this. If you want a copy of the source that produced the error just let me know.
[edit]
String Types with in Oobjects
I may have found another problem accessing strings within an object. I believe the statement StrCopy(this.filename, filename); causes the exception. I don't know if you intended strings to be supported by the new object stuff or not, but I don't think it works at this point. There is an example below.
Script Header
#define CFG_SIZE 500
struct IniFile {
int fp; // file handle
char modified; // TRUE if changed, FALSE otherwise
string filename;
char db[CFG_SIZE];
import function Open(string filename);
import function ReadInt(string section, string option);
import function ReadStr(string section, string option,string value);
import function WriteInt(string section, string option,int value);
import function WriteStr(string section, string option,string value);
import function Close();
};
Global Script
function IniFile::Open(string filename) {
// Read in an INI type config file
// Open the file
this.fp = FileOpen(filename, FILE_READ);
StrCopy(this.filename, filename); // Execution of this line seems
// to cause a fata error
// :
// :
}
Room Script
function room_b () { // any click on hotspot
IniFile Cfg;
Cfg.Open();
}
Oobjects in Room Scripts
I tried this and then read the docs at the beginning of the thread. I was hoping to be able to do this at some point in the future. This would allow all of the loop/view/id stuff to be embedded in an Oobject so that, for example, to implement a specific door in a specific room one could simply have something like door.open() or door.close. In another room there could also be door.open, door.close but would work in different manner (i.e. different views, ids, etc, or functionality).
Is this something that is planned or should I just put it out of my mind ? :)
Hmm that's strange -- if it's reproducible then yes, could you please send me a copy of the gmae that causes the problem.
Ok here is a link to the converted game that causes a problem.
http://www.gaia-spa.com/project/ags/Test.ZIP
Please re-read my previous post as I added two more questions while you were responding to it. Thanks
*** Edit
One more OO question please. Have you considered about allowing OOobjects to have both private and public functions? If so perhaps just replace the "import" directive with "private" or something.
I keep meaning to say this, but I keep forgetting. About auto-complete again. You say, CJ, that we no longer have to remember every single thing, due to the way it works now. That is true, and most welcome it is too, but let's take AnimeObject. Let's say I type "AnimeObject(" and then PASTE the coordinates I've previously gotten from the room. Auto-complete no longer will show, and will not give us those so nice extra "eBlock" and "eRepeat". Can this be changed?
Rick: I tried your test game but I didn't get a crash. All I got was it ran through the first room and then got an Array Index Out of Bounds error on global script line 1075.
At what point does it crash for you?
QuoteI may have found another problem accessing strings within an object. I believe the statement StrCopy(this.filename, filename); causes the exception.
Yes, strings within structs are not supported. This is the main reason why structs are an undocumented feature. I'll update the compiler to give an error message if you do this, to clarify matters.
The workaround is to do:
char filename[200];
QuoteOobjects in Room Scripts
I tried this and then read the docs at the beginning of the thread. I was hoping to be able to do this at some point in the future. This would allow all of the loop/view/id stuff to be embedded in an Oobject so that, for example, to implement a specific door in a specific room one could simply have something like door.open() or door.close.
I'm not entirely sure what you're getting at here. If you're referring to inheritance so that you could add methods to an object then I can't make any promises about that I'm afraid.
QuoteOne more OO question please. Have you considered about allowing OOobjects to have both private and public functions? If so perhaps just replace the "import" directive with "private" or something.
That's a possibility for future -- for now I just want to get the basics all working in OO-fashion for 2.7.
QuoteI keep meaning to say this, but I keep forgetting. About auto-complete again. You say, CJ, that we no longer have to remember every single thing, due to the way it works now. That is true, and most welcome it is too, but let's take AnimeObject. Let's say I type "AnimeObject(" and then PASTE the coordinates I've previously gotten from the room. Auto-complete no longer will show, and will not give us those so nice extra "eBlock" and "eRepeat". Can this be changed?
Assuming you mean MoveObject (since Animate doesn't use coordinates), then if you were to paste in the X/Y co-ordinates, then when you press the comma key autocomplete should automatically re-appear as usual. The ( and , keys should trigger autocomplete.
Quote
I tried your test game but I didn't get a crash. All I got was it ran through the first room and then got an Array Index Out of Bounds error on global script line 1075.
At what point does it crash for you?
It crashes right at startup. I may even happen before the video mode is switched etc. I happens both when I do a Test or when I execute the exe directly. I didn't have any problems with V2.62.
I guess I'll go check line 1075 and see what's going on there and let you know if I can get it to work. Maybe I'll just start doing surgery until the problem goes away. If you can't repoduce the problem then there probably isn't much you can do on your end. If you have any other ideas or things you would like me to try just let me know.
Quote
Yes, strings within structs are not supported. This is the main reason why structs are an undocumented feature. I'll update the compiler to give an error message if you do this, to clarify matters. The workaround is to do:
char filename[200];
I didn't know if you had intentions to support them as part of the OO stuff or not. I don't mind the workaround much because it is less wasteful of memory. Conversions between string and char[] is a bit inconvient at the moment though. Maybe some day I'll ask you to add a couple of functions; one to copy a string to a char buffer and another to do the reverse.
Quote
I'm not entirely sure what you're getting at here. If you're referring to inheritance so that you could add methods to an object then I can't make any promises about that I'm afraid.
I wasn't thinking of inheritance at all but rather scope. I would like to define OObjects that have scope only within a specific room. Specifically I would like to declare the struct and methods/functions within a Room Script so that they would only have scope within the room. So that in the room script I could do someting like this.
function room_b() {
FrontDoor.Open();
BackDoor.Close();
}
All of the object, view, loop, and sound id numbers could be embedded in the OObject definition, making the game/interaction logic cleaner and easier to read. Anyway that's what I was askin about.
Quote
That's a possibility for future -- for now I just want to get the basics all working in OO-fashion for 2.7.
I understand. I have been playing with that read/write INI file thing using the OOisms. In several instances I found opportunities to excise code and put it into utility functions. I haven't done so, so as to keep everything as part of the object. Private functions would have ben ideal for this.
The other thing I wish were available is a way to initialize an object in some way. I don't mean this in the sense of constructor/destructor functions. A flag would be enough so that when the object is created (i.e. MyObjDef MyObj;) the flag would be set to a known value (i.e. 0 would work just fine) and not just a random value. The methods then could be able to know if this is the first time they are running. I know, :) the workaround is to simply call the init method before doing anything else.
Anyway these are just a couple of things that occured to me while I have been trying out the "make your own object" stuff. I really like it and I am looking forward to upgrading the BlueGui and AnimationEngine.
*** Edit
I think I saw something above about the editor and the auto indent feature. I am finding that pressing ENTER after a closing brace "}" causes it to unindent to the next outer level of indentation.....
Never mind :-[ operator error. It's because I was manually backing up the brace to align with the "if" on the previous line and then of course pressing enter after that casues it to backup again. Now that I know how to use it ::) it works just fine for me.
QuoteIt crashes right at startup. I may even happen before the video mode is switched etc. I happens both when I do a Test or when I execute the exe directly. I didn't have any problems with V2.62.
Hmm yeah, EIP -189 is the free disk space check, which is done before any of the game scripts are loaded. I don't know why on earth that should suddenly start crashing.
The only thing I can think of is that the call to GetDiskFreeSpaceEx is for some reason crashing the game, but it's been there for ages and I've never seen a problem with it before. Bit of a mystery, I have to say.
QuoteI didn't know if you had intentions to support them as part of the OO stuff or not. I don't mind the workaround much because it is less wasteful of memory. Conversions between string and char[] is a bit inconvient at the moment though. Maybe some day I'll ask you to add a couple of functions; one to copy a string to a char buffer and another to do the reverse.
It's not something I'm planning on implementing particularly soon, but it'd be handy to have one day. As for converting between them, StrCopy accepts a char array for either parameter, so it shouldn't be a big deal.
QuoteI wasn't thinking of inheritance at all but rather scope. I would like to define OObjects that have scope only within a specific room. Specifically I would like to declare the struct and methods/functions within a Room Script so that they would only have scope within the room.
You can place the struct definition in the room script rather than the script header, and that should then make it local to the room.
QuoteThe other thing I wish were available is a way to initialize an object in some way.
Global variables are always initialized to 0; but local variables don't have any way of knowing at present.
QuoteAnyway these are just a couple of things that occured to me while I have been trying out the "make your own object" stuff. I really like it and I am looking forward to upgrading the BlueGui and AnimationEngine.
Thanks for your comments :)
Quote from: Pumaman on Sat 04/12/2004 12:26:36
Hmm yeah, EIP -189 is the free disk space check, which is done before any of the game scripts are loaded. I don't know why on earth that should suddenly start crashing.
Er, maybe his disk is full? Windows does tend to behave very strangely when confronted with limited resources.
QuoteGlobal variables are always initialized to 0; but local variables don't have any way of knowing at present.
I believe it would be nice for local variables to also get initialized to zero (since the alternative is making them 'undefined'...)
Quote
EIP -189 is the free disk space check, which is done before any of the game scripts are loaded .... Bit of a mystery, I have to say.
I only have 2GB free disk space :( but since AGS doesn't mind when starting games then I suppose this is enough. Right, so I'm back to dismantling the offending program to see if I can find the problem by the process of elimination.
Quote
StrCopy accepts a char array for either parameter...
:o No s#@%t! Well that's all I need!
***** EDIT ******
I got a type mismatch error when a character array is specified as the destination in the statement "StrCopy(this.name, name)" .
Actually, if this were to work, then all I need would be a StrnCopy() function added some day.
****************
Quote
You can place the struct definition in the room script rather than the script header, and that should then make it local to the room.
I get a compile error "Error (line 7): Variable 'TestObj::Init' is already imported " when I do this ....
// room script file
struct TestObj {
int var;
import function Init();
};
function TestObj::Init() {
this.var = 0;
}
TestObj MyObj;
#sectionstart room_a // DO NOT EDIT OR REMOVE THIS LINE
function room_a() {
// script for room: Player enters screen (after fadein)
MyObj.Init();
SetCursorMode(6);
}
#sectionend room_a // DO NOT EDIT OR REMOVE THIS LINE
Quote
I believe it would be nice for local variables to also get initialized to zero (since the alternative is making them 'undefined'...)
Radiant, I don't usually depend on variables being initialized to anything and normally prefer initializing them in the declaration (i.e. int var=0). My point was that there doesn't appear to be a way of doing this with variables that are contained within a user defined OObject.
Quote from: Radiant on Sat 04/12/2004 13:05:18
I believe it would be nice for local variables to also get initialized to zero (since the alternative is making them 'undefined'...)
Actually, I've just checked the code and it looks like they do -- well, basic types, anyway. Structs don't, which is a bit inconsistent I guess.
QuoteI only have 2GB free disk space but since AGS doesn't mind when starting games then I suppose this is enough. Right, so I'm back to dismantling the offending program to see if I can find the problem by the process of elimination.
Is it just this particular game that causes the problem?
QuoteI got a type mismatch error when a character array is specified as the destination in the statement "StrCopy(this.name, name)"
I just gave it a quick test with this:
StrCopy(character[EGO].name, "Roger");
and it compiled fine. How's your struct declared?
QuoteI get a compile error "Error (line 7): Variable 'TestObj::Init' is already imported " when I do this ....
Ah yeah, that will happen in a room script, sorry I forgot about that.
Can AGS add the support for multibyte in the TTF Font?
thx....
Alice: I know you're keen to have this, and the last time you asked (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=13762.0) I did say it'd be in 2.62, but other priorities have taken over for now, it's still on my to-do list.
Anyway, beta 5 is now up! This adds pointer support. What does that mean? Well, it means that for one the "player" variable is now always kept up to date with the player character so it's actually useful! Also, there are new named character objects for each character -- the naming is like this:
cEgo
ie. "c" for character, followed by the script name in sentence case. So:
cEgo.Walk(10, 40);
is identical to:
character[EGO].Walk(10, 40);
For the next version I'm aiming to add something similar for objects and for GUI items.
The new File I/O functions now demonstrate another use for the pointers support -- it's now much more intuitive than having to pass the handle around everywhere.
Can you do your own pointers? Well, yes and no.
You can create a pointer to any of the AGS types (characters, objects, files), but not to your own structs. You can also only have local variables as pointers -- globals are not supported. This is because supporting global pointers throws up save game issues and makes it possible for your script to have memory leaks; I'll think a bit further about whether to implement this.
Anyway, have a play and most importantly, let me know if anything doesn't work properly. Play about with pointers -- for example, you can have a custom function take a character rather than a CHARID as its parameter:
function FaceLeft(GameCharacter *theChar) {
theChar.FaceLocation(-100, theChar.y);
}
Finally, I've decided to start adding icons to the editor menus. Donations welcome!!! Menu item icons must be 16x17 pixels (and make sure to leave a 1-pixel border within that, or it'll look strange).
Sweet! AGS is becoming quite the powerful programming language...
What icons are you looking to add? Posting from a work computer, I can't really go and install AGS here.
Well basically, I'm happy to add icons to any of the main menu options if people come up with suitable ones.
Quote from: Snarky on Mon 06/12/2004 22:18:40
Sweet! AGS is becoming quite the powerful programming language...
That make me think if embedding javascript* would bring more or less problems than extending the AGS script with objects and pointers.
I'm not saying that's a better option nor trying anyone how things should be made. I just have curiousity if there are technical, license, or personal reasons that makes the adoption of a general script language a worse option.
*I've put the example of javascript because it's very similar to the idea of OO that has been explained in this thread and has similar syntax to AGS script (as far as I know because I'm not a javascript expert).
Generally, using an existing script engine isn't a good idea. Early versions of AGS did so, but in the end I had to write my own.
Some reasons are:
* most script languages are interpreted rather than compiled, which makes them slow
* most languages do not provide a means to save the script state to disk (for a Save Game feature)
* most script languages are not cross-platform
* most script languages are either not powerful enough, or are too confusing, to use as a game script language
* most don't integrate with the game engine in the way that AGS works best
Therefore, using an existing scripting engine is not really viable. However, AGS does attempt to emulate the syntax of C (and therefore also Java, C#, etc) as closely as possible so that people already familiar with these languages can pick it up easily.
Ok, thanks for your explanation. And thanks for the great effort to move AGS towards OO in order to make our scripting easier.
Two small bugs entirely unrelated to the entire scripting system,
when you do 'show usage' on a sprite, it says 'gui button 54' rather than, say, 'button 3 on gui 18'.
when you do 'export GUIs', I get an error that 'sectionstart interface_click' is not found - even if it actually does exist in my global script.
Quotewhen you do 'show usage' on a sprite, it says 'gui button 54' rather than, say, 'button 3 on gui 18'.
That's not a bug, it's a showcase of my extreme laziness at the time I implemented it ;)
Quotewhen you do 'export GUIs', I get an error that 'sectionstart interface_click' is not found - even if it actually does exist in my global script.
I'll take a look.
Also, some very low-numbered sprites are sometimes labeled as used on a certain GUI, when in fact they aren't. This is most obvious for sprite #0... but it seems that sometimes a font number is mistaken for a sprite number, or something. This isn't important, of course.
Something else that is a bit more important - when importing all frames of an animated GIF, sometimes two colors turn transparent (the first is the color of the upper left pixel, which is pure pink, the second is a black color). The effect, needless to say, messes up the transparency. For reference, try multi-frame-importing this image, courtesy of InCreator.
(http://www.terran-x.com/increator/smith.gif)
StrSetCharAt()
If the char position is larger than the length of the string a runtime error is generated. Have you considered just appending the char to the end of the string in this case instead of generating a runtime error?
Compiler and Objects
The compiler doesn't seem to check that the object and function definitions match. I don't know if you are aware of this or not so I thought I would mention it.
// Script Header
struct IniFile {
:
import function GetInt(string section, string option, int value);
:
};
// Global Script
function IniFile::GetInt(string section, string option) {
:
:
}
*** Edit ***
Corrected format above
Quote from: RickJ on Thu 09/12/2004 00:26:32
StrSetCharAt()
If the char position is larger than the length of the string a runtime error is generated. Have you considered just appending the char to the end of the string in this case instead of generating a runtime error?
I think the better way is the scripter himself to be more aware of it and use StrLen() to check for it if required. If he really needs to append something just use StrCat().
If it's set to append the character, in my opinion it's even harder to spot bugs as it won't generate an error and it may be doing something you don't want to (well maybe it can generate an error to warning.log though), the problem is, when you, say, set a character to the 10th position of a string which is only 5 characters long, what should the behaviour be? Add that character to the 6th position? Or add it to the 10th position and pad the inbetween characters with some other things?
StrSetCharAt()Quote
I think the better way is the scripter himself to be more aware of it and use StrLen() to check for it if required. ... If it's set to append the character, in my opinion it's even harder to spot bugs as it won't generate an error and it may be doing something you don't want to (well maybe it can generate an error to warning.log though)
I pretty much agree with this until the game is released and distributed. After that point I think it would be better to not have a runtime error that crashes the game in response to this situation, IMHO.
Quote
... the problem is, when you, say, set a character to the 10th position of a string which is only 5 characters long, what should the behaviour be? ...
As you suggest there is not really a correct behaviour but just appending to the very end and making an entry in the warning.log file, as you suggest would probably better than completely bailing out of the game.
Quote
If he really needs to append something just use StrCat().
Except that strings can't be defined as a member of a struct and char[] is the workaround and StrSet/GetCharAt() is the conversion mechanism.
Compiler error message generated without line numberWhen I incorrectly wrote this (in the proper context in the global script of course):
len = seclen + 3 + this.length;instead of this:
len = seclen + 3 + this.length();the compiler correctly complained about a missing '(' but didn't give a line number.
QuoteAlso, some very low-numbered sprites are sometimes labeled as used on a certain GUI, when in fact they aren't.
Can you provide an example? What does it say that the sprite is, the GUI background image?
QuoteSomething else that is a bit more important - when importing all frames of an animated GIF, sometimes two colors turn transparent
Well spotted yes, if one of the colours in the image has the same RGB as the transparent colour then it will also be made transparent. I'll get it fixed. A workaround for now would be to change the colour of the background.
QuoteIf the char position is larger than the length of the string a runtime error is generated. Have you considered just appending the char to the end of the string in this case instead of generating a runtime error?
I'm not sure that this is a good idea, it would seem better to inform the user of their mistake.
QuoteThe compiler doesn't seem to check that the object and function definitions match. I don't know if you are aware of this or not so I thought I would mention it.
Hmm good point, I'll look into it.
QuoteExcept that strings can't be defined as a member of a struct and char[] is the workaround and StrSet/GetCharAt() is the conversion mechanism.
StrSet/GetCharAt are not intended as a conversion mechanism in any way. You can use StrCopy to copy a string to/from a char[]
Quotethe compiler correctly complained about a missing '(' but didn't give a line number.
Well spotted, I'll get that fixed.
StrCopy() nd ObjectsQuote
You can use StrCopy to copy a string to/from a char[]
StrCopy generates runtime errors when trying to pass a char[] as a parameter
when the char[] is defined within an object. A similar and possibly related
situation occurs when attempting to pass char[n] as a parameter to StrCopy(). I mentioned this problem earlier but mis-communicated by referring to character arrays when I meant to say char[], sory for the confusion.
Exporting/Importing ObjectsCJ, did you intend that it be possible to create an instance of an object in the global script and then be able to access it from a room script?
I unsuccessfully tried to do this. I defined the struct in the script header and placed the functions in the global script file as you instructed. I created an instance of the object in the global script file. I was able to access and test everything by placng my object.function() calls in the GUI interface_click() interaction. Next I tried to export the instance of the object and got a compiler error.
Global Script:
IniFile Config;
export Config;
Script Header:
import Config;
File I/OWorks great!!
IniFile ModuleCJ, here is a link to the user module I created. It implements the ability to
work with INI configuration files. I used this try out the OO stuff and thought you may want to have a look. There is also a comment file I made while working on the module containing some of my thoughts you may find amusing.
Everyone else is welcome to take a look as well. I plan on making a general release after an official AGS OO release is announced. I am happy to take C&C but I think we should start another thread for that. Well anyway it's an example of how to make your own oobjects.
http://www.gaia-spa.com/project/ags/modules/IniFile001.zip
object vs objectHow can we avoid confusion between object-oriented obnjects and room objects when discussing things in the forums or writing about them in docs or tutorials? Should we consider some kind of convention like oobject for OO objects and just object for room objects? Just curious!
*** Edit ***
$$I incorrectly typed $$ instead of &&. The compiler error correctly identified the line number but the error message, "How did we get here?", was amusing. Just out of curiosoity does $$ have a meaning relative to this message or is that message just a polite way of saying "You're a bloom'in idiot!!" because that's how it made me feel :-[
It does not. I got that error after royally screwing up some parenthesis. ;D
CJ -> for instance,
Quote
Sprite 2 is used in the following places. It may also be used in text script commands and in rooms (for example, room object graphics); we cannot detect those uses automatically.
View 6, loop 0, frame 0
View 6, loop 0, frame 5
View 10, loop 0, frame 3
View 10, loop 1, frame 4
View 25, loop 1, frame 0
View 25, loop 1, frame 7
Mouse cursor 7 (Wait)
GUI button 15
GUI button 67
GUI button 68
GUI button 69
GUI button 70
GUI button 71
GUI button 72
GUI button 73
GUI button 74
Sprite #2 is an empty sprite (1x1 pixel) and I'm certain I'm not using it on any GUI buttons.
(also, btw, an image that is used as an edge image for a textbox GUI, is falsely named a button image by the usage list)
QuoteStrCopy generates runtime errors when trying to pass a char[] as a parameter
when the char[] is defined within an object.
I tried this:
struct TestStr {
char thestring[200];
};
function test_str() {
TestStr tstr;
StrCopy(tstr.thestring, "Jibble!");
}
and it worked fine. How do you get a compile error?
QuoteScript Header:
import Config;
It needs to be:
import IniFile Config;
import lines need to include the variable type.
QuoteIniFile Module
Looks good, that's some handy work with the OO functionality :)
QuoteExample: #define NONE -1
enum {NONE, eSOME, eMUCHO};
Because #define is a preprocessor thing that replaces all instances of "NONE" with "-1", the error message here was correct. This is one of the problems with using #defines, which is why hopefully enum support can go some way to removing the need for them.
QuoteUsing Display() to display the value of an enum using %d seems to work fine; the numeric value is displayed. Using %s causes a fatal error. It would be pretty slick to use %s to display the value in text form, especially while in debug mode.
That would be handy; but because the enum is compiled into numeric values, it's not possible for the runtime to know the enum names. Of course, there's the wider issue of having the ability to include debug information in the script to assist things like this, but that's not something I'm looking into at the moment.
QuoteStrCopy(name[7], filename); // Doesn't work
That won't work because a string can't be copied into a single character.
QuoteStrCopy(this.filename, filename); // Doesn't work
This could well be because of the use of "filename" as the variable name in the struct and for the parameter -- try changing the name of the funciton's parameter and see if that fixes it. If so, I'll have to add some sort of compiler check for this.
QuoteIs there any kind of "break" instruction, to break out of a loop, other than using the while's conditional expression? It would be convienient to have on ocassion.
Not currently, no ... the only thing you could do would be a "return" but that breaks out of the whole function.
QuoteHow can we avoid confusion between object-oriented obnjects and room objects when discussing things in the forums or writing about them in docs or tutorials?
Good question, there is ample room for confusion there. We'll have to think about that.
Quote$$
I incorrectly typed $$ instead of &&. The compiler error correctly identified the line number but the error message, "How did we get here?", was amusing.
Strange, what did your script look like? I just tried this:
if (i $$ 2) { }
but it just gave a standard Parse Error.
QuoteCJ -> for instance,
GUI button 68
GUI button 69
Hmm ok, well the best thing here would be for me to fix it to display the GUI/button number rather than "gui buttn 68" then we'd have a clearer idea where the problem was.
Quote
Strange, what did your script look like? I just tried this:
if (i $$ 2) { }
When I did the following I got the unny error message.
while ((i<INIBUFSIZE)$$(status==ININONE)) {
}
Quote
Good question, there is ample room for confusion there. We'll have to think about that.
;) Probably before you spring this on everyone ,,,
Quote
This could well be because of the use of "filename" as the variable name in the struct and for the parameter -- try changing the name of the funciton's parameter and see if that fixes it. If so, I'll have to add some sort of compiler check for this.
No I still get the type mis-match error. Here is a code snippet. I am also going to zip up a copy of the game where this and the above $$ error occur.
//===================================================================
function IniFile::setfilename(string xname) {
//
// Copy the filename from the parameter to the object. The status of
// the operation is returned as follows:
//
// INIOK - successfully completed operation
// INIERR - N/A
//===================================================================
int i, len;
string filename;
len = StrLen(filename);
while ((i < len)&&(i < ININAMSIZE)) {
this.filename[i] = StrGetCharAt(filename,i);
i++;
}
this.filename[i] = 0;
i=0;
StrCopy(this.filename, xname);
}
Here is a game that contains the above two problems. Just uncomment lines 97 and line 249.
http://www.gaia-spa.com/project/ags/modules/IniFileGame.zip
Quote
Re: break - Not currently, no ...
That's what I thought but after seeing my little IniFile module you probably know why I mentioned it.
Quote
re: StrCopy(name[7], filename); // Doesn't work
That won't work because ...
I understand. I was trying to see if I could use StrCopy() to grab part of the buffer. Damm I'm lazy ;)
Quote
That would be handy; but because the enum is compiled into numeric values, it's not possible for the runtime to know the enum names. Of course, there's the wider issue of having the ability to include debug information in the script to assist things like this, but that's not something I'm looking into at the moment.
If you ever decide to add debug info into the exe then perhaps this would deserve consideration then. I can see why it's not much of a priority at the moment.
Quote
Because #define is a preprocessor thing ...
Understand. Perhaps my confusion is worth remembering whenever you get round to explaining enums in the manual.
Quote
Looks good, that's some handy work with the OO functionality
Thanks for the kind comments. Since the topic came of recently I thought that it would make for a good test of the OO stuff. Do you think that you might devise an easy way of including or using such things, maybe something like the plugin-manager or just a simple directive in the header like use IniFile? Maybe it will be part of the borader scoped import/export mechanism you mentioned. Anyway just some thoughts here....
Quote
It needs to be:
import IniFile Config;
OOooooooooo! :o That makes my day!!!
Great work CJ, the OO stuff was easy and fun to work with.
QuoteWhen I did the following I got the unny error message.
Thanks -- now that I know what causes it, I'll reword the error message to actually make sense ;)
QuoteNo I still get the type mis-match error. Here is a code snippet. I am also going to zip up a copy of the game where this and the above $$ error occur.
Thanks for spotting this, it is a bug in the compiler and I'll get it fixed. I've also double-checked the variable naming thing and it should be fine to call the paramter "string filename", so feel free to change xname back to filename.
QuoteUnderstand. Perhaps my confusion is worth remembering whenever you get round to explaining enums in the manual.
Well that's just it, it's not specific to enums. Using defines can cause this sort of strange error message to occur anywhere, wherever you use a define in the wrong way you'll get an error message that's not entirely obvious because of the macro expansion. Ideally I'd like to add const ints and scrap defines altogether because of this sort of problem.
QuoteThanks for the kind comments. Since the topic came of recently I thought that it would make for a good test of the OO stuff. Do you think that you might devise an easy way of including or using such things, maybe something like the plugin-manager or just a simple directive in the header like use IniFile?
Please understand that my first priority is to get all the built-in AGS functions working in an OO-fashion (specifically, all the GUI stuff). Once that's done I'll concentrate further on the user scripting side of things.
Quote
Well that's just it, it's not specific to enums. ...
Hehehe ... I'm too embarrassed to tell the silly things I have done to myself... but #define is too useful to abandon.
Quote
Please understand that my first priority is to get all the built-in AGS functions working in an OO-fashion (specifically, all the GUI stuff). Once that's done I'll concentrate further on the user scripting side of things.
I understand completely :). I think you do a really good job of listenig to ideas and setting priorities accordingly. The cool thing about the AGS community is that you take inspiration from our ideas and then implement cool stuff 8). That in turn inspires us to have more ideas which in turn inspires you to implement more cool stuff. It's a real pleasure for me to participate in the process. Thanks CJ.
Ok, beta 6 is now up.
Room objects now have script names, so that you can do:
oDoor.Animate( ... );
and so on, which is much more user friendly than the previous number-based approach. It also means that if you delete an object (and thus they get re-numbered), your script is unaffected.
The main thrust of this release is the new GUI stuff.
All GUI controls now have a "Script name" property, which allows you to give them a VB-style "lstSaveGames" or "btnCancel" type name.
Then, in the script you can do stuff like:
lstSaveGames.AddItem("Jibble");
rather than
ListBoxAdd(3, 6, "Jibble");
all much nicer the new way.
Also, GUI controls like the button and slider now have an event property at the bottom of the list, which allows you to assign a special event function to process clicks on that control. Again, this is like the way VB does it, so rather than forcing everything through interface_click you can have a seperate function to handle each different control. For buttons, you can also find out whether the left or right mouse button was clicked.
If you assign an event function then it will be called instead of interface_click; if you don't then interface_click will be called as usual.
Have a play and let me know of any issues.
Chris, this new version is beautiful, just beautiful, but... yeah, there's a but...
You added the ability to change the listboxes' highlight color! That's great!
...but I wanted to set it to transparent. Which I can't. 0 should make it transparent, it makes everything ELSE transparent, but HERE just makes 'em black...
There's always one, isn't there ::)
Fine, you can have your transparent selection background but you'll have to wait for beta 7 :P
Aw, sorry 'bout being so picky! I've been having a looksie at the whole new GUI system. I love it! You're doing an awsome job! ;D
Hehe actually I did think about making 0 transparent when I added it, but then I thought "that would be stupid, then you wouldn't be able to tell which item was selected".
It was only when you mentioned it that I took a second look and remembered there's the selected text colour property too ... so the rolleyes are all mine I think ::)
Quote
Added simple inheritance support ("extends" keyword).
Can you give a sample usage of reference a descritption in manual. Thanks.
Quote
All GUI controls now have a "Script name" property, which allows you to give them a VB-style "lstSaveGames" or "btnCancel" type name.
Then, in the script you can do stuff like:
lstSaveGames.AddItem("Jibble");
rather than
ListBoxAdd(3, 6, "Jibble");
all much nicer the new way.
Wouldn't it be something like gMyGui.lstSaveGames.AddItem("Jibble"). If not then how is the particular GUI id resolved? Also, there is no "Script O-name" display for Gui components in the editor pane. Is the "lst", "btn", ect prefixes enforced by the editor (as is with gName, oName and cName) or is this just by convention for Gui components?
Quote
Room objects now have script names, so that you can do:
oDoor.Animate( ... );
and so on, which is much more user friendly than the previous number-based approach.
Cool! Cool! Cool!
Would it be practical, at some point, to allow mixed case for the object names so that instead of oFrontdoor.Animate(...) one could have oFrontDoor.Animate(...).
Character ObjectsDon't yet have a Script O-name display in the editor pane as do Object Objects and Gui Objects.
All I can say is really cool stuff here CJ 8)
---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x0044867E ; program pointer is +211, ACI version 2.70.800, gtags (7,2)
AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and notify CJ on the Tech forum.
Most versions of Windows allow you to press Ctrl+C now to copy this entire message to the clipboard for easy reporting.
---------------------------
OK
---------------------------
I seem to get this error whenever I use RestartGame(). This is the message I get when calling it from the GUIs, I get a similar message when calling it from a hotstpot.
QuoteCan you give a sample usage of reference a descritption in manual. Thanks.
struct Base {
int a;
}
struct Derived extends Base {
int b;
}
then you can do:
Derived der;
der.a = 4;
der.b = 5;
The reason I say it's simple inheritance support is that you can't downcast a pointer, ie. you can't do this:
Derived *derived;
Base *base = derived;
so the inheritance is of limited use... I basically added what was necessary for the GUI Control stuff.
QuoteWouldn't it be something like gMyGui.lstSaveGames.AddItem("Jibble").
Well, I thought about that... it would be the "proper" OO way to do it, but fully pathing the control names all the time would be a pain, so in the end I decided just to make the control names have global scope. The only drawback is that you can't have two controls on different GUIs with the same name; but then, allowing that would only lead to confusion anyway.
QuoteIf not then how is the particular GUI id resolved?
The GUI ID is not needed in the script any more -- AGS knows which GUI the control is on, so you can just use the control's name.
QuoteAlso, there is no "Script O-name" display for Gui components in the editor pane. Is the "lst", "btn", ect prefixes enforced by the editor (as is with gName, oName and cName) or is this just by convention for Gui components?
The prefix is not enforced. Whatever you type in as the script name for the gui control, is the name by which it is accessible in the script.
QuoteWould it be practical, at some point, to allow mixed case for the object names so that instead of oFrontdoor.Animate(...) one could have oFrontDoor.Animate(...).
Well, it's a matter of practicality. At the moment, for backwards compatibility, the o-name is just the script name automatically sentence-cased. However, in a future version there could be an option to get rid of the old-style script names, and then you could give an exact o-name however you wanted.
QuoteI seem to get this error whenever I use RestartGame(). This is the message I get when calling it from the GUIs, I get a similar message when calling it from a hotstpot.
Um, oops. Yeah, er, beta 6 will crash if you restore or restart the game ... well spotted, sorry about that. I'll get it fixed.
Quote
struct Derived extends Base {
int b;
}
Does this also work for internal AGS objects (i.e Characters, Objects, GUI, etd) or just ones created in the script?
Well, you could declare a struct inherited from a Character, but because the characters aren't actually declared as your inherited type you wouldn't be able to use it.
Quote
Quote
I tried your test game but I didn't get a crash. All I got was it ran through the first room and then got an Array Index Out of Bounds error on global script line 1075.
At what point does it crash for you?
It crashes right at startup. I may even happen before the video mode is switched etc. I happens both when I do a Test or when I execute the exe directly. I didn't have any problems with V2.62.
I guess I'll go check line 1075 and see what's going on there and let you know if I can get it to work. Maybe I'll just start doing surgery until the problem goes away. If you can't repoduce the problem then there probably isn't much you can do on your end. If you have any other ideas or things you would like me to try just let me know.
If you remember the problem I had converting an existing game a couple of betas back... The problem is that I was using "object" as a parameter name in a number of functions I created. It seemed an appropiate name to use, at the time, for passing a room object's id number. It's not surprising that object-o-izing (hehe, sorry couldn't resist the 'o' thingy) process laid claim to "object" as a reserved word but the resulting error message is a bit confusing in that the line number given doesn't seem to exist or be related. I suppose "object" contains a pointer or something that go used in trying to acces the object[] array.
I guess this is more of a gotcha than a bug for people upgrading existing projects.
P.S. I accidently disobeyed you and upgarded everything on that project and now have no way back to my V2.62 version. Everything seems to now work ok under the new beta. Will I be forgiven and my project see a bright future or shall I be cursed and my project suffer a thousand calamities? ???
QuoteIf you remember the problem I had converting an existing game a couple of betas back... The problem is that I was using "object" as a parameter name in a number of functions I created.
Hmm, that should generate a compile error... I'll look into it.
QuoteP.S. I accidently disobeyed you and upgarded everything on that project and now have no way back to my V2.62 version. Everything seems to now work ok under the new beta. Will I be forgiven and my project see a bright future or shall I be cursed and my project suffer a thousand calamities?
Oh dear... I can see the cloud of wasps approaching already :-\
Oh my god!!Ã, :o
Methods, properties, enums, optional arguments, pointers with neatly improved autocomplete list and calltip features! Hurray OO! Hurray CJ! :)
Unbelievably useful things we have here! High thanks, Chris, for improving the scripting language!
Pity I couldn't be online for the past month and thus missed such interesting changes being made. I'm still fiddling with the new features and, if I may, I'd like to ask a couple of questions:
1. Sorry if it was already discussed but is it possible to declare user properties? I've tried some things but was unable to declare those get_* / set_* functions for my property to work.
2. Is it a bad idea to have user-defined managed :) structs (and thereby pointers to them) in scripts? Will it lead to some weird results with save/load?
Oh and btw, is it safe to name vars/functions as something like NAME_name (or whatever it may be) if there is a NAME::name identifier there? I mean are there any internal names declared (like in C with its names with leading underscore character) or should we not bother?
Quote from: RickJ on Tue 14/12/2004 01:26:17
If you remember the problem I had converting an existing game a couple of betas back... The problem is that I was using "object" as a parameter name in a number of functions I created. It seemed an appropiate name to use, at the time, for passing a room object's id number. It's not surprising that object-o-izing (hehe, sorry couldn't resist the 'o' thingy) process laid claim to "object" as a reserved word but the resulting error message is a bit confusing in that the line number given doesn't seem to exist or be related. I suppose "object" contains a pointer or something that go used in trying to acces the object[] array.
Hmm, I tried doing this:
function myfunc(int object) {
}
but I correctly got a compile error saying the "object" was already defined. Can you elaborate on what sort of code you had that lead it to crash?
QuoteUnbelievably useful things we have here! High thanks, Chris, for improving the scripting language!
No problem! It was about time ;)
Quote1. Sorry if it was already discussed but is it possible to declare user properties? I've tried some things but was unable to declare those get_* / set_* functions for my property to work.
User properties in the script are not currently supported. Plugins can however export them (I'll update the plugin documentation at a later date).
Quote2. Is it a bad idea to have user-defined managedÃ, structs (and thereby pointers to them) in scripts? Will it lead to some weird results with save/load?
That's a possibility for future. It would need some sort of "new" keyword and associated script bytecode, but I may well add it at some point. To be honest, it's not a priority for 2.7.
QuoteOh and btw, is it safe to name vars/functions as something like NAME_name (or whatever it may be) if there is a NAME::name identifier there? I mean are there any internal names declared (like in C with its names with leading underscore character) or should we not bother?
Member vars/funcs are named internally "struct::member", and since that's not a legal name for a global variable I think you'll be alright ;)
Thanks for clarifying :)
Having plugin to export properties would be a really nice feature.
Quote from: Pumaman on Tue 14/12/2004 20:38:16Member vars/funcs are named internally "struct::member", and since that's not a legal name for a global variable I think you'll be alright ;)
Hehe, the reason I asked is because in earlier versions it wasn't possible to declare a var like this:
struct NAME {
Ã, int name;
};
int NAME_name;
And yeah, hehe, one can't have '::' as part of a var name - the above piece of code is compiled with no problems in the beta. :)
Quote
but I correctly got a compile error saying the "object" was already defined. Can you elaborate on what sort of code you had that lead it to crash?
The sample game I gave you produces the error. If you remember, you got the runtime error as well. If you don't have a copy of the sample it's still up here: http://www.gaia-spa.com/project/ags/
Quote from: Scorpiorus on Tue 14/12/2004 23:19:53
Having plugin to export properties would be a really nice feature.
Properties are translated into two functions:
type Struct::get_PropertyName(Struct *)
void Struct::set_PropertyName(Struct *, type);
where type is the property's variable type. If you export those (or just the "get" one for a readonly property) from the plugin that'll do the trick.
QuoteHehe, the reason I asked is because in earlier versions it wasn't possible to declare a var like this:
struct NAME {
int name;
};
int NAME_name;
Indeed, that's one of the things I fixed for the beta :)
QuoteThe sample game I gave you produces the error. If you remember, you got the runtime error as well.
Hmm, I just got an array index error. Anyway, glad it's all working now.
Quote from: Pumaman on Wed 15/12/2004 21:53:05
Properties are translated into two functions:
type Struct::get_PropertyName(Struct *)
void Struct::set_PropertyName(Struct *, type);
where type is the property's variable type. If you export those (or just the "get" one for a readonly property) from the plugin that'll do the trick.
Thanks for the info - I managed to get it to work with the following code:
Plugin code (changes in ags_template.cpp):struct FRUITS {
int Apples;Ã, Ã, // property
int bananas;Ã, // ordinary var
};
int get_Apples(const FRUITS * const pFruits) {
return pFruits->Apples;
}
void set_Apples(FRUITS * const pFruits, int newValue) {
pFruits->Apples = newValue;
}
...
const char *ourScriptHeader =
"Ã, struct FRUITS {Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, \r\n"
"Ã, Ã, import attribute int Apples;Ã, Ã, Ã, Ã, Ã, \r\n"
"Ã, Ã, int reserved; // $AUTOCOMPLETEIGNORE$ \r\n"
"Ã, Ã, int bananas;Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, \r\n"
"Ã, };Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, \r\n";
...
Ã, engine->RegisterScriptFunction ("FRUITS::get_Apples", get_Apples);
Ã, engine->RegisterScriptFunction ("FRUITS::set_Apples", set_Apples);
Main global scriptFRUITS fruits[3];
function game_start() {
Ã, // called when the game starts, before the first room is loaded
Ã,Â
Ã, Ã, int i = 0;
Ã, Ã,Â
Ã, Ã, while (i < 3)
Ã, Ã, {
Ã, Ã, Ã, Ã, Display("Apples: %d",Ã, fruits[ i ].Apples);
Ã, Ã, Ã, Ã, Display("Bananas: %d", fruits[ i ].bananas);
Ã, Ã, Ã, Ã,Â
Ã, Ã, Ã, Ã, fruits[ i ].Apples++;
Ã, Ã, Ã, Ã, fruits[ i ].bananas++;
Ã, Ã, Ã, Ã,Â
Ã, Ã, Ã, Ã, Display("Apples: %d",Ã, fruits[ i ].Apples);
Ã, Ã, Ã, Ã, Display("Bananas: %d", fruits[ i ].bananas);
Ã, Ã, Ã,Â
Ã, Ã, Ã, Ã, i++;Ã,Â
Ã, Ã, }
}
The first thing I realized that the property import declaration only adds get/set functions but not a variable to store the value, that's actually a clever way. So I added
int reserved;. :)
By the way, what about declaring a variable in the plugin code and then export its adress via RegisterScriptFunction. I tried to declare a struct var, export it from the plugin and then import into the script header (just like import GameCharacter character[]). That way we could access the var from both the script and the plugin itself. I seems to work fine. One thing though, for such imported struct var AGS doesn't show autocomplete list with struct's members.
It would be cool to be able to declare a pointer to this var in the script but it didn't work even if I define a struct as managed -
Error(...): Pointer cast failure: the object being pointed to is not in the managed object pool.p.s. sorry for cluttering the thread with somewhat aside issues. :)
EDIT:
After some testing I discovered the following issues:
1. Compiler doesn't allow to declare a pointer to a non-managed type but it's still possible to do that within the function header:
struct MyStruct {
Ã, Ã, int a;
};
function Func(MyStruct *Pointer) {
Ã, Ã, Pointer.a = 10;
}
On calling that function AGS reports an "object is not in pool" error. Seems not dangerous as the engine catchs that one at run-time. Just to let you know. :)
2. If function only has optional parameters and is called with default values the compiler doesn't allow that:
import function Func(int a = 0, int b = 0);
Funct();
I see that none of the imported internal functions is declared like this, so maybe it's not supposed that a function is declared this way.
3. Optional parameters only work in room scripts:
script header:
import function Func(int a, int b=0);
global script:
function Func(int a, int b) {
Ã, Ã, return a+b;
}
Func(1); // doesn't work
room script:
Func(1); // works
I believe that's because the global script has a function implementation code. And it's not possible to have a default value in there (unless the identifier is not specified):
global script:
function Func(int a, int b=0) { // doesn't work
Ã, Ã, return a+b;
}
global script:
function Func(int a, int=0) { // allowed but variable identifier is lost
}
Maybe not the right place for this, but there's no MP3-free version of AGS 2.62 on the main download page...
Quote from: Scorpiorus on Thu 16/12/2004 13:16:43
Thanks for the info - I managed to get it to work with the following code:
That looks exactly right, glad you got it working :)
Quote
The first thing I realized that the property import declaration only adds get/set functions but not a variable to store the value, that's actually a clever way. So I added int reserved;. :)
Yes, this is deliberate. The script compiler shouldn't make any assumptions about how the property is actually stored internally -- it might not even be stored as part of that struct necessarily. Your "int reserved" approach is the best way, and it's what I've done with the built-in AGS stuff.
Quote
By the way, what about declaring a variable in the plugin code and then export its adress via RegisterScriptFunction. I tried to declare a struct var, export it from the plugin and then import into the script header (just like import GameCharacter character[]). That way we could access the var from both the script and the plugin itself. I seems to work fine.
Yep, that should work fine, it's what AGS does to export stuff like the characters. This should be mentioned in the docs for RegisterScriptFunction really.
QuoteOne thing though, for such imported struct var AGS doesn't show autocomplete list with struct's members.
It should do -- so long as the struct definition and the import directive are part of the plugin's script header, it should be picked up. If it's not working, can you provide the plugins' script header and I can take a look at why it might not be spotting it.
Quote
It would be cool to be able to declare a pointer to this var in the script but it didn't work even if I define a struct as managed - Error(...): Pointer cast failure: the object being pointed to is not in the managed object pool.
Yes, this will be the case -- I need to add a new RegisterManagedObject function or something to the plugin API.
Basically, managed objects have a reference count maintained, and are automatically freed when the count reaches 0. (this is how things like the OpenFile function don't cause a memory leak).
In order for the reference count to work, AGS has to have the object in its "managed pool"; but currently there's no plugin access to do so.
QuoteMaybe not the right place for this, but there's no MP3-free version of AGS 2.62 on the main download page...
Hmm yeah, oops. Ah well, if anyone needs it, let me know and I'll see what I can do.
Quote from: Pumaman on Thu 16/12/2004 22:47:26The script compiler shouldn't make any assumptions about how the property is actually stored internally -- it might not even be stored as part of that struct necessarily.
Yeah, I got it after looking into a new GameObject struct - it mainly consists of properties but all of them should use old object's get/set functions.
QuoteYep, that should work fine, it's what AGS does to export stuff like the characters. This should be mentioned in the docs for RegisterScriptFunction really.
That's really cool - I can see some use for this. :)
QuoteIt should do -- so long as the struct definition and the import directive are part of the plugin's script header, it should be picked up. If it's not working, can you provide the plugins' script header and I can take a look at why it might not be spotting it.
Yep, and the strange thing - it happens to work with no problem. When I had
FRUITS fruits[3]; in the plugin header it worked. I'll try replicating and then provide all the info about it.
QuoteBasically, managed objects have a reference count maintained, and are automatically freed when the count reaches 0.
Ah, like in COM specification. So we have it similar to VB and every time the object address is written into a pointer or pointer is reset to nill the ref count is adjusted if necessary?
BTW, I noticed that in the beta a 'ac.log' file is created with all that stuff being logged into it. :)
Quote(this is how things like the OpenFile function don't cause a memory leak).
Ah, so a local pointer to file is reset and file is closed as the function is finished?
By the way, I had edited my previous post just a few minutes before you replied -- some testing results there.
Quote from: Scorpiorus on Fri 17/12/2004 19:15:04
Ah, like in COM specification. So we have it similar to VB and every time the object address is written into a pointer or pointer is reset to nill the ref count is adjusted if necessary?
Exactly. I prefer this method to the .net/java style because this way has determinalistic destruction of objects, which comes in handy for various things. The only potential problem is circular references, which is why pointers are not allowed inside struct definitions.
Quote
BTW, I noticed that in the beta a 'ac.log' file is created with all that stuff being logged into it. :)
Indeed ... this was in case it caused catastrophic crashes all over the place, I'd have some useful information to work from ;)
QuoteAh, so a local pointer to file is reset and file is closed as the function is finished?
Yes, if you forget to Close the file yourself, it will now automatically be closed when the File object goes out of scope.
QuoteCompiler doesn't allow to declare a pointer to a non-managed type but it's still possible to do that within the function header
Well spotted, I'll fix that.
QuoteIf function only has optional parameters and is called with default values the compiler doesn't allow that:
Hmm, that's a strange one, I'll look into it.
QuoteOptional parameters only work in room scripts:
Good point, I'll have a look at how difficult this would be to resolve.
Ok, here is a test game where struct members list doesn't seem to pop up after the this keyword followed by a dot:
// main global script file
// TYPE_MyCharacter Implementation:
function TYPE_MyCharacter::Init(CHARID id)Ã, {
this.
}
http://www.geocities.com/scorpiorus82/oos_test.zip (copy & paste)
It's right at the top of the main global script.
Tested with AGS v2.7 beta 6.
Thanks for that, it's a bit of an odd bug in the autocomplete. I'll get it fixed.
Right, beta 7 is now up.
The mouse functions have been object-ised, and that ends the objectisation that I'm going to do for 2.7. All the functions that have not yet been changed are not going to be changed, unless anyone can think of a good reason to.
Anyway, the new names for the mouse functions are still negotiable -- I've tried to rename them to make them better reflect what they do, but let me know if you disagree.
what are static member functions?
static member functions are functions which belong to a struct, but which are not part of an actual instance of a struct. In effect, they are global functions.
What's the point? Purely organisational. A static function could just as well be a normal global function but being grouped into a struct allows you to organise related functions better.
Example:
script header:
struct Blah {
import static function mystaticfunc();
};
global script:
static function Blah::mystaticfunc() {
}
usage:
Blah.mystaticfunc();
static functions do NOT have a "this" pointer since they do not belong to an instance.
what are protected members?
A protected member is only accessible to member functions within the struct, and cannot be used from outside. For example:
script header:
struct Blah {
protected int data;
import function SetData(int newdata) ;
};
global script:
function Blah::SetData(int newdata) {
this.data = newdata;
}
usage:
Blah bla;
bla.data = 5; // <--- ILLEGAL, WON'T COMPILE
bla.SetData(5); // <--- Use this instead
QuoteWell, this may well be the last beta before Christmas ... I hope you've all got the Santa hats out!
You said this for the previous beta. ::) You see, Chris, this is why we love you.
Quote* Setting the list box selected bkgrnd colour to 0 now makes it transparent.
* Fixed game load & restart crash bug in beta 6.
Yee-haw! Party time for me! ;D
I'm not sure if this is just me or not, but whenever I change like the speech style and the new "Enforce object-based scripting" the settings are either a) not saved, or b) when loaded, the checkbox and listbox don't get set.
I'm not sure if this is a bug that others are getting or just my whacky computer acting up again.
Oh, and Chris, thanks for all the crazy work you've done for AGS!Ã, If I were a girl, I'd have your baby.Ã, ... Well... maybe...
QuoteFor buttons, you can also find out whether the left or right mouse button was clicked.
How, exactly?
QuoteI'm not sure if this is just me or not, but whenever I change like the speech style and the new "Enforce object-based scripting" the settings are either a) not saved, or b) when loaded, the checkbox and listbox don't get set.
I just did a quick check and it worked fine. Are you sure this is happening? You did save the game after changing the settings, right?
QuoteEDIT: I've also sometimes had a problem that when I try to compile, I'll get like "Undefined Token 'InterfaceOn' " for a GUIOn in the keypress script.Ã, Also, when I create a new game using the "Default Game" Template, I get an undefined token for "LEFT". I assume that's because of the new changes with the mouse?
If you tick Enforce Object-based Scripting, then these functins are no longer supported. "GUIOn" has been replaced by "gGuiname.Visible = true;" and "LEFT" has been replaced by eMouseLeft.
QuoteHow, exactly?
Add a handler for the button (ie. double-click the "Click" entry at the bottom of the button's properties). The handler will be created with an "int button" parameter, which tells you whcih mouse button was used.
Ah, lovely. Thanks a bunch, I didn't know I could use that check here.
QuoteI just did a quick check and it worked fine. Are you sure this is happening? You did save the game after changing the settings, right?
I just tried it again, and it worked for me too, though I know I did save it before.
QuoteIf you tick Enforce Object-based Scripting, then these functins are no longer supported. "GUIOn" has been replaced by "gGuiname.Visible = true;" and "LEFT" has been replaced by eMouseLeft.
Heh. Yeah, I noticed that right after I posted that. Sorry. -_-
mouse.x, mouse.yMaybe these should be properties instead of global vars even though it's subtle distinction?
*** Edit ***
Quote
* Added support for static member functions.
* Added support for protected member variables/functions.
How to use these? Is it documented yet?
Rick, look a few posts above you... ;)
Thanks Strazer, found the explanation. I guess I just got over-excited. One remaining question; is it possible to have static member data and protected member functions? I'll try some experiments to find out.... :=
CJ, Thanks for the AGS 2.7 Christmas present.
... Merry Christmas All ...
Jet here again. Sorry to bug you, but I THINK I might have found another bug. I've included a sample game so you could check it out, but from what I can gather, this seems to be the issue: If you declare an array of a user-defined structures, in this case,
char_data pc[10];
And you set values out of order:
pc[0].SetName("Chris");
pc[2].SetName("Scorpiorus");
pc[1].SetName("Radiant");
Then it nulls out the value of element immediately before it. The sample game's example works just like this. The way it is now with pc[ARTEA] before the pc[RUNT] assignments, it works fine, but if you were to reverse them (put the RUNT assignments, then the ARTEA ones), it seems to null the ARTEA ones out. When testing the game, use the '+' to open a menu, and '0' (zero) to close it and you'll see what I mean. Code-wise, I think it should all be correct.
http://jetkobayashizala.kicks-ass.net/cb.zip
And don't forget: Merry Christmas, Happy Holidays, and all that good stuff to all of you awesome AGS'ers out there! Especially Chris!
When updating one of my demo games from Beta 4 to Beta 7, the editor didn't complain about
NewRoomEx(2, 10, player.y);
in the "Walk off right screen edge" interaction in one of the rooms (with object-based scripting enforced).
The game compiled fine. When walking off the right edge of the screen, it changed rooms, but the player character was nowhere to be seen. It didn't crash.
I had an NPC face him, and he faced downwards...?
I updated the line, and when I rebuilt all rooms, the editor correctly complained about the other similar line in the other room. Updated both, now it works.
With the original line restored and object-based scripting NOT enforced, everything works fine as well.
Hm, I don't know what exactly my point is, maybe a note about remembering to rebuild all room files prior to testing when a game from an earlier version is loaded into the editor?
And how about making MODE_LOOK, MODE_USEINV etc. enums too?
In another demo game, I get this:
QuoteAn exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x0044A974 ; program pointer is +1004, ACI version 2.70.807, gtags (0,0)
Can you tell from this what the problem could be?
Quote from: Pumaman on Sun 12/12/2004 18:23:36
All GUI controls now have a "Script name" property, which allows you to give them a VB-style "lstSaveGames" or "btnCancel" type name.
Then, in the script you can do stuff like:
lstSaveGames.AddItem("Jibble");
rather than
ListBoxAdd(3, 6, "Jibble");
This is way too cool to be true. It makes the code so much cleaner to read. However I had a bit of a problem with them GUIs. After five minutes of converting my old scripts into this oo-thing, I came upon
if (GetGuiAt(mouse.x, mouse.y) != 1) { do_stuff(); }
which I tried to change into GetGuiAtLocation. I also changed the 1 into GuiName, or something. Ags however said that I can't use != to compare two GUIs (I'm sorry, I don't have the exact error message with me here at uni) and I tried a bit more and I couldn't use == either. So I used the oh-so-cool .ID bit 'cause you can compare ints. And it worked, until there was no gui under mouse, ie. getguiatlocation gives
null which doesn't have .ID. Or at least the engine crashed saying something about pointers and all.
I worked through it with if and else, but still, isn't a bit annoying not to be able to compare GUIs? Or did I just do something wrong?
Quotemouse.x, mouse.y
Maybe these should be properties instead of global vars even though it's subtle distinction?
Perhaps, and that same argument could be applied to character[].x/y ... I'm not convinced of the need to change it.
Quoteis it possible to have static member data and protected member functions?
No and yes, respectively.Ã, :)
QuoteSorry to bug you, but I THINK I might have found another bug. I've included a sample game so you could check it out, but from what I can gather, this seems to be the issue:
I just tried to download your sample game, but the link didn't work. Without knowing the code behind the struct it's hard for me to replicate the problem.
Any chance you could just post the code for that struct and its functions?
QuoteWhen updating one of my demo games from Beta 4 to Beta 7, the editor didn't complain about
NewRoomEx(2, 10, player.y);
in the "Walk off right screen edge" interaction in one of the rooms
Ah, yes this is a problem with using "player". Because it's now a pointer to the current player character, the rooms need to be re-compiled in order to work with it. I'll add that to the 2.7 upgrade docs when the time comes.
QuoteIn another demo game, I get this:
An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x0044A974 ; program pointer is +1004, ACI version 2.70.807, gtags (0,0)
Can you tell from this what the problem could be?
Hmm no, that's strange -- any chance you could upload the game that causes the problem?
Quoteif (GetGuiAt(mouse.x, mouse.y) != 1) { do_stuff(); }
which I tried to change into GetGuiAtLocation. I also changed the 1 into GuiName, or something. Ags however said that I can't use != to compare two GUIs (I'm sorry, I don't have the exact error message with me here at uni) and I tried a bit more and I couldn't use == either. So I used the oh-so-cool .ID bit 'cause you can compare ints. And it worked, until there was no gui under mouse, ie. getguiatlocation gives null which doesn't have .ID. Or at least the engine crashed saying something about pointers and all.
GUI *theGui = GetGUIAtLocation(mouse.x, mouse.y);
if (theGui != null) {
if (theGui.ID == INVENTORY) {
Display("On the inventory GUI");
}
}
replace INVENTORY with the GUI ID, obviosuly.
I appreciate this is slightly more involved than the old GetGUIAt code, but it does add flexibility to the script language.
Quote from: Pumaman link=topic=17697.msg222907#msg222907
QuoteIn another demo game, I get this:
An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x0044A974 ; program pointer is +1004, ACI version 2.70.807, gtags (0,0)
Can you tell from this what the problem could be?
Hmm no, that's strange -- any chance you could upload the game that causes the problem?
Oh, it may be worth noting that I'm using the current beta with Wine (http://www.winehq.com/) (a Windows API wrapper) under Linux. I've pm'd you the game download location anyway.
Edit:
Haha, figures. I just found out I forgot to update the room file in this demo as well...
Sorry for wasting your time. Works now.
Hehe yep, that'll be it.
I think it'd probably be a good idea if AGS automatically recompiles all room files if you upgrade from a pre-2.7 version.
Seconded. ;)
Alrighty, here's the code. It's kinda big, sorry. :/
Here's the global header:
// Stats
#define STAT_STRENGTH 0
#define STAT_AGILITY 1
#define STAT_VITALITY 2
#define STAT_MAGIC 3
#define STAT_SPIRIT 4
#define STAT_LUCK 5
#define HP 0
#define MAX_HP 1
#define MP 0
#define MAX_MP 1
// EQ Slots
#define EQ_WEAPON 0
#define EQ_HEAD 1
#define EQ_BODY 2
#define EQ_ARMS 3
#define EQ_ACCESSORY 4
// Elements
#define ELEMENT_FIRE 0
#define ELEMENT_AIR 1
#define ELEMENT_WATER 2
#define ELEMENT_EARTH 3
#define ELEMENT_VOID 4
// Item Types
#define ITEM_GENERAL 0
#define ITEM_WEAPONÃ, 1
#define ITEM_ARMORÃ, Ã, 2
#define ITEM_MONEYÃ, Ã, 3
#define ITEM_KEYIYEM 4
// ------ keyboard control ------
#define DIR_DISTANCEÃ, Ã, 10000
#define DIR_DOWN_LEFTÃ, 1
#define DIR_DOWNÃ, Ã, Ã, Ã, 2
#define DIR_DOWN_RIGHT 3
#define DIR_LEFTÃ, Ã, Ã, Ã, 4
#define DIR_STOPÃ, Ã, Ã, Ã, 5
#define DIR_RIGHTÃ, Ã, Ã, 6
#define DIR_UP_LEFTÃ, Ã, 7
#define DIR_UPÃ, Ã, Ã, Ã, Ã, 8
#define DIR_UP_RIGHTÃ, Ã, 9
struct game_data {
Ã, int party[10]; // Stores order of party members by charID
Ã, long money; // Stores money; Score will be used for something else
Ã, long time; // Stores time in seconds. Can be converted later
};
struct char_data {
Ã, char name[15]; // Name of the character
Ã, char title[20]; // Character's job title
Ã, short basestats[6]; // "Natural" stats before eq
Ã, short stats[6]; // Stats after equipment and such
Ã, short hp[2]; // Character Hit Points
Ã, short mp[2]; // Character Magic Points
Ã, short level; // Character Level
Ã, long exp; // Character Experience
Ã, short element; // Character's Elemental Affinity
Ã, short eq[5]; // Stores index number of item in corresponding eq slot
Ã,Â
Ã, import function SetName (string newName);
Ã, import function SetTitle (string newTitle);
};
The global declarations in the main script file:
char_data pc[10];
game_data cb;
function char_data::SetName(string newName) {
Ã, StrCopy(this.name,Ã, newName);
}
function char_data::SetTitle(string newTitle) {
Ã, StrCopy(this.title,Ã, newTitle);
}
And then game_start where the members are initialized:
function game_start() {
Ã, // called when the game starts, before the first room is loaded
Ã, pc[SLADE].SetName("Slade Azurus");
Ã, pc[SLADE].SetTitle("Knight of Illus");
Ã, pc[SLADE].level = 17;
Ã, pc[SLADE].hp[HP] = 100;
Ã, pc[SLADE].hp[MAX_HP] = 150;
Ã, pc[SLADE].mp[MP] = 10;
Ã, pc[SLADE].mp[MAX_MP] = 1250;
Ã, pc[ARTEA].SetName("Artea Scotsen");
Ã, pc[ARTEA].SetTitle("Treasure Hunter");
Ã, pc[ARTEA].level = 24;
Ã, pc[ARTEA].hp[HP] = 200;
Ã, pc[ARTEA].hp[MAX_HP] = 250;
Ã, pc[ARTEA].mp[MP] = 150;
Ã, pc[ARTEA].mp[MAX_MP] = 167;
Ã, pc[RUNT].SetName("Runt");
Ã, pc[RUNT].SetTitle("Pickpocket");
Ã, pc[RUNT].level = 5;
Ã, pc[RUNT].hp[HP] = 20;
Ã, pc[RUNT].hp[MAX_HP] = 20;
Ã, pc[RUNT].mp[MP] = 0;
Ã, pc[RUNT].mp[MAX_MP] = 0;
Ã,Â
Ã, int i = 0;
Ã, while (i < 10) {
Ã, Ã, cb.party[i] = -1;
Ã, Ã, i++;
Ã, }
Ã, cb.party[0] = SLADE;
Ã, cb.party[1] = ARTEA;
Ã, cb.party[2] = RUNT;
Ã,Â
Ã, cb.money = 5000;
Ã,Â
Ã, mouse.Visible = false;
Ã, // ------ keyboard control ------
Ã, PrevDirection = DIR_STOP;
//Ã, SetGlobalInt (4, 1);
Ã,Â
}
SLADE, ARTEA, and RUNT are all character script names (ID's), so I use them as the array index holder. SLADE = 0, RUNT = 1, and ARTEA = 2. They are initialized and output in a menu later. With the above code, the pc[2] (pc[ARTEA]) ends up blank, but if you switch them and put pc[RUNT] first, it works fine. Oh, and if you need the sample game, the link should work now. If not, I can always e-mail it or something.
You might try making the char[]s 201+ bytes as below:
Quote
char name[201]; // Name of the character
char title[201]; // Character's job title
I bet other elements in your struct are zero as well when this problem occurs.
This is going to need some better documentation, I'm afraid. I don't understand, for instance, why
GUIControl *whichBut=GetGUIControlAtLocation(mouse.x, mouse.y);
if (whichBut==null) {
Ã, if (gAction.Visible || gShort.Visible) {}
}works and
GUIControl *whichBut=GetGUIControlAtLocation(mouse.x, mouse.y);
if ((gAction.Visible || gShort.Visible) && whichBut==null) {} gives the following error upon compiling:
QuoteError (line 628): Type mismatch: cannot convert 'null*' to 'bool'
And incidently, I've been experimenting with that "GetGUIAt(mouse.x,mouse.y) replacement a bit. WHY do we need to compare with null first? I mean, logically, if I just did stuff like "if (whichGUI.ID == INVENTORY)" and kept on with that sort of thing, why should ANYTHING happen when it returns "null" since I didn't code it?
EDIT - Ok, nevermind the 1st one, I just tripped on the answer - we can't use operators with this type. This should be documented indeed. But the second question remains.
Er... would it work if you put more brackets around the == null comparison?
Indeed, it might make life easier if there was a shorthand like
if (something.safeID == INVENTORY)
where safeID was like ID, but was also defined for the null pointer too, as -1 or something
or even...
try { if (something.ID == INVENTORY) { .... } }
catch {}
:=
QuoteYou might try making the char[]s 201+ bytes as below:
Exactly right. Your problem is that StrCopy assumes the destination has a 200 byte buffer (since all "string" variables are allocated one) and therefore blats over it, padding out the text with zeros.
I'll see about changing this behaviour because it is a bit odd, but for now do as Rick suggests and increase the char buffer lengths to 200.
Quoteif ((gAction.Visible || gShort.Visible) && whichBut==null) {}
gives the following error upon compiling:
Error (line 628): Type mismatch: cannot convert 'null*' to 'bool'
Well spotted, that's a bug in the compiler -- that line should compile fine. I'll get it fixed.
QuoteWHY do we need to compare with null first? I mean, logically, if I just did stuff like "if (whichGUI.ID == INVENTORY)" and kept on with that sort of thing, why should ANYTHING happen when it returns "null" since I didn't code it?
It's to do with the way object oriented systems work. If there is no GUI, then there is nothing to access in the script, so null is returned instead. If you then try and access the ID of nothing, it all breaks down and cries.
What I could do is rather than returning null, return some sort of dummy GUI object with an ID of -1 or something ... might make it easier for people to get to grips with.
QuoteEr... would it work if you put more brackets around the == null comparison?
Sadly, no. The following line:
if ((whichGUI!=null) && (whichBut!=null)) {
...displays the same operator error.
Er, I think I misunderstood the second part of your post, SSH. Was that "try" for me to try something?
EDIT - And
if ((gAction.Visible || gShort.Visible) && (whichBut==null)) {}
still has the same error, too.
Redrum: see my edit above
No, try and catch are C++/Java keywords used to do exception handling. That way, you can make a piece of code never have any runtime errors occur. But I think that you should be able to use && and || on the boolean result of an == to null... CJ get fixing!
Ok then, glad to have been of assistance in bug reporting. :)
QuoteWhat I could do is rather than returning null, return some sort of dummy GUI object with an ID of -1 or something
Actually, what about SSH's "safeID" suggestion? It sounds nice...
QuoteNo, try and catch are C++/Java keywords used to do exception handling. That way, you can make a piece of code never have any runtime errors occur.
Oh dear, I can just imagine the chaos that would ensue if that was added. Whenever anybody got an error message they would start to wrap all their code in try-catch blocks to make the message go away, and then they'd wonder why their script wasn't working properly :P
QuoteActually, what about SSH's "safeID" suggestion? It sounds nice...
It's not possible. If the returned value is null, then there is no GUI there, nothing exists to ask for its SafeID.
Ok then, your suggestion sounds nice. As long as we don't have to start by checking whether the thing is null, that's one of those little extra hassles no one really needs.
I suppose you could argue the same about putting a semicolon at the end of all your lines; anyone who's done any Java or C# will be used to checking if things are null ... I guess it's just something you pick up with the language.
Anyway, I'll see what I can do because I agree that it would make things easier to use.
Yeah, but anyone who's worked with previous versions of AGS has picked up the semicolon. And has ALSO picked up not-checking-for-null and related...
If our macros could be parameterised, and if we had the ?: operator...
#define SafeID(x) ((x == null) ? -1 : x.ID)
btw...
Having this semi-OOP stuff will make co-operative programming easier, but it would be great if there was a way to have multiple "files" in a global script and a way to import and export them
Thanks, Chris, for the fixes and new features for the beta 7. All the previous issues with compiling were successfully resolved. :)
Quote* Autocomplete now shows struct types as well as global variables.
Hehe, thanks for that. ;)
Quote* Added support for static member functions.
* Added support for protected member variables/functions.
These are great!
Sorry to bug you about autocomplete/calltips again, but the editor doesn't show parameters list for new static and protected functions, thus:
mouse.SetPosition(
and
this.SomeProtectedFunction(
won't show the list.
Quote from: Pumaman on Wed 22/12/2004 12:15:27
QuoteYou might try making the char[]s 201+ bytes as below:
Exactly right. Your problem is that StrCopy assumes the destination has a 200 byte buffer (since all "string" variables are allocated one) and therefore blats over it, padding out the text with zeros.
By the way, it just occured to me, what if we change character[].name variable with StrCopy? It's declared as
char name[40]; in the built-in header.
Also there is a character[].scrname variable (char scrname[20]) which isn't readonly so when I'd tried doing:
StrCopy(character[ 0 ].scrname, "XXX");
...the following
char GameCharacter::on variable was overwritten with 0. Not sure about variables of the next character in the character[] array.
I'm worried because we had questions like "How can I change character's name?" and the answer was in using StrCopy to alter character[].name.Ã, :-\
QuoteI'll see about changing this behaviour because it is a bit odd
Maybe for now the compiler could allow declaring strings in structs and substitute
string text; for
char text[200];?
QuoteI suppose you could argue the same about putting a semicolon at the end of all your lines; anyone who's done any Java or C# will be used to checking if things are null ... I guess it's just something you pick up with the language.
Seconded! I would rather prefer to compare a returned value with null. I think it would be more conventionally correct for all object-reference-getting functions to return
null if the object doesn't exist or is out of the coverage. Because if a dummy object is returned instead then I can't use null anymore. I believe, that means all such functions would return their own dummy object whereas others would still return null? Hmm, personally, it makes things confusing to me.
QuoteSorry to bug you about autocomplete/calltips again, but the editor doesn't show parameters list for new static and protected functions
Oops, well spotted, I'll get it fixed.
QuoteBy the way, it just occured to me, what if we change character[].name variable with StrCopy? It's declared as char name[40]; in the built-in header.
Changing the name like this is ok -- StrCopy does a special check to see if the string is a character name variable, and if so limits it to 40 characters instead.
However, scrname is a very good point. I'll make it readonly, but the problem is that won't stop you passing it to StrCopy. Really, I hope nobody is silly enough to try and change the script name at runtime.
QuoteMaybe for now the compiler could allow declaring strings in structs and substitute string text; for char text[200];?
That's a possibility; I'd still like to implement string support properly but we'll see.
QuoteSeconded! I would rather prefer to compare a returned value with null. I think it would be more conventionally correct for all object-reference-getting functions to return null if the object doesn't exist or is out of the coverage. Because if a dummy object is returned instead then I can't use null anymore. I believe, that means all such functions would return their own dummy object whereas others would still return null? Hmm, personally, it makes things confusing to me.
Personally, I agree with you 100%. However, in terms of GetGUIAt, having to check for null is an "extra step" and I can see a lot of people complaining that "they never had to do that in 2.62, so why do they have to now?" and so forth -- therefore I'm quite tempted to add the dummy object.
Functions like OpenFile would still return null because you need to check for success anyway before using a file. (on a sidenote, should OpenFile become File.Open now that static funcs are implemented?)
The other possibility for GetGUIAt is to retain the old versions that return the GUI number, and then just have some sort of GetGUIByID(int id) function to return the GUI object if you need it.
Yeah. Same for GetGUIObjectAt, if possible - it's kind of a pain to have to initialize a *thingy everytime I want to check for them, especially if in different functions.
I have just tried the following:
repeatedly execute:GUI *gui = GetGUIAtLocation(mouse.x ,mouse.y);
if (gui == gInventory) {...}
if (gui == gIconbarÃ, ) {...}
if (gui == gStatusbar) {...}
It didn't compile but, Redrum, maybe it is that what you're trying to convert the things to?
Could this be added, CJ?
It won't work with GUI objects since they can be objects of different types and didn't have names in 2.62 or earlier.
But names can be added automatically -- gInventory_Object0, gInventory_Object1, etc.
Unfortunately, the compiler won't allow to compare a base pointer with a pointer to an object of a child struct. I see a workaround in allowing pointer comparison regardless of their types but this is, of course, not the best solution as we may end up comparing two entirely different objects (although, such if-blocks shouldn't run at run time as long as both pointers don't hold nulls).
QuoteThe other possibility for GetGUIAt is to retain the old versions that return the GUI number, and then just have some sort of GetGUIByID(int id) function to return the GUI object if you need it.
So, you mean there will be no
GUI* GetGUIAtLocation? But then it means that we still will have to use ID in object-oriented scripting? EDIT: On the other hand, we still, in any case, have to access many things through ID (in fact, that's the only way to iterate, since arrays of pointers are not supported). Hmm...
Quoteon a sidenote, should OpenFile become File.Open now that static funcs are implemented?
Seems reasonable to me.
Quote from: strazer on Mon 20/12/2004 08:40:41And how about making MODE_LOOK, MODE_USEINV etc. enums too?
Btw, a good idea -- thus the modes would be shown for the appropriate mouse function.
Yes, Scorpiorus, that's quite what I was trying to do. And it was also in rep_execute.
Well, full-scale try/catching for errors is going way too far, obviously - but a bit more control over it would be nice. It seems rather arbitrary which errors crash your game, and which merely put a warning in the logfile, for instance. Also, I believe that teleporting to a non-existant room (especailly with the ^X debug command) should not crash your game, but for instance stay in the current room.
Alrighty, thanks all. I didn't know about the 200 string size. Sorry about that. However, I don't know why I'm not using the character.name anyway which would work just as fine. Thanks CJ, Scorp, and all!
If you load the "Default game" template as new game in beta 7, spend ages setting up a bunch of stuff , importing sprites, etc, and then save the game without having a room file, it crashes without any warning/dialog after the dialog box about "no room files" is OKed...
I'm not going to try and reproduce this, tho :( It doesn't happen if you do it straight away after using that template... I guess it may be dependednt on sommething I changed (and lost). Oh, I also did run a "Recompile all room files" earlier on, which appeared to do nothing at the time.
The "edit this AGS game" file had been modified, as had Compiled/acsetup.cfg, but all other files had not been changed from when I first created game from template (1 hour 40 mins earlier >:( >:( >:( )
There were backup versions of the .dta and .spr files in the game directory, with the older modification times.
Actually, I've had similar problems recently. Never COULD reproduce them. Random weirds instances where AGS quits.
Quote from: Scorpiorus on Wed 22/12/2004 17:33:02
if (gui == gStatusbar) {...}
Could this be added, CJ?
Yeah that could be added. The only reason I'm nervous to is because people won't necessarily realise it's a pointer comparison, and might assume it does a proper full struct compare. Not too important with GUIs, but if you had some sort of custom struct it has potential to confuse people.
But actually, this is probably the neatest solution. It avoids the dummy object, allows it still to return null which is the OO-way, and still makes comparing the result a single if statement, as before.
QuoteUnfortunately, the compiler won't allow to compare a base pointer with a pointer to an object of a child struct. I see a workaround in allowing pointer comparison regardless of their types but this is, of course, not the best solution as we may end up comparing two entirely different objects (although, such if-blocks shouldn't run at run time as long as both pointers don't hold nulls).
Yeah, allowing base pointer comparisons sounds like the neatest solution here.
QuoteIt seems rather arbitrary which errors crash your game, and which merely put a warning in the logfile, for instance. Also, I believe that teleporting to a non-existant room (especailly with the ^X debug command) should not crash your game, but for instance stay in the current room.
Well, the idea is that errors are given for things where there is no reasonable default course of action, and where the game author needs to fix the problem. For example, a NewRoom failure could stay in the current room, but that wouldn't be intuitive and people would complain "NewRoom doens't work!!!!11".
QuoteIf you load the "Default game" template as new game in beta 7, spend ages setting up a bunch of stuff , importing sprites, etc, and then save the game without having a room file, it crashes without any warning/dialog after the dialog box about "no room files" is OKed...
:(
Sorry to hear that ... I've not had any such problems myself, and it's strange that there was no error dialog either.
Save early, save often, as they say.
QuoteThere were backup versions of the .dta and .spr files in the game directory, with the older modification times.
That's strange in itself. The backup spr file is only created once the ac2game.dta has been saved successfully, so if you have a .spr backup then you should have a working ac2game.dta. Unless the backup was created as part of the New Game creation process, of course.
Can I make a struct member variable that can be written only by functions of the struct but can be read directly by all other functions?
Do I really need to make Getxxx functions for every variable?
Quote
Can I make a struct member variable that can be written only by functions of the struct but can be read directly by all other functions?
Do I really need to make Getxxx functions for every variable?
Interesting idea, I'll certainly consider it. Can you think of a snappy keyword to represent this?
readonlyexternal comes to mind, but that's a bit unwieldy.
Anyway, beta 8 is now up. This fixes a few things, and adds a float data type. Currently Display() doesn't support floats, so there's no way to display the current value of one other than doing a FloatToInt on it and displaying the rounded value. I'm looking into solutions for this.
Now that's definitely the last beta before Christmas -- I'm off for a Christmas break tomorrow. Have a great holiday, everyone! :)
QuoteInteresting idea, I'll certainly consider it. Can you think of a snappy keyword to represent this?
readonlyexternal comes to mind, but that's a bit unwieldy.
Actually, I thought that was what "protected" would do. After all, what's the harm of reading a variable?
How about "writeprotected"? :)
Happy holidays!
Here are a few possible keywords for the "readonlyexternal" thingie,
- readonly, readonlyext
- readext or readexternal
- readpub or readpublic
- writeprotected
- protectedw
Sorry if I made a mistake or it was answered already, as I didn't really have a better look on the beta until now. (Since I have absolutely no knowledge in OO-scripting, it's something completely alien to me).
As what I can see currently, when using GUI functions, you have to use something like gInventory.Whatever() (it seems you can't use things like gui[1].Whatever() like characters and objects do), normally that's okay, but for some more advanced stuff this can be a pain. Say for example:
1. You cant do things like this easily:
int a=0;
while (a<5) {
GUIOff(a);
a++;
}
2. Say for example I have a battle system, where you control 3 characters, each have a similar GUI to control his actions (say #3-#5, all appear at the sametime), to simplify the codes you can do something like below in InterfaceClick():
if ((interface>=3)||(interface<=5)){ //clicked on battle GUIs
if (button==1) { //attack
//blah blah attack action for appropiate character
} else if (button==2) {.....
....
}
}
If I insist on using this new OO convention you may need to repeat the scripts several times.
So, does this mean that I have to use old style scripting instead in these circumstances? That way the old functions can't be all made obsolete actually, and it's not quite possible to change everything to this OO format anyway. (Or are there ways around such problems? I don't know anything about OO so I can't tell).
Second Gilbot's suggestion of a gui[n] array....
Actually, now that GUIs can have their own individual handlers, would it be possible to allow import and export of individual GUIs rather than always havign to load and save the whole set of GUIs. That would be another boon to co-operative development: it would also make it easier for someone to import, for example a Savegame-with-screenshot GUI on top of whatever GUIs they are using already.
Another thing that I thoguht would be nice is to have user-defined Game properties, like you have room, onject, character properties already. And, as I think is on your list already, sepearate schemeas for the different types of object.
The nomenclature is getting a bit confused now, too. I mean we have Objects (OOP) and Objects (in rooms), and we have Properties (OOP), Properties (things like anti-glide mode) and Properties (user defined schema)... maybe some thoguht needs to go on giving them well-defined and different naming conventions?
Quote
.. would it be possible to allow import and export individual GUIs rather than always havign to load and save the whole set of GUIs.
I second SSH's suggestion as long as there was an "ALL" option. I think this would be helpful to some people.
A couple more things....
I got that crash again, and it is very intermittent. Fortunately this time I had saved 30 seconds before again. It always seems to happen on a save, but I reloaded my 30-second old game and tried doing the same chnages again (it was all just changing stuff on the game settings page). This time it saved OK. Something intermittent like this implies "memory leak" to me!
I suggest you try loading in a bunch of sprites, editing GUIs, change stuff here and there for a while and see if you can get the crash too, CJ. I'd never seen this instability before this beta, and I think it will really bug people.
Secondly, if you have a GUI control you called the object handle goPUsh by mistake and you want to change it to goPush, it wont let you and you have to rename it via "temp" or something first then back to what you wanted. It seems that the object check is case-insensitive, and also includes itself if the check of clashing names...
I second Gilbots suggestion aswell, and extend it to gui buttons also. It would be great to have gui[n].button[n] or something similar.
Also, not sure if its related to this beta or even if its my fault, but i have 4 guis i want to resize at the same time. 3 of them i have no problem with, but there is one that does not resize properly, unless i write the resizing function twice.
this does not work:
gFri.SetSize(HRES - xright,FHEIGHT);
but this works:
gFri.SetSize(HRES - xright,FHEIGHT);
gFri.SetSize(HRES - xright,FHEIGHT);
seemed strange to me, so i thought i'd say it just in case.
thanks for all the hard work chris : )
For what it's worth, I agree with Gilbot and SSH's earlier suggestions.
For nomenclature, the things in rooms have always been called objects in AGS, so I think they should stay that way. The OOP-objects could be referred to as classes, maybe? Like they are in C++.
Properties... well maybe this could be cleared up by referring to room.properties, character.properties, etc.
QuoteActually, I thought that was what "protected" would do. After all, what's the harm of reading a variable?
You may want to manipulate the data before you return it.
Case in point -- the character[].idleview variable. Because internally AGS stores the view number minus 1, giving the script direct access to it caused confusion and problems. With a GetIdleView approach (via the property), the script can be given the correct value that it expects.
QuoteHere are a few possible keywords for the "readonlyexternal" thingie
Thanks, I'll have a think about it.
QuoteAs what I can see currently, when using GUI functions, you have to use something like gInventory.Whatever() (it seems you can't use things like gui[1].Whatever() like characters and objects do), normally that's okay, but for some more advanced stuff this can be a pain. Say for example:
I agree, a gui[] array would be useful. The only thing is, a lot of people will have "int gui" variables so I don't want to name the array "gui" because it will cause all sorts of problems. So then, I could call it "guis" instead but that's inconsistent. Ah well, nothing's perfect.
QuoteActually, now that GUIs can have their own individual handlers, would it be possible to allow import and export of individual GUIs rather than always havign to load and save the whole set of GUIs. That would be another boon to co-operative development: it would also make it easier for someone to import, for example a Savegame-with-screenshot GUI on top of whatever GUIs they are using already.
Yeah, that's something that could reasonably be added now. And with names rather than numbers, it doesn't matter if the imported GUI has a different number to where it was exported from.
QuoteThe nomenclature is getting a bit confused now, too. I mean we have Objects (OOP) and Objects (in rooms), and we have Properties (OOP), Properties (things like Ã, anti-glide mode) and Properties (user defined schema)... maybe some thoguht needs to go on giving them well-defined and different naming conventions?
I agree -- Ã, the object (struct) thing vs the object (room object) thing is particularly confusing -- any ideas on how to clarify this would be welcome.
QuoteI got that crash again, and it is very intermittent. Fortunately this time I had saved 30 seconds before again. It always seems to happen on a save, but I reloaded my 30-second old game and tried doing the same chnages again (it was all just changing stuff on the game settings page). This time it saved OK.
Hmm, I'll try and see if I can replicate it. How long did you work in the editor for before the crash happened?
QuoteSecondly, if you have a GUI control you called the object handle goPUsh by mistake and you want to change it to goPush, it wont let you and you have to rename it via "temp" or something first then back to what you wanted. It seems that the object check is case-insensitive, and also includes itself if the check of clashing names...
I'll look into it.
QuoteAlso, not sure if its related to this beta or even if its my fault, but i have 4 guis i want to resize at the same time. 3 of them i have no problem with, but there is one that does not resize properly, unless i write the resizing function twice.
That's very strange, can you upload something that replicates the problem?
QuoteI got that crash again, and it is very intermittent.
I've just been investigating this, and I have managed to get a crash myself, but whether it's the same one or not, I don't know.
The crash I'm getting happens if you have been editing a room with no code in its room script, and didn't save the room before loading another one. I'll get it fixed, but does this sound like something you'd have done in the time leading up to the crash?
Quote from: Pumaman on Fri 24/12/2004 13:55:14
QuoteActually, I thought that was what "protected" would do. After all, what's the harm of reading a variable?
You may want to manipulate the data before you return it.
Case in point -- the character[].idleview variable. Because internally AGS stores the view number minus 1, giving the script direct access to it caused confusion and problems. With a GetIdleView approach (via the property), the script can be given the correct value that it expects.
QuoteHere are a few possible keywords for the "readonlyexternal" thingie
Thanks, I'll have a think about it.
I don't know if you're familiar with C#, but it uses a concept it calls Properties (though it seems we're already using that word for three other things, one of which I've always called member variables) to get around the GetX()/SetX() inconvenience. You can define a member "variable" that is actually a pair of methods:
private int m_hiddenvariable;
public int MyProperty
{
Ã, Ã, get
Ã, Ã, {
Ã, Ã, Ã, return m_hiddenvariable;
Ã, Ã, }
Ã, Ã, set
Ã, Ã, {
Ã, Ã, Ã, m_hiddenvariable = value;
Ã, Ã, }
}
If you omit the "set" block, the property can be read but not written to. The "get" and "set" blocks can manipulate the output and input data (for instance to perform bounds checking or handle special cases).
Quote from: Radiant on Fri 24/12/2004 13:53:53
For nomenclature, the things in rooms have always been called objects in AGS, so I think they should stay that way. The OOP-objects could be referred to as classes, maybe? Like they are in C++.
Objects aren't called classes in C++. They're called objects. A class is a type of object, and an object is an instance of a class.
Quote from: Pumaman on Fri 24/12/2004 13:55:14
QuoteThe nomenclature is getting a bit confused now, too. I mean we have Objects (OOP) and Objects (in rooms), and we have Properties (OOP), Properties (things like Ã, anti-glide mode) and Properties (user defined schema)... maybe some thoguht needs to go on giving them well-defined and different naming conventions?
I agree -- Ã, the object (struct) thing vs the object (room object) thing is particularly confusing -- any ideas on how to clarify this would be welcome.
How about talking about game objects and game properties (or AGS objects/AGS properties) when referring to the AGS concepts, and just objects and properties (or variables) when referring to the OO concepts? Or renaming the old "objects" to "items".
Quotedon't know if you're familiar with C#, but it uses a concept it calls Properties
Yeah, this is what AGS does for the built-in properties, it just doesn't currently support them for user-written script.
QuoteHow about talking about game objects and game properties (or AGS objects/AGS properties) when referring to the AGS concepts, and just objects and properties (or variables) when referring to the OO concepts? Or renaming the old "objects" to "items".
I really don't want to rename the old objects to something else -- that would cause no end of confusion. We do need some way to make it distinct -- perhaps have another word (totally unlike "object") for the script OO objects.
Quote
I really don't want to rename the old objects to something else -- that would cause no end of confusion. We do need some way to make it distinct -- perhaps have another word (totally unlike "object") for the script OO objects.
Previously, in this thread, I have used "oobject" and "object" to make the distinction. I don't think I could make the case that "oobject" is totally unlike "object" though. ;)
So instead why not just call them "structures" instead of "objects". I know that those of us with C or C++ experience will find this suggestion unpleaseant (I do as well.). However, if we can put our prejudice aside for a moment, IMHO, we may be able to see some merit in this idea. I think most of the folks will find it easy to make the connetion between "struct" and "structure" and will be untroubled by the terminology. Those of us who who have enough programmng experience to not like it should, by definition, have enough programming experience to get over it.
Maybe it's just my Linux chm viewer acting up but could it be that a lot of entries for the new functions don't link to their anchors on the respective pages in the help file?
Also, I'm in favor of object-ising walkable areas, regions and walkbehinds as well.
As it is now, their functions seem out-of-place compared to the rest of the scripting language.
I vote for at least grouping them via static member functions so you have the advantage of auto-completion.
And how about merging PlaySound and PlaySoundEx now that parameters can be optional?
Not specifying a channel would use PlaySound as usual, otherwise it would act like PlaySoundEx.
Little bug: GUIs are displayed under 'display' text, but over 'displayspeech' text.
Hmmm, but that one's been there for a loong time now, ain't it? I thought it even had it's own tracker entry.
Idea: Could the room id numbers be enumerated constants so that you could use either the room name or the room number?
So instead of this:
character[EGO].ChangeRoom(0, 100, 50);
You would something like this:
character[EGO].ChangeRoom(eIntro, 100, 50);
I've been experimenting with two of the new features in this beta version - Int to Float and Float to Int. I've been attempting to display a floating number on a GUI label. For example, displaying the number 1.50 or 15.3.
However, when executing the program, the number remains to be displayed as a fixed number, opposed to a floating one. 1.50 is only displayed as 1 and 15.3 is only displayed as 15. How can I properly script these numbers as floats ?
Thanks.
Quote from: Pumaman on Thu 23/12/2004 22:58:26Anyway, beta 8 is now up. This fixes a few things, and adds a float data type. Currently Display() doesn't support floats, so there's no way to display the current value of one other than doing a FloatToInt on it and displaying the rounded value. I'm looking into solutions for this.
So, no, you can't display a floating point number at the moment, they're currently used only for in-game calculations.
BTW CJ: I see that it's just a start, but the current set of floating point functions are obviously not that enough, I think at least arctan/arcsin/arccos and RaisetoPower (float base, float power) can be useful additions (only square root is not really enough).
You can't create
member functions that have the same name as a built-in global function.
Is this something that can be fixed?
Edit:I get
Quote
Exception 0xC0000005 at EIP=0x005E6AB1, AGSE v2.70.549
if I do this:
// Main header script
#define AGS_MAXREGIONS 16 // including region 0!
struct ccsRegionType {
short framesounds[128000]; // 3d array: AGS_MAXVIEWS*AGS_MAXLOOPSPERVIEW*AGS_MAXFRAMESPERLOOP
};
// main global script file
ccsRegionType ccsRegion[AGS_MAXREGIONS];
and try to save the game. Can anyone confirm this?
Understood, thanks for clearing that up, Gilbot. I'm glad to hear though that float calculations are getting more attention though, as I've been trying to display float numbers in my game for nearly a year now. I thought that perhaps this was the implementation that I was looking for. I considered writing a custom plug-in, but didn't want to limit the portability of games on different platforms. Anyway, thanks again, I'm sure it will be implemented sooner or later.
Actually there're workarounds for displaying decimal numbers.
If you want to display a float variable, say, num with 3 decimal places, you can do something like:
int tempnum=FloatToInt(num * 1000.0, eRoundNearest);
Display("The number is:%d.%03d",tempnum/1000, temp%1000);
EDIT: Fixed it so it actually works.
Reminder: As the engine can't do type conversions internally, you need to use (num*1000.0) instead of (num*1000), else there'll be a typemismatch error (as 1000 is an integer, but 1000.0 is "not" an integer).
Quote from: Radiant on Tue 28/12/2004 21:35:31
Little bug: GUIs are displayed under 'display' text, but over 'displayspeech' text.
Quote from: Rui "Puss in Boots" Pires on Tue 28/12/2004 22:11:06
Hmmm, but that one's been there for a loong time now, ain't it? I thought it even had it's own tracker entry.
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=126
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=256
I've noticed since... I believe Beta 7 that when I start doing a lot of GUI work (making more than one with several objects per GUI), it'll stop allowing me to name the GUI controls, and shortly after that, I get the following crash error:
(Exception 0xC0000005 at EIP=0x00428F52, AGSE v 2.70.549)
On a side note, I'm not sure if this would have happened before B7 since I only recently went GUI-building-crazy and started shortly after Beta 7 came out.
Regarding Sierra-style-portraits with character speech...
the character only loops his talking animation for a certain amount of time depending on text length.
However, after this time, he will no longer blink either!
Plus a small feature request: portraits are alternately displayed on the left and right side of the screen... it would be nice if all portraits on the right side were mirrored horizontally.
These additions are scary and confusing, to say the least. I desperately hope that these new object-oriented commands and variables will be explained in the manual, because I don't quite get them as of yet. :P
QuoteMaybe it's just my Linux chm viewer acting up but could it be that a lot of entries for the new functions don't link to their anchors on the respective pages in the help file?
Can you give an example?
QuoteAlso, I'm in favor of object-ising walkable areas, regions and walkbehinds as well.
As it is now, their functions seem out-of-place compared to the rest of the scripting language.
I vote for at least grouping them via static member functions so you have the advantage of auto-completion.
The reason I haven't done this is that I didn't want to obsolete more functions than necessary, where there wasn't a clear benefit in making the switch.
However, you may be right -- it might be better to get it all over with now and change the lot, rather than coming back in a few months time and deciding to change them after all.
QuoteAnd how about merging PlaySound and PlaySoundEx now that parameters can be optional?
Not specifying a channel would use PlaySound as usual, otherwise it would act like PlaySoundEx.
That would indeed be possible now; I'd have to rename PlaySound in order to do so, however. Perhaps this can wait until and if the global functions like PlaySound get objectised.
QuoteLittle bug: GUIs are displayed under 'display' text, but over 'displayspeech' text.
This is the way things have always worked; it's not necessarily intuitive, but it's just the way AGS works. There is an outstanding request to allow DisplaySpeech to be displayed on top of GUIs.
QuoteIdea: Could the room id numbers be enumerated constants so that you could use either the room name or the room number?
Yeah, script names for rooms have been requested before. It's not something I'm aiming to add in 2.7 though.
QuoteBTW CJ: I see that it's just a start, but the current set of floating point functions are obviously not that enough, I think at least arctan/arcsin/arccos and RaisetoPower (float base, float power) can be useful additions (only square root is not really enough).
Well, the ones I added are ones I've noticed people requesting in the past. If atan/asin/acos/power are functions people would find useful, then I can certainly add them. Any others while we're at it?
QuoteYou can't create member functions that have the same name as a built-in global function.
Is this something that can be fixed?
Unfortunately this is non-trivial to fix... this is one reason why it'd be nice to make everything object-based to clear the global namespace, but it's not something I'm too concerned about at the moment.
QuoteI get
Exception 0xC0000005 at EIP=0x005E6AB1, AGSE v2.70.549
if I do this:
Well spotted -- this happens if a single array is bigger than 32 KB. I'll get it fixed.
QuoteI've noticed since... I believe Beta 7 that when I start doing a lot of GUI work (making more than one with several objects per GUI), it'll stop allowing me to name the GUI controls, and shortly after that, I get the following crash error:
Thanks for the bug report -- I think I've located the problem and will fix it for the next beta.
QuoteRegarding Sierra-style-portraits with character speech...
Ok, can I please request that there are
no further feature requests in this thread. There's quite a lot of stuff to deal with in terms of the scripting changes, so can we leave other things aside for now.
QuoteThese additions are scary and confusing, to say the least. I desperately hope that these new object-oriented commands and variables will be explained in the manual, because I don't quite get them as of yet.
I'll write an "upgrading to object-based scripting" guide before 2.7 Final is released.
Quote from: Pumaman on Sun 02/01/2005 17:44:24Can you give an example?
If I choose "Text Scripting" -> "Character functions and properties" from the contents and click
SetCharacterProperty
it jumps to its position on the page, but when I click
View property
for example, it jumps to the top of the page. This happens with a lot of the new entries. As I said, it may be a quirk of the Linux program I'm using.
Quote from: Pumaman on Sun 02/01/2005 17:44:24The reason I haven't done this is that I didn't want to obsolete more functions than necessary, where there wasn't a clear benefit in making the switch.
However, you may be right -- it might be better to get it all over with now and change the lot, rather than coming back in a few months time and deciding to change them after all.
If you intended to change them anyhow, I agree now would be the time to do so.
Quote from: Pumaman on Sun 02/01/2005 17:44:24That would indeed be possible now; I'd have to rename PlaySound in order to do so, however. Perhaps this can wait until and if the global functions like PlaySound get objectised.
Ok, I didn't realize the function would have to be renamed. In that case it can probably wait.
Quote from: Pumaman on Sun 02/01/2005 17:44:24Unfortunately this is non-trivial to fix... this is one reason why it'd be nice to make everything object-based to clear the global namespace, but it's not something I'm too concerned about at the moment.
I see, no problem.
Quote from: Pumaman on Sun 02/01/2005 17:44:24
Well spotted -- this happens if a single array is bigger than 32 KB. I'll get it fixed.
Cool, thanks.
QuoteIf I choose "Text Scripting" -> "Character functions and properties" from the contents and click
SetCharacterProperty
it jumps to its position on the page, but when I click
View property
for example, it jumps to the top of the page. This happens with a lot of the new entries. As I said, it may be a quirk of the Linux program I'm using.
I just gave it a quick try and it worked fine -- probably some quirk of your Linux reader, as you say.
QuoteIf you intended to change them anyhow, I agree now would be the time to do so.
Well, I'm still unconvinced of the need. What do other people think; is it worth objectising the hotspot/region/etc functions? (eg. hotspot[3].Disable rather than DisableHotspot(3) ) or should they just be left alone?
QuoteOk, I didn't realize the function would have to be renamed. In that case it can probably wait.
Yeah, it's backwards compatibility -- if it wasn't renamed, and the engine was used to run an old (2.62) game, it would only push one argument to the function, and mess the stack up.
Quote
Well, I'm still unconvinced of the need. What do other people think; is it worth objectising the hotspot/region/etc functions? (eg. hotspot[3].Disable rather than DisableHotspot(3) ) or should they just be left alone?
I would be for it, especially if we would also be able to use script names/pointers as we are with objects, characters, and GUIs; i.e. hMySpot.Disable();. Seems like they should all work the same way.
Ok, beta 9 is now up. This completes float support by adding support for it to Display (in the form of %f), and adding the ArcCos/sin/tan and RaiseToPower functions.
If there's anything else that anyone is keen to have in terms of float support, now's the time to speak.
Beta 9 should also solve the stability issues that some people have been having with the editor -- two seperate crash bugs have been fixed, so if you get any crashes with beta 9 please let me know.
QuoteI would be for it, especially if we would also be able to use script names/pointers as we are with objects, characters, and GUIs; i.e. hMySpot.Disable();. Seems like they should all work the same way.
Yeah, it would be nice to have them all working like that. I propose to add hotspot and region objectisation for the next beta and then call it a day, again unless anyone has good reasoning to do anything else.
Quote* Added AGS_MAX_* constants to allow you to check the AGS limits in your script (see Constants section in the manual).
Cool, very helpful!
Won't you be able to use the constants yourself for the internal header? Should save you some work, too, no?
Quote* Fixed compiler crash if a single array or struct was bigger than 32KB.
Whee, my script now works like a charm. Thanks a lot, CJ! :)
Wow, the ability to finally display floats ! This was my most wanted feature to be implemented in AGS for a year now. With this, I should be able to properly finish my game. Thanks very much, CJ !
Okay, the only difficulty now though, is properly implementing this new feature. My scripting goal is to:
1) Add the floating numbers 12.50 and 1.10 together into one variable.
2) Use StrCopy to a copy the total float value to a string.
3) Display the floating number as a GUI Label.
However, my attempts at doing this seem to be unsuccessful as far. Would someone mind drawing out some simple code to demonstrate how this is done ? I noticed that the f% command needs to be present, but the proper usage is not yet documented.
An error also occurs when attempting to create a floating integer ? Is there another method to accomplish this ?
The goal though, one method or another, is to add two floats together
and display the total float value on a GUI label.
Any help would be most appreciated.
Thanks.
string buffer;
float first = 12.50;
float second = 1.10;
StrFormat(buffer, "%f", first + second);
lblLabelName.SetText(buffer);
where lblLabelName is the name of the GUI label
If you're having problems, please post the EXACT error message as well as the script code you're trying to use.
whine...
s3m still doesn't work. still can't release mie littl' game.
S3M works fine as far as I know ... can you upload an s3m file that doesn't play, if you're having problems.
Looks like the latest beta puts a few plugins out of business. :)
Won't be needing to use Maya again.
http://www.2dadventure.com/ags/s3mmusic.zip
I tried it on two computers. both didn't work (in ags, that is).
mod and xm works fine.
s3m stopped working around 2.60? I don't know...
jetxl: ok thanks, I'll look into it.
Anyway, here's a first draft of the Upgrading to Object Based Scripting guide:
http://www.adventuregamestudio.co.uk/manual/UpgradingTo27.htm
Basically, this will be aimed at people who are currently using 2.62 but haven't been looking at this beta thread. Let me know if there are any errors or omissions, or any further detail you think should be added.
I think a passage about enums and optional parameters would be nice.
Quote from: Pumaman link=topic=17697.msg225364#msg225364
QuoteOk, I didn't realize the function would have to be renamed. In that case it can probably wait.
Yeah, it's backwards compatibility -- if it wasn't renamed, and the engine was used to run an old (2.62) game, it would only push one argument to the function, and mess the stack up.
I just think PlaySoundEx isn't a terribly intuitive name. Seeing as we have a tracker entry about PlaySoundChannel (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=238) anyway, how about renaming PlaySoundEx to PlaySoundChannel and, since optional parameters are possible, be able to add the vol, x, y and loop parameters at a later time?
Or would that pose the same backwards compatibility problem?
An intro to pointers and how they work would also be nice.
HoN
PS (Hey, here's a neat side-benefit to using AGS. I've just started learning how to program in C++, and I'm already familiar with a lot of the conventions/syntax. Thanks, CJ!)
Quote
If there's anything else that anyone is keen to have in terms of float support, now's the time to speak.
Just did overflow and undeflow test. Both conditions handled perfectly, as far as I could tell. Nice work ;)
Quote
Yeah, it would be nice to have them all working like that. I propose to add hotspot and region objectisation for the next beta and then call it a day, again unless anyone has good reasoning to do anything else.
Great! I suppose you are leaving out Walkable and Walk Behind Areas because they have no interactions and so very few functions that do anyting with them? Future possibilites come to mind though, particularily with regard to Set/Get property type stuff (not the custom property thingy of course). Leaving this to the future, I think, works for most of us.
Oh, will regions be geting script-o names or how will they be handled?
Quote
Basically, this will be aimed at people who are currently using 2.62 but haven't been looking at this beta thread. Let me know if there are any errors or omissions, or any further detail you think should be added.
How about adding a section called GOTCHAS
New Keywords/Reserved WordsA number of new keywords have been added in this version of AGS. If any of these are used as variable, function, or parameter names in a game you are upgrading it is very likely you will get compile errors. Change your names to something else and recompile. Here is a list of keywords/reserved words
- object
- attribute
- etc
Using '==' with Floating Point Numbers
The likely hood of any two floating point numbers being exactly equal is extremely low. Comparing two floats using the '==' operator may not produce the results you expect. Try checking for a range instead.
QuoteI think a passage about enums and optional parameters would be nice.
Done.
QuoteI just think PlaySoundEx isn't a terribly intuitive name. Seeing as we have a tracker entry about PlaySoundChannel anyway, how about renaming PlaySoundEx to PlaySoundChannel and, since optional parameters are possible, be able to add the vol, x, y and loop parameters at a later time?
Or would that pose the same backwards compatibility problem?
I agree about PlaySoundEx being nasty ... in fact, I hate "Ex" naming. But, adding extra parameters later would pose the same compataibility problem.
However, in this case I'm really not convinced of the need for the (x,y) parameters, so how about:
PlaySoundChannel(sound, optional channel, optional loop, optional volume);
QuoteAn intro to pointers and how they work would also be nice.
Ok, well I've added a very brief paragraph explaining that pointers exist, but I don't want to confuse matters too much by talking about them at this stage. Perhaps a "Part 2: Advanced topics" page later on could cover them properly.
QuoteGreat! I suppose you are leaving out Walkable and Walk Behind Areas because they have no interactions and so very few functions that do anyting with them?
Yeah, they have so few functions I can't really justify the time and effort. It was a close call with Regions in that respect, but I've decided to do them anyway.
Quote
Oh, will regions be geting script-o names or how will they be handled?
No, I don't really think it's worth it. Hotspots will get an "hHotspot" name, but regions will not. You'll have to access them through:
region[3].LightLevel = 40;
or whatever.
QuoteNew Keywords/Reserved Words
A number of new keywords have been added in this version of AGS. If any of these are used as variable, function, or parameter names in a game you are upgrading it is very likely you will get compile errors.
Good point, added.
QuoteUsing '==' with Floating Point Numbers
The likely hood of any two floating point numbers being exactly equal is extremely low. Comparing two floats using the '==' operator may not produce the results you expect.
This is an interesting one. I was actually thinking about dealing with it by making the == operator return true for floats if the values were within 0.0001 of each other. Do you think this would be useful, or would this be annoying big brother interference when you did actually want to compare at a very fine accuracy?
Quote from: Pumaman on Tue 04/01/2005 19:21:21
This is an interesting one. I was actually thinking about dealing with it by making the == operator return true for floats if the values were within 0.0001 of each other. Do you think this would be useful, or would this be annoying big brother interference when you did actually want to compare at a very fine accuracy?
From a purist mathematical point of view, I would disagree with that. If two things aren't equal, then == isn't true for them. Plus there's the matter of exponents (according to your defintion, 1 ex -8 == 1 ex -10, since the difference is 99 ex -10, which is less than 1 ex -4).
Maybe you could create a shorthand function for (abs (float_a - float_b) < epsilon), though.
Quote from: Pumaman on Tue 04/01/2005 19:21:21
I agree about PlaySoundEx being nasty ... in fact, I hate "Ex" naming. But, adding extra parameters later would pose the same compataibility problem.
However, in this case I'm really not convinced of the need for the (x,y) parameters, so how about:
PlaySoundChannel(sound, optional channel, optional loop, optional volume);
Works for me.
However, I would prefer for "volume" to be the second parameter, so we need not specify a channel if we want to play a sound at a specified volume.
Because PlaySoundChannel(sound,,, 80); doesn't work, right?
Btw, would that volume affect the whole channel or only that sound?
I was thinking about how to implement "adjust volume with scaling" for frame sounds, so being able to play only the sound at the specified volume would make that possible.
Almost sounds like a suggestion...sorry. :P
QuoteFrom a purist mathematical point of view, I would disagree with that. If two things aren't equal, then == isn't true for them.
But on the other hand, they might well have been supposed to be equal, but the precision has been lost.
However, I do see what you're saying. Floats only have an accuracy of 6 digits; but because these 6 digits can "float" anywhere due to the exponent, just hardcoding something like "0.001" in wouldn't be fair on people trying to work with small numbers. Perhaps I'll just leave it and add a warning as Rick suggests.
Quote
However, I would prefer for "volume" to be the second parameter, so we need not specify a channel if we want to play a sound at a specified volume.
On the other hand, having to specify the volume would be annoying if you just wanted to loop the sound. Actually, thinking about it I can't see any ideal order for these parameters. Hmmm :P
Quote from: Jet X.L. on Mon 03/01/2005 20:43:18
http://www.2dadventure.com/ags/s3mmusic.zip
I tried it on two computers. both didn't work (in ags, that is).
I've just tried this out ... seems that the S3M player that AGS uses doesn't like these tracks. I've found an alternate player, but the problem is it doesn't support SeekMODPattern. How many people are using SeekMODPattern; what would opinions be like if it stopped working?
In my opinion SeekMODPattern can be quite useful for tracker musics, it's just common that a tracker music piece plays in on player and doesn't in another (that means if the player is changed it's also possible that it won't play some of the files the engine used to play anymore), so I vote for not changing it.
If there's a file which won't work, I'd recommend using another (in different format or some other composition, etc.).
Quote
This is an interesting one. I was actually thinking about dealing with it by making the == operator return true for floats if the values were within 0.0001 of each other. Do you think this would be useful, or would this be annoying big brother interference when you did actually want to compare at a very fine accuracy?
Instead of playing with the == operator, how about adding a floating point function to test if a value is in a specified range. It could return 1 if the value was within the range and 0 otherwise. If the "min" parameter is not specified then the range is +/- max. For example:
FloatInRange(float value, float max, optional float min); // For lack of a better name
float var;
if (FloatInRange(var, 10.1, -0.042)) { // Do something when 10.1 <= var <= -0.042
}
if (FloatInRange(var, 9.234)) { // Do something when 9.234 <= var <= -9.234
}
Interesting, but FloatInRange() can be just defined like:
function FloatInRange(float var,float min,float max) {
Ã, if ((var<=max)&&(var>=min)) return 1;
Ã, else return 0;
}
Well the max parameter is not optional here, but users can just custumize it according to their needs, like changing >= to >, etc. So I think it's not quite necessary to add this internally.
For the '== true for within certain range' part I'll say 'no', unless you can set the accuracy via some function/property/game variable/whatever, eg:
FloatSetCompareAccuracy(0.01); //so x==y will return true if |x-y|<0.01
as different people may need different accuracies.
Quote from: Pumaman on Tue 04/01/2005 19:52:21
Quote
However, I would prefer for "volume" to be the second parameter, so we need not specify a channel if we want to play a sound at a specified volume.
On the other hand, having to specify the volume would be annoying if you just wanted to loop the sound. Actually, thinking about it I can't see any ideal order for these parameters. Hmmm :P
Seeing as it would be called PlaySound
Channel, maybe the "channel" parameter shouldn't be optional, but passing -1 for example would choose a free channel like PlaySound.
Would it be too much trouble to implement the x and y parameters? I think it would be nice being able to pan the sound.
Quote from: Pumaman on Tue 04/01/2005 22:05:48
I've just tried this out ... seems that the S3M player that AGS uses doesn't like these tracks. I've found an alternate player, but the problem is it doesn't support SeekMODPattern. How many people are using SeekMODPattern; what would opinions be like if it stopped working?
In such case, instead of one music file, you could make two. Instead of jump to another pattern, you can just simply play the second music file.
Quote from: Gilbot V7000a on Wed 05/01/2005 01:33:13
In my opinion SeekMODPattern can be quite useful for tracker musics, it's just common that a tracker music piece plays in on player and doesn't in another (that means if the player is changed it's also possible that it won't play some of the files the engine used to play anymore), so I vote for not changing it.
If there's a file which won't work, I'd recommend using another (in different format or some other composition, etc.).
The weird thing is that a s3m file I used worked fine, then I stopped working on the game for a while (and downloaded other ags versions), but when I tested the game again, the music didn't work. Somewhere along, the s3m tracker in ags must has been changed?
s3m converters are rare, work in dos (not in xp. I hate xp), and will bring the quality down. I changed them to mp3, but then the game is more than 3 times bigger (making it hard to host it on my wbsite).
This the first time I made music, and it fits the atmosphere of the game perfect. I don't want to change a thing about it.
Another nice thing would be if the recompile all rooms dialog on loading an old game had 3 options instead of 2: OK, Load but dont recompile rooms and Cancel... that way you can use the latest editor to load an old game just to look at, without it forcing the old game into 2.7 ...
EDIT:
and are enums strictly type-checked? Can I use an enum value of one enumeration as a parameter to a function that has a different enumeration type? Can you set more that one identifier to the same value in the same enumeration, i.e.
enum verb { Take = 1, Pickup = 1, PickUp = 1, ...}
EDIT 2: MORE TECHIE QUESTIONS
Is it possible for a global function to take a pointer to a function as an argument, and then call the dereferenced pointer. Would this work if the function was a room specific function?
I am thinking to avoid using the interaction editor by having global functions called something like SetObjectCallback which run in the before_fadein of the room and set up a global array which the global script can use to find otu which function pointer to use for a given verb/object or verb/hotspot combination. Is this possible?
And can you have static protected functions?
And can you have static member variables, protected or otherwise?
Oh, and the manual doesn't mention that you can have a room-specific rep_ex_always function
QuoteIn my opinion SeekMODPattern can be quite useful for tracker musics, it's just common that a tracker music piece plays in on player and doesn't in another (that means if the player is changed it's also possible that it won't play some of the files the engine used to play anymore), so I vote for not changing it.
Thanks for your input on the MOD music issue, guys. However, we're in luck, as I've found an alternate mod player that supports MOD/XM/S3M/IT and also does support SeekMODPattern, so things are looking good. I'm currently giving it some testing, with a view to implementation in beta 10.
QuoteInstead of playing with the == operator, how about adding a floating point function to test if a value is in a specified range. It could return 1 if the value was within the range and 0 otherwise. If the "min" parameter is not specified then the range is +/- max. For example:
Good idea -- but then, as Gilbert says, it's so easy to implement yourself that I'm not sure a built-in function is necessary.
QuoteSeeing as it would be called PlaySoundChannel, maybe the "channel" parameter shouldn't be optional, but passing -1 for example would choose a free channel like PlaySound.
Would it be too much trouble to implement the x and y parameters? I think it would be nice being able to pan the sound.
Well, I was also thinking of renaming it to PlaySound
Effect; but I digress, let's leave this one for now ;)
QuoteAnother nice thing would be if the recompile all rooms dialog on loading an old game had 3 options instead of 2: OK, Load but dont recompile rooms and Cancel... that way you can use the latest editor to load an old game just to look at, without it forcing the old game into 2.7 ...
Sounds reasonable -- it is a bit drastic at the moment forcing you to recompile or quit, so I'll make the change.
Quoteand are enums strictly type-checked? Can I use an enum value of one enumeration as a parameter to a function that has a different enumeration type? Can you set more that one identifier to the same value in the same enumeration, i.e.
No. Yes. Yes.
Quote
Is it possible for a global function to take a pointer to a function as an argument, and then call the dereferenced pointer. Would this work if the function was a room specific function?
No; allowing function pointers throws up various problems and isn't something I'll be implementing for 2.7.
QuoteAnd can you have static protected functions?
Yes.
Quote
And can you have static member variables, protected or otherwise?
No.
QuoteOh, and the manual doesn't mention that you can have a room-specific rep_ex_always function
Actually it does, under "repeatedly_execute_always" in the Scripting event reference.
Quote
QuoteInstead of playing with the == operator, how about adding a floating point function to test if a value is in a specified range. It could return 1 if the value was within the range and 0 otherwise. If the "min" parameter is not specified then the range is +/- max. For example:
Good idea -- but then, as Gilbert says, it's so easy to implement yourself that I'm not sure a built-in function is necessary.
Yeah, I'm with Gilbert also. Probably a well placed sentence or two in the manual and upgrade instructions would suffice. I think you should mention it to illuminate confusion for the non-programmers amoung us.
Btw, are we able to create functions with optional parameters or is this restricted to built-ins?
Quote
Quoteand are enums strictly type-checked? Can I use an enum value of one enumeration as a parameter to a function that has a different enumeration type? Can you set more that one identifier to the same value in the same enumeration, i.e.
No. Yes. Yes.
The "No" answer is causing me a bit of confusion. Hmmm.... then are enum values unique across all enum types instead of being unique within each type? If the former is true (i.e. unique across all enum types) would that mean that two different enum types couldn't use the same value, for example is the following permitted?
enum ADEF {
eOtherthing,
eSomething
}
enum BDEF {
eThis,
eThat,
eOtherthing
}
Quote
Quote
And can you have static member variables, protected or otherwise?
No.
But you could make static variables in the global script and then use them for the same purpose; they just wouldn't be part of the struct.
I think I've found another bug while trying to make a keyboard-only-controlled GUI. When a GUI is opened, the Enter key by the number pad (keycode 13 just like the main one) does not trigger an IsKeyPressed(13), though it does when no GUI's are open.
Also, for the (sorta) new GUI objects, would it be possible to include their x and y as parameters? Such as gInventory.x and gInventory.y.
This could be handle for implementing, say, an inventory GUI that doesn't block the view of the character or that changes sides of the screen depending on where the character is.
Quote from: Pumaman on Wed 05/01/2005 20:32:16
QuoteAnd can you have static protected functions?
Yes.
What is the syntax? I have tried both:
import static protected function get_slots();
and
import protected static function get_slots();
in my struct and neither works: it says "protected not allowed in struct" which is a misleading message anyway!
I wanted protected static variable because I want the protection on the variable and encapsulation in a struct, but the struct is actually used in an array and I only want one copy of these variables:
#define SGS_SLOTS_ONSCREEN 9
enum sgs_saveload_t {
eNone, eSave, eLoad, eConfirm
};
sgs_saveload_t sgs_saveload; // I want this in the struct
int sgs_offset; // I want this in the struct
int sgs_selected_slot; // I want this in the struct
struct sgs {
char t[200]; // This is the string description of a save slot
int spr; // This is the sprite number of a save slot
// internal fns:
import static function get_slots();
import static function reget_slots();
import static function do_save();
import static function do_load();
import static function close();
import static function check_do_save();
import static function interface_click(int button);
import static function on_key_press(int keycode);
import static function repeatedly_execute();
// external fns
import static function Save();
import static function Load();
};
sgs sgs_struct[(SGS_SLOTS_ONSCREEN+1)];
oh, that last line doesn't work either. Despite 9+1 evaluating to a constant, AGS says that array bounds must be constant >:(
Anyway, is there another way to have my global variables inside the struct, protected? Can I nest structs?
struct sgs {
char t[200]; // This is the string description of a save slot
int spr; // This is the sprite number of a save slot
}
struct sgss {
static sgs slot[10];
static sgs_saveload_t saveload;
static int offset;
static int selected_slot;
// imports, etc...
}
Oh, and is it possible to automatically turn off the 8) smilie in the tech forums, as it seems to code up a lot when people post code
And another question: can multiple GUI controls be set up to access the same handler function? This would be quite handy. The "this" pointer would still be set differently for each call...
EDIT: I've tried this, and it seems that you can set the same function for multiple GUI controls, but (apart from the flipping global script opening every time you do it) the "this" pointer is not set at all! It would be nice if "this" was set for GUI handler functions.
And another enum question: I presume that enums start counting at 0 by default. Can you change this by doing:
enum mye {
one = 1, two, three, four };
and have two, three, four set to 2, 3, 4?
EDIT
BUG REPORT
When I try and edit the text of a new GUI label to be longer than 25 characters, it gets truncated to 25 chars. You have said elsewhere that the limit is 200 (and I've used longer labels myself before)
QuoteYeah, I'm with Gilbert also. Probably a well placed sentence or two in the manual and upgrade instructions would suffice. I think you should mention it to illuminate confusion for the non-programmers amoung us.
I'll mention it in the Data Types section of the manual.
QuoteBtw, are we able to create functions with optional parameters or is this restricted to built-ins?
Yes -- in the script header just do this:
import function MyFunc(int param=5);
that will set param as an optional parameter, with a default value of 5.
Note that optional parameters only with with int and enum parameters, you can't do it with strings or floats.
QuoteThe "No" answer is causing me a bit of confusion.
All it means is that enums work just like in C -- effectively the enum values are just #defines to their particular numbers. There's nothing to stop you passing an int to a function that expects an enum, and vice versa.
QuoteBut you could make static variables in the global script and then use them for the same purpose; they just wouldn't be part of the struct.
Yes, this is the workaround. Not very nice I know, but I did have a brief look at static member variables and it looked like it was going to be fairly hefty job to implement them.
QuoteI think I've found another bug while trying to make a keyboard-only-controlled GUI. When a GUI is opened, the Enter key by the number pad (keycode 13 just like the main one) does not trigger an IsKeyPressed(13), though it does when no GUI's are open
I just tried this but it worked fine for me. Do you mean IsKeyPressed, or do you mean on_mouse_click? If it's the latter, it won't get called if your GUI has a text box since it steals the keypress.
QuoteAlso, for the (sorta) new GUI objects, would it be possible to include their x and y as parameters? Such as gInventory.x and gInventory.y.
Sounds reasonable to me.
Quote
What is the syntax? I have tried both:
import static protected function get_slots();
It's
protected import static function get_slots();
just to keep you on your toes :P
Basically, to be consistent with Java/C#, the protection level always goes first.
Quoteoh, that last line doesn't work either. Despite 9+1 evaluating to a constant, AGS says that array bounds must be constant
This isn't trivial to fix due to the way the script compiler works, I'm afraid. The workaround is to #define another constant as one higher; not perfect by any means, I concede.
Quote
Anyway, is there another way to have my global variables inside the struct, protected? Can I nest structs?
Not at the moment, no.
QuoteEDIT: I've tried this, and it seems that you can set the same function for multiple GUI controls, but (apart from the flipping global script opening every time you do it) the "this" pointer is not set at all! It would be nice if "this" was set for GUI handler functions.
I agree, that would be nice. However, it's difficult to implement this way, I'll have a think about it.
QuoteAnd another enum question: I presume that enums start counting at 0 by default. Can you change this by doing:
enum mye {
one = 1, two, three, four };
and have two, three, four set to 2, 3, 4?
Yes.
QuoteWhen I try and edit the text of a new GUI label to be longer than 25 characters, it gets truncated to 25 chars. You have said elsewhere that the limit is 200 (and I've used longer labels myself before)
Well spotted, I'll fix it.
Quote from: Pumaman on Thu 06/01/2005 18:38:10
QuoteEDIT: I've tried this, and it seems that you can set the same function for multiple GUI controls, but (apart from the flipping global script opening every time you do it) the "this" pointer is not set at all! It would be nice if "this" was set for GUI handler functions.
I agree, that would be nice. However, it's difficult to implement this way, I'll have a think about it.
Well, it can be called something else, if that helps, like game.current_button_ptr or whatever...
Yeah, the main issue is how to ensure type safety. Would just having the GUIControl* pointer be enough, or would you want to access label/button/etc-specific methods on it?
Quote* Changed Character.AddInventory/LoseInventory to take the inventory item object rather than the number. For example:
player.AddInventory(iSmallKey);
You need to update the example script for InventoryItem.ID in the manual.
Edit:QuoteObject-ised GetHotspotAt/GetCharacterAt/GetObjectAt/GetRegionAt/GetInvAt to work like GetGUIAtLocation does.
Shouldn't we rename xxxAtLocation(int x, int y) to avoid confusion with future Locations (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=131)?
Also, GetCharacterAtScreen sounds more intuitive to me than GetCharacterAtLocation.
I think we should find a consistent terminology to differentiate functions expecting screen or room coordinates.
I propose:
GetLocationName -> GetNameAtScreen
GetLocationType -> GetTypeAtScreen
Mouse.SaveUntilLocationChange -> Mouse.SaveUntilTypeChange
Character.FaceLocation -> Character.FaceScreen
GetGUIAtLocation -> GetGUIAtScreen
GetGUIControlAtLocation -> GetGUIControlAtScreen
ListBox.GetItemAtLocation -> ListBox.GetItemAtScreen
GetCharacterAtLocation -> GetCharacterAtScreen
GetHotSpotAtLocation -> GetHotSpotAtScreen
GetInvAtLocation -> GetInvAtScreen
GetObjectAtLocation -> GetObjectAtScreen
GetWalkableAreaAt -> GetWalkableAreaAtScreen
GetRegionAtLocation -> GetRegionAtLocation or GetRegionAtPosition or GetRegionAtCoordinates
Or, if we'll call Locations "Markers" instead, we have:
GetLocationName -> GetNameAtLocation
GetLocationType -> GetTypeAtLocation
Mouse.SaveUntilLocationChange -> Mouse.SaveUntilTypeChange
GetRegionAtLocation -> GetRegionAtPosition or GetRegionAtCoordinates
GetWalkableAreaAt -> GetWalkableAreaAtLocation
Obviously less functions to rename, but, again, I think xxxAtScreen is much more intuitive.
Edit 2:Manual -> Tutorial -> Advanced room features -> Lighting effects:
"NOTE: Light levels affect characters only -
they do not affect objects" is obsolete.
Just discovered, seems that there're problem with eRoundNearest for FloatToInt() when the number is negative (don't know about the others);
Quick Test:
Display("%d %d", FloatToInt(2.0,eRoundNearest), FloatToInt(-2.0,eRoundNearest));
Displayed text will be:
2 -1
What?2?
EDIT:
By the way, there're some limit to how many optional parameters a function can take, right?
For example the following line generates an error of 'too many arguments' while breaking it up into two lines won't crash the game:
RawPrint(0, 0, "%d %d %d %d %d %d %d", 1, 2, 3, 4, 5, 6, 7);
YAY for the Room menu, at last we can edit the room script when in the areas screen, etc!
Quote from: Pumaman on Thu 06/01/2005 23:34:27
Yeah, the main issue is how to ensure type safety. Would just having the GUIControl* pointer be enough, or would you want to access label/button/etc-specific methods on it?
I'd want to run button-specific methods on it. Maybe if the handler functions can be declared with an argument, it would make the type clearer:
function myButtonHandler_Click (Button *this)...
Then when a user set a control to call a particular function, the editor could check if the function was already declared, and if it was, check that the type was the same...
Quote from: strazer on Fri 07/01/2005 01:10:08
Shouldn't we rename xxxAtLocation(int x, int y) to avoid confusion with future Locations (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=131)?
Also, GetCharacterAtScreen sounds more intuitive to me than GetCharacterAtLocation.
I think we should find a consistent terminology to differentiate functions expecting screen or room coordinates.
I think "GetxxxAtXY" or "GetxxxAtCoords" is meaningful and clearest
Quote from: Pumaman on Thu 06/01/2005 18:38:10
QuoteAlso, for the (sorta) new GUI objects, would it be possible to include their x and y as parameters? Such as gInventory.x and gInventory.y.
Sounds reasonable to me.
Would it be possible to have width and height in there too, for GUIs and controls, please?
Another idea: could the syntax highlighting of the editor make deprecated function names appear in a slightly different colour?
And typo in manual ref of IsGamePaused:
if (IsGamePaudsed() == 1) UnPauseGame();
QuoteI just tried this but it worked fine for me. Do you mean IsKeyPressed, or do you mean on_mouse_click? If it's the latter, it won't get called if your GUI has a text box since it steals the keypress.
I meant using IsKeyPressed inside the repeatedly_execute function.Ã, With IsKeyPressed (13) in the repeatedly_execute, it didn't pick up the Enter key by the numpad, but does read it from the main enter. The GUI's are set to Normal except for the one that manages the cursor on the screen (set to Popup Modal).
But, did that GUI contain a textbox (read Pumaman's post) ? I'm not sure, but I think in that case the textbox RULEZ and ate every ENTER key pressed, so it's not even detectable with IsKeyPressed().
Ummm, your earlier reply about enums was wrong, CJ. Enums default to start counting at 1, not 0!
Oh, and shouldn't SkipUntilCharacterStops be objectised?
Can we have an enum builtin for GetLocationType results?
Can the manual liust in one place the legal values for the different builtin enums?
Quote from: SSH on Fri 07/01/2005 14:55:26
Oh, and shouldn't SkipUntilCharacterStops be objectised?
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=17697.msg218483#msg218483
Quote from: Gilbot V7000a on Fri 07/01/2005 09:55:36
But, did that GUI contain a textbox (read Pumaman's post) ? I'm not sure, but I think in that case the textbox RULEZ and ate every ENTER key pressed, so it's not even detectable with IsKeyPressed().
Sorry, no, there are no textboxes. It's all labels and buttons.
QuoteYou need to update the example script for InventoryItem.ID in the manual.
The example there is using the obsolete AddInventory function, not the Character.AddInventory function. For obvious backwards compatibility reasons, I'm not changing the way the old-style AddInventory works.
QuoteShouldn't we rename xxxAtLocation(int x, int y) to avoid confusion with future Locations?
Also, GetCharacterAtScreen sounds more intuitive to me than GetCharacterAtLocation.
I think we should find a consistent terminology to differentiate functions expecting screen or room coordinates.
I agree. However, we can't just use "GetCharacterAt" because they're the old functions. Personally I don't like "AtScreen", because it doesn't really make any grammatical sense. "AtPositionOnScreen" perhaps, but then that's too long-winded.
How about "GetCharacterByPosition"?
QuoteManual -> Tutorial -> Advanced room features -> Lighting effects:
"NOTE: Light levels affect characters only - they do not affect objects" is obsolete.
Well spotted, thanks.
QuoteJust discovered, seems that there're problem with eRoundNearest for FloatToInt() when the number is negative (don't know about the others);
Good point, FloatToInt doesn't work properly with negative numbers. Well spotted, I'll get it fixed.
QuoteBy the way, there're some limit to how many optional parameters a function can take, right?
Yes, the script engine has a limit of 9 parameters in a function call. If this is too much of a problem, it can probably be increased.
QuoteI'd want to run button-specific methods on it. Maybe if the handler functions can be declared with an argument, it would make the type clearer:
function myButtonHandler_Click (Button *this)...
Yes, that was what I was thinking. The problem is how to stop you then assigning that function to a text box, for instance. I suppose the editor could do some sort of check, but it all starts to get rather involved.
QuoteI think "GetxxxAtXY" or "GetxxxAtCoords" is meaningful and clearest
'Coords' isn't a bad idea ... we should really have some way to distinguish GetRegionAt because it takes room co-ordinates, as strazer says. I'm not sure what would be best for that.
QuoteWould it be possible to have width and height in there too, for GUIs and controls, please?
I guess that would kinda go with X and Y, wouldn't it ;)
QuoteAnother idea: could the syntax highlighting of the editor make deprecated function names appear in a slightly different colour?
That's an interesting idea; it would probably involve more work than it'd be worth though. I'll think about it.
QuoteAnd typo in manual ref of IsGamePaused:
Thanks, fixed it.
QuoteIsKeyPressed (13) in the repeatedly_execute, it didn't pick up the Enter key by the numpad, but does read it from the main enter.
Ahh right; well spotted, IsKeyPressed doesn't work with the numeric keypad Enter key. I'll get it fixed.
QuoteUmmm, your earlier reply about enums was wrong, CJ. Enums default to start counting at 1, not 0!
What did I say? I can't remember! Stop confusing me! I'm just a poor old man in my rocking chair, I can't keep up with all you rowdy kids!
QuoteOh, and shouldn't SkipUntilCharacterStops be objectised?
Well, there is a wider issue of whether all functions that take a CHARID as a parameter should now take the actual character object instead; what do people think?
Quote
Can we have an enum builtin for GetLocationType results?
I suppose you can have that ;)
QuoteCan the manual liust in one place the legal values for the different builtin enums?
How do you mean? Like a Big List of All AGS Enums?
QuoteHow about "GetCharacterByPosition"?
Nah, that sounds like the Position refers to the character's position, not the screen position.
QuoteQuoteI think "GetxxxAtXY" or "GetxxxAtCoords" is meaningful and clearest
'Coords' isn't a bad idea ... we should really have some way to distinguish GetRegionAt because it takes room co-ordinates, as strazer says. I'm not sure what would be best for that.
But XY, Coords or even Position wouldn't be any different than Location. No indication of what kind of coordinates. How about AtScreenXY and AtRoomXY?
StrLen(ScreenXY) = StrLen(Location) ;)
Hmmm... a Big List of All Enums would be awesome. The addition of a Room Menu is handy as well. I agree with Strazer's latest idea on the naming conventions. OnScreenXY or AtScreenXY, along with AtRoomXY sounds clearest to me.
The internal FindGUIID function is included in the autocomplete pop-up.
So are
all member variables of GameState, unless that's intentional.
QuoteWell, there is a wider issue of whether all functions that take a CHARID as a parameter should now take the actual character object instead; what do people think?
Ah, now I get it. Sorry SSH, I thought you were talking about making the function a member of GameCharacter.
I'm for objectising.
Quote
How about AtScreenXY and AtRoomXY?
If Room and Screen were objectized then you would have:
Screen.GetNameAt(), Room.GetNameAt()
and if we are not in the mood to do anymore objectizing then we could at least fake it like so...
ScreenGetNameAt(), RoomGetNameAt()
I was going to stay out of this one but couldn't help myself :=
CJ, if you just implemented overloading (and why not polymorphism while you're at it) then you wouldn't have this problem :=
Could you consider an inv[] array, similar to gui[], character[] and object[]?
QuoteBut XY, Coords or even Position wouldn't be any different than Location. No indication of what kind of coordinates. How about AtScreenXY and AtRoomXY?
StrLen(ScreenXY) = StrLen(Location)
Ok, yeah .. GetHotspotAtScreenXY() doesn't sound too bad.
QuoteHmmm... a Big List of All Enums would be awesome.
Ok, I'll see what I can do.
QuoteThe internal FindGUIID function is included in the autocomplete pop-up.
Well spotted, I'll remove it.
Quote
So are all member variables of GameState, unless that's intentional.
Well, I'm not sure about this one. It is kinda handy to have them all there, but then some aren't supposed to be fiddled with. It really needs a proper review.
QuoteIf Room and Screen were objectized then you would have:
Screen.GetNameAt(), Room.GetNameAt()
That's not a bad idea, actually. Although it would mean that I'd have to properly object-ise both to stop it looking odd, and there are quite a lot of screen and room functions :P
QuoteCJ, if you just implemented overloading (and why not polymorphism while you're at it) then you wouldn't have this problem
Quiet, you :P
QuoteCould you consider an inv[] array, similar to gui[], character[] and object[]?
Beta 10 has an inventory[] array.
Oh, sorry. Since I didn't see it listed, I didn't know it was there.
Ok, beta 11 is now up. This includes global pointers and object pathing, so testing would be appreciated as there's quite a bit of new code in there any I don't guarantee it all works perfectly!
Quote* Object-ised Overlay functions now that global pointers are supported.
How do we use the return value of Character.SayBackground now?
Quote* Added "Built in enumerated types" page to the manual, listing all the built-in enums.
Shouldn't this be under "Reference"?
Quote from: Pumaman on Fri 07/01/2005 20:28:51
Good point, FloatToInt doesn't work properly with negative numbers. Well spotted, I'll get it fixed.
Great :D
Quote
Yes, the script engine has a limit of 9 parameters in a function call. If this is too much of a problem, it can probably be increased.
That's okay, I think it's not that common to call a function with > 9 parameters anyway, and there're always workaround when you need them (which rarely happened).
I asked about these two things because I mucked up a small test (http://www.2dadventure.com/ags/agsclocksrc1.zip) for the engine, which looks better compiled with beta11 now (because of the rounding fix, some of the stuff were off by 1 pixel with beta10), and the line of text on the top if I put everything into one RawPrint() call it would crash (because of more than 9 parameters) so I had to split it into two calls.
Quote from: Pumaman on Sat 13/11/2004 21:02:00
Changes from Beta 10 to Beta 11:
* Added support for global pointers in script, so that you can declare a global variable as a pointer. But, consequently:
* SaveGameSlot/SaveGameDialog are now delayed-response functions, just like the RestoreGame ones. This means the game won't actually be saved until the script function finishes.
NOOOOO!
This means, then, If I want to use the savegameslot function to save a temporary copy of the current game, then load it back in to get the screenshot, I have to stop the script and set a flag in rep_ex to pick up again on the next game cycle? Euugh!
Poor CJ, work as you might we are never happy... but I'm not sure which I'd rather, either. Gloval Pointers VS delayed SaveGameSlot... that's a hard one.
While we're moaning, as ever, its a real pain that all the old function help is gone from the manual when yuo are converting the scripts... maybe 2.7 can have both in, as lots of people will be converting scripts...? As it is I have to have two help files open at once, And I keep getting the wrong one, as they look the same on the taskbar... failing having the old functions in the helpfile you couldn't add the version number to the helpfile's taskbar text could you?
And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...
Quote
And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...
SSH, I shall also sin for we share the same desires ... :=
Quote from: RickJ on Mon 10/01/2005 15:04:07
Quote
And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...
SSH, I shall also sin for we share the same desires ... :=
So it was
you in the Blue Oyster the other night? :=
Two issues.
1) object[1].Animate(0, 4, eRepeat);
The previous line of code, which was mighty handy in Player Enters Screen BEFORE Fadein for those objects that were ALWAYS animating even before the room was loaded, and which USED to work, now gives the following error message -
Quote
---------------------------
Adventure Game Studio
---------------------------
An error has occured. Please contact the game author for support, as this
is likely to be a scripting error and not a bug in AGS.
(ACI version 2.70.827)
(Room 0 script line 10)
Error: A text script run in the Player Enters Screen event caused the
screen to be updated. If you need to use Wait(), do so in After Fadein
2) object[3].Move(282, 89, eNoBlock, eAnywhere);
You'll notice I forgot one parameter, between 89 and eNoBlock - SPEED. This error was NOT detected upon compiling, but while I was playing the game aborted with a message saying that the value for BLOCKING was invalid. Shouldn't this have been detected upon compiling?
QuoteHow do we use the return value of Character.SayBackground now?
Yeah I was thinking about that one, I guess it needs to return an Overlay* as well.
QuoteShouldn't this be under "Reference"?
I suppose it could be :P
QuoteI asked about these two things because I mucked up a small test for the engine, which looks better compiled with beta11 now
Hehe, hey that's really cool. Nice work ;)
QuoteThis means, then, If I want to use the savegameslot function to save a temporary copy of the current game, then load it back in to get the screenshot, I have to stop the script and set a flag in rep_ex to pick up again on the next game cycle? Euugh!
Unfortunately it's simply not possible to support both global pointers and a blocking SaveGameSlot. This is because if the game was saved at that time, the reference counts for any objects used within the script function would be saved incorrectly.
However, it seems like what you're trying to do with it is rather hacky. Surely the best solution all round would be some sort of new CreateScreenShotSprite command so that you can get the current image without having to save-load it?
QuotePoor CJ, work as you might we are never happy
Oh don't worry, it's the nature of software development; whatever you do, your 'customers' are never happy ;)
QuoteWhile we're moaning, as ever, its a real pain that all the old function help is gone from the manual when yuo are converting the scripts... maybe 2.7 can have both in, as lots of people will be converting scripts...?
Sorry about that; but I can't realistically add them all back in again.
Quotefailing having the old functions in the helpfile you couldn't add the version number to the helpfile's taskbar text could you?
I'm sure I can manage that. :)
QuoteAnd I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...
That's a possibility for a future version. Not 2.7 though, there's just too much else to do :P
Quote
1) object[1].Animate(0, 4, eRepeat);
The previous line of code, which was mighty handy in Player Enters Screen BEFORE Fadein for those objects that were ALWAYS animating even before the room was loaded, and which USED to work, now gives the following error message
That's because it's now blocking by default.
Quote2) object[3].Move(282, 89, eNoBlock, eAnywhere);
You'll notice I forgot one parameter, between 89 and eNoBlock - SPEED. This error was NOT detected upon compiling, but while I was playing the game aborted with a message saying that the value for BLOCKING was invalid. Shouldn't this have been detected upon compiling?
No, enums are not strictly type checked. This is because people still wanted to be able to use 0 and 1 as the enum values. At least it is now caught as an error at run-time, which is more than 2.62 managed ;)
1 - Oh? Blocking by default? Ok. I'll have to remember that. Heh, probably I'll have to hammer it in my head. :P
2 - I'll shut up then, because I also still want to use 0 and 1. ::) So feel free to forget about it.
Quote* Added support for global pointers in script, so that you can declare a global variable as a pointer.
* Added pathing support to script, so you can doÃ, lstList.OwningGUI.IDÃ, orÃ, gui[3].Controls[2].AsListBox.AddItem();Ã, and so on.
* Object-ised hotspots, regions and inventory items. Added script names for hotspots and inv items.
* Added gui[] array to access guis, similar to character[] and object[] arrays.
* Pointers can now be compared to each other and to base classes, so GetGUIAtLocation/GetControlAtLocation are now easier to use.
Thanks CJ, for all the hard work and efforts you put into making this new object-oriented scripting approach become more and more user-friendly and intuitive!
Quote from: Pumaman on Thu 23/12/2004 22:58:26
Quote
Can I make a struct member variable that can be written only by functions of the struct but can be read directly by all other functions?
Do I really need to make Getxxx functions for every variable?
Interesting idea, I'll certainly consider it. Can you think of a snappy keyword to represent this?
readonlyexternal comes to mind, but that's a bit unwieldy.
I think Strazer's "writeprotected" seems fine - it still tells that a member variable is protected but also specifies the actual level of protection. I'm not sure whether it should be "writeprotected", "protectedw", or maybe even "protected write" / "write protected" (two words) but I feel like the "protected" part should be there. :)
Quote from: Pumaman on Fri 24/12/2004 15:17:13I really don't want to rename the old objects to something else -- that would cause no end of confusion. We do need some way to make it distinct -- perhaps have another word (totally unlike "object") for the script OO objects.
So, what if, as Snarky mentioned, they'd be refered to as instances of struct? I see, it may seem confusing to some people at first but on the other hand it's both completely distinct from "object" and, indeed, a word that's used in OO terminology?
But I also see benefits in what Rick suggested, i.e. struct is a type and structure is an instance of struct.
Quote from: PumamanWell, there is a wider issue of whether all functions that take a CHARID as a parameter should now take the actual character object instead; what do people think?
Yeah, this seems very reasonable to me since, for instance, character.FollowCharacter() could accept character's pointer name rather than id. It would also be wonderful if the editor listed all character names once an opening bracket (comma) is typed.
By the way, I think it worth mentioning somewhere in the manual all the
managed types so that people could write thier own functions having pointers of these types as parameters:
function SomeFunction(GameCharacter *pointer) {...}
Quote from: Pumaman on Mon 10/01/2005 19:40:07
Surely the best solution all round would be some sort of new CreateScreenShotSprite command so that you can get the current image without having to save-load it?
Heh reading this I was suddenly inspired of some feature additions, but since this is the beta thread and I don't think that should be made into this release I posted that in the suggestions thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=18554.msg227248#msg227248) instead.
There seems to be a problem with objectised hotspots, or something. "null" as a value in GetHotspotAtLocation(mouse.x,mouse.y)!=null doesn't have good results - matter of fact, I think it screws up... and "0" isn't recognized by the engine, saying it can't change "int" to "*hotspot", or something.
Try it yourself - paste this in repeatedly_execute
if (GetHotspotAtLocation(mouse.x,mouse.y)!=null) mouse.Mode=2;
else mouse.Mode=0;
For it, it was always stuck on mode 2. The manual says that this function returns 0 instead of null (unlike the others; VERY strange). But
if (GetHotspotAtLocation(mouse.x,mouse.y)!=0) mouse.Mode=2;
else mouse.Mode=0;
says
---------------------------
Compile Error
---------------------------
There was an error compiling your script. The problem was:
In: 'Room script'
Error (line 7): Type mismatch: cannot convert 'Hotspot*' to 'int'
Do you want to fix the script now? (Your room has not been saved).
---------------------------
Sim Não
---------------------------
And I got the same result whether "Enforce Object-Based Scripting" was on or off.
QuoteThanks CJ, for all the hard work and efforts you put into making this new object-oriented scripting approach become more and more user-friendly and intuitive!
No problemo!
QuoteI think Strazer's "writeprotected" seems fine - it still tells that a member variable is protected but also specifies the actual level of protection.
Yeah, I rather like "writeprotected" too; it neatly sums up what it does.
QuoteSo, what if, as Snarky mentioned, they'd be refered to as instances of struct?
Indeed - or even perhaps just as "instances" rather than "objects"?
QuoteYeah, this seems very reasonable to me since, for instance, character.FollowCharacter() could accept character's pointer name rather than id. It would also be wonderful if the editor listed all character names once an opening bracket (comma) is typed.
Yeah that would be neat if autocomplete did that, I'll look into it.
Quote
By the way, I think it worth mentioning somewhere in the manual all the managed types so that people could write thier own functions having pointers of these types as parameters:
function SomeFunction(GameCharacter *pointer) {...}
Good point. I think that really, I need to write an Introduction to Pointers manual page, since a fair few commands return them now, so it's probably time to make sure people know what they are.
QuoteHeh reading this I was suddenly inspired of some feature additions, but since this is the beta thread and I don't think that should be made into this release I posted that in the suggestions thread instead.
Interesting idea you posted, I'll bear it in mind :)
QuoteThere seems to be a problem with objectised hotspots, or something. "null" as a value in GetHotspotAtLocation(mouse.x,mouse.y)!=null doesn't have good results - matter of fact, I think it screws up... and "0" isn't recognized by the engine, saying it can't change "int" to "*hotspot", or something.
The manual says that
hotspot 0 is returned, not 0. So you'd do:
if (GetHotspotAtLocation(mouse.x,mouse.y) != hotspot[0])
however you raise a good point. The wording in the manual could be better, so I'll update it to clarify matters. The reason for it not returning null is because Hotspot 0 is still considered a hotspot, and it's possible for it to have interactions,etc.
Oh, ok. Bugger, these things will take some time to adjust to... I apologise in advance for any more silly posts in the future.
Please do continue to point things out if they aren't immediately obvious. Remember, in a couple of months time we'll have a load of people upgrading from 2.62 and the less confusion and questions they have, the better; so let's get it all clarified properly while we can :)
I've noticed that if you tick the "Hide player character" checkbox for a room, you can't make an NPC in that room follow another NPC in that room.
There's no error message, the NPC just doesn't move.
Quote from: Pumaman on Tue 11/01/2005 20:31:27QuoteSo, what if, as Snarky mentioned, they'd be refered to as instances of struct?
Indeed - or even perhaps just as "instances" rather than "objects"?
Yeah, seems fine.
I have another idea -- it's kind of a suggestion but I believe it would be very handy with OO scripting.
What if the script editor would bring autocomplete list on pressing Ctrl-Space (or whatever). Currently, we have to type at least three characters for it to pop up but in certain cases it may be very useful for it to pop up on less then three. For example, we now have character o-names, all have a 'c' prefix. But without some tricky o-names it isn't possible to view all of them. With 'Ctrl-Space' thingy we could just type 'c' and call autocomplite list to see all related names. The same goes to objects, guis, inventory items, etc. Or maybe one wants to see a list of all enumerated constants -- type 'e' and Ctrl - Space. ?
QuoteI've noticed that if you tick the "Hide player character" checkbox for a room, you can't make an NPC in that room follow another NPC in that room.
well spotted, I'll fix it
QuoteWhat if the script editor would bring autocomplete list on pressing Ctrl-Space (or whatever).
Sounds reasonable, I'll look into it.
I've noticed some inconsistency in the way object and character views are set as follows:
- Character walking/normal view is set using ChangeView function (i.e. cEgo.ChangeView(7)).
- Other character views are set using properties (i.e. cEgo.ThinkView = 7)).
- Object views are set using SetView function (oDoor.SetView(14)).
I know this was discussed before but I don't recall if we did a consistency check, so please take these questions/comments as an exercise in review.
1. Would it not be more consistent to make the View property writable? This would make the ChangeView function redundant but it would make the walking or normal view work the same as the other views for character.
2. Shouldn't objects also have a view property the same as characters?
3. The object SetView function has optional parameters that allow the loop and frame to be set. If the character View property were made writable then couldn't the ChangeView function be made to work the same as the object SetView function and couldn't both functions then have the same name?
I believe some folks have used characters as substitutes or supplements to room objects on ocassion and it would seem that keeping some consistentcy would be helpful (so as long as it is practical). If this has already been discussed and well considered then just ignore the above and forgive me for missing out on the discussion.
[edit]
I just installed Beta11. The Room menu is very nice but I sorely miss the room editor toolbar, especially the interaction editor and script editor buttons. I know there are keyboard shortcuts for these two functions but is there any chance they can be added back. Old habits die hard you know. Btw, plain grey buttons would be fine with me as well.
I don't know, but this inconstency thing didn't annoy me.
I think one reason for using a function to change the character's view is because it's for changing the currently displayed view he's using (while for the other talk/think/whatever views, it's usually safe to change them by directly changing the appropiate variables), using a function can ensure proper checking and that the graphics is updated accordingly at the same time (if this is changed to a variable instead, the engine might need to either check for the changes in the variables every gameloops, or should be smart enough to act immediately whenever such a variable is changed).
OOps, stupid question deleted!
Anyway: would it be possible to have pathing from the GetAtLocation (or whatever they end up being called) functions. i.e.
if (type == 1) default_verb = HSActions[GetHotspotAtLocation(mouse.x, mouse.y).ID];
Would that mean it might have to be something like:
hotspot.GetAtScreenXY(mouse.x, mouse.y).ID;
actually, this might be a nice solution to the naming problem, if the GetAt functions were static functions of the arrays...
Quote
I don't know, but this inconstency thing didn't annoy me.
That's fine, I'm not really annoyed either because I am aware of the differences and am capable of dealing with them. On the other hand we have been kindly asked to review and comment on V2.7 before everything is cast in stone and difficult to change. If the "inconsistencies" I have noted are intentional then fine I have no problem with that, if not then I thought someone may appreciate them being pointed out.
Quote
I think one reason for using a function to change the character's view is because
it's for changing the currently displayed view ...
It is my understanding that setting properties of native objects does in fact invoke handler functions. Clearly if there were a problem setting a view property while the view is in use then the problem would eventually occur regardless of how infrequently the view was used or changed.
Quote from: SSH on Thu 13/01/2005 10:24:00
I'm a little unsure as to string handling now (and in the past, too). For example:
SSH, I think you would do it like this:
string name;
InventoryItem *ii = GetInvAtLocation (mouse.x, mouse.y);
if (ii != null) ii.GetName(name));
else StrCopy (name, "");
Probably you have ben spending too much time at the Blue Oyster ;)
Damn you Rick for replying before I could edit away my silliness! And I thoguht we had something special!
And you double-posted to do it, too!
Oh, and just to stay on-topic. CJ, you didn't include the mouse mode enumeration in your big list.... ah, because it is define dby cursor names. Maybe you can explain the naming convention for these generated enums in that section, too?
More:
How about a way to avoid opening the script editor when you set a GUI control's script function? Either a third button on the popup window so "OK - Edit script", "OK - No edit" and "Cancel". Or maybe a preference setting in the AGS Editor in general
Also nice would be a shortcut key in the editor for "Save and Exit". Ctrl-S would be fine!
Also, shouldn't interface_click take pointers now instead of numbers?
Quote
And I thoguht we had something special!
I you didn't care ... you wouldn't be so hard on me ::)
Earlier it was said that we can have protected static functions, but I can't seem to get them to work: they parse OK, but then it says that I'm not allowed to call one from another. Here's my declaration:
Also, I can't seem to access protected variables from inside my static functions.
struct sgs {
char t[200]; // This is the string description of a save slot
int spr; // This is the sprite number of a save slot
// internal fns:
protected import static function get_slots();
protected import static function reget_slots();
protected import static function do_save();
protected import static function do_load();
protected import static function close();
protected import static function check_do_save();
protected import static function on_key_press(int keycode);
protected import static function repeatedly_execute();
protected import static function setup_gui();
// external fns
import static function Save();
import static function Load();
};
sgs sgs_struct[10];
Is this becuase it is used in an array? Should that work?
Quote1.Ã, Would it not be more consistent to make the View property writable?Ã, This would make the ChangeView function redundant but it would make the walking or normal view work the same as the other views for character.
The reason for this difference is because the View property represents the
current view, ie. if LockView has been used, View will return that.
On the other hand, ChangeView deals with the 'normal' walking view for the character. Therefore, it's possible that the following code:
player.ChangeView(5);
Display("%d", player.View);
wouldn't return 5, if the view was currently locked to something else. Hence, having it as a writable property would be uninituitive and confusing.
Quote2.Ã, Shouldn't objects also have a view property the same as characters?Ã,Â
Good point, I'll add that.
Quote3.Ã, The object SetView function has optional parameters that allow the loop and frame to be set.Ã, Ã, If the character View property were made writable then couldn't the ChangeView function be made to work the same as the object SetView function and couldn't both functions then have the same name?Ã, Ã,Â
I wanted to have different names to differentiate the way the views work. A character
always has to have a current view, whereas an object does not (it might just have a sprite number instead).
Also, because LockView used to be called SetCharacterView, I thought that calling it SetView on the character would confuse people.
QuoteThe Room menu is very nice but I sorely miss the room editor toolbar, especially the interaction editor and script editor buttons.
The Save, Edit Script, Edit Interaction and Edit Messages buttons are returning for the next beta.
QuoteAnyway: would it be possible to have pathing from the GetAtLocation (or whatever they end up being called) functions. i.e.
It'd probably be possible; the reason I'm not too enthusiastic to add it is that generally the Get* functions can return null, and people trying to path with it would be dangerous. This doesn't apply to hotspots and regions, of course.
Quotehotspot.GetAtScreenXY(mouse.x,Ã, mouse.y).ID;
actually, this might be a nice solution to the naming problem, if the GetAt functions were static functions of the arrays...
That's actually a very good idea, I'll do that.
QuoteThat's fine, I'm not really annoyed either because I am aware of the differences and am capable of dealing with them.Ã, On the other hand we have been kindly asked to review and comment on V2.7 before everything is cast in stone and difficult to change.Ã,Â
Yes, please do continue to review things like this. If you disagree with my reasoning above for leaving things as they are, feel free to say so.
Quoteyou didn't include the mouse mode enumeration in your big list.... ah, because it is define dby cursor names. Maybe you can explain the naming convention for these generated enums in that section, too?
Good point, I'll add it.
QuoteHow about a way to avoid opening the script editor when you set a GUI control's script function? Either a third button on the popup window so "OK - Edit script", "OK - No edit" and "Cancel". Or maybe a preference setting in the AGS Editor in general
Yeah I know, I don't like the way this works at the moment -- it was very much put in as a 'quick hack' to allow you to get at the functionality (in case you hadn't guessed, I hate coding user interface stuff ;) ).
QuoteAlso, shouldn't interface_click take pointers now instead of numbers?
Well, interface_click is obsoleted now by the individual control handler functions, so I'm not planning to update it.
QuoteEarlier it was said that we can have protected static functions, but I can't seem to get them to work: they parse OK, but then it says that I'm not allowed to call one from another. Here's my declaration:
Good point, that won't work. Because the static functions don't have a this pointer, they are denied access to the protected members. I'm not sure of a clean way to fix this.
Quote
Also, I can't seem to access protected variables from inside my static functions.
Non-static variables cannot be accessed from static functions -- it doesn't make sense (there's no way of knowing which instance of the struct to access).
Small bug - sometimes the window holding GUI properties disappears, I have to restart AGS to get it back. I have been unable to see WHEN this happens, but I think it has to do with resizing - maybe even the change of resolution involved upon using "Test game". Maybe the window just moves offscreen, but in any case it's lost until AGS is restarted.
Quote
Yes, please do continue to review things like this. If you disagree with my reasoning above for leaving things as they are, feel free to say so.
Thanks for your confidence. Regrading Character/Object differences your explanation sounds reasonable to me. I think it's one of those things where there just isn't any one right way of doing things.
For what it's worth, in my world view objects and characters are pretty much the same thing. One has global scope and the other has scope within a specific room. I suspect that other people have other points of view. ;) It seems to me that the new OO script language, at some future point, could take advantage of these similarities by having each inheirit functionality from a common parent, etc, etc... Ok, I'm getting way beyond the scope of this thread, so I'll leave this discussion for another day. Well it's food for thought anyway (or at least junk food).
:= Cheers
Indeed, if I'm writing code for a character who only appears in one room, why does it need to go in the global script? But then, I may have a solution for that... ;)
Come to that, maybe Objects, Characters and Hotspot shoudl all be extensions of some base type, so we could do:
Thing *thingy =GetThingAtLocation(mouse.x, mouse.y);
if (thingy == null) {
// do something here
} else if (thingy.IsObject()) {
thingy.AsObject.SomeFunction();
} etc...
Also, it would be nice if there was a way for a script to call a GUI control's handler function:
gui[X].Controls[Y].AsButton.CallHandler(eMouseLeft);
QuoteSmall bug - sometimes the window holding GUI properties disappears, I have to restart AGS to get it back. I have been unable to see WHEN this happens, but I think it has to do with resizing - maybe even the change of resolution involved upon using "Test game". Maybe the window just moves offscreen, but in any case it's lost until AGS is restarted.
Strange, I haven't seen that myself. I'll bear it in mind but it doesn't sound too serious so I'm not going to thoroughly investigate it.
QuoteFor what it's worth, in my world view objects and characters are pretty much the same thing. One has global scope and the other has scope within a specific room.
In a sense, that's true. Perhaps they should both inherit from some sort of "actor" class. But on the other hand, I think the implementation details are just too different to make it work intuitively if that was the case.
QuoteCome to that, maybe Objects, Characters and Hotspot shoudl all be extensions of some base type, so we could do:
Thing *thingy =GetThingAtLocation(mouse.x, mouse.y);
if (thingy == null) {
// do something here
} else if (thingy.IsObject()) {
thingy.AsObject.SomeFunction();
} etc...
Interesting idea; that's something that could be added at a later date without causing disruption, so we'll leave it for now.
QuoteAlso, it would be nice if there was a way for a script to call a GUI control's handler function:
gui[X].Controls[Y].AsButton.CallHandler(eMouseLeft);
Yeah, I'm still not sure how to deal with the GUI button handlers. One thought I had was that each control type would have its own handler, so you'd script:
function Button::OnClick(MouseButton) {
}
that way, you'd have the "this" pointer to identify the object, but on the other hand you'd have to stick all the code for all the buttons in there, so it wouldn't be much better than the one big interface_click.
On the other hand, now that we have the AsButton, AsListBox, etc it would be viable to just pass a GUIControl* into the handlers as a parameter, and not have to worry about the editor checking the types or anything.
Anyway, beta 12 is now up. This tidies up various things -- notable the custom inventory, which works much better and more intuitively than it used to.
Note that it *should* be backwards compatible, but I'd appreciate it if people would just have a quick check to make sure it still does work. Basically, if you change the "game.top_inv_item" variable then it switches into Compatibility Mode and all the inventory windows redirect themselves to look at the old-style game.num_inv_items style variables.
I was wondering what would be the best approach to allow a smoother transition to future seperation of LEC and Sierra speech views (see Tracker (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=154)).
Currently, the Character.SpeechView property applies to both, so renaming it is not an option...
QuoteNote that it *should* be backwards compatible, but I'd appreciate it if people would just have a quick check to make sure it still does work.
Works fine here.
I've only noticed that the Item width & height properties override the old SetInvDimensions function, it has no effect. To preserve compatibility with old scripts, I think the function should have priority.
Quote* Renamed structs from GameCharacter and GameObject to Character and Object respectively, to make it more intuitive.
Good call. The Character.GetAtScreenXY in the manual still refers to "GameCharacter" though.
Quote* (...) each inv window can display inventory for a specific character (...)
This should make a lot of people happy. Great job, CJ!
Edit:
Oh, and may I re-suggest to rename
GetLocationName -> GetNameAtScreenXY
GetLocationType -> GetTypeAtScreenXY
Mouse.SaveUntilLocationChange -> Mouse.SaveCursorUntilChange
as I think they're slightly confusing.
Edit 2:
Shouldn't we obsolete the GetPlayerCharacter function since we now can simply use player.ID?
Edit 3:
How about
SetAreaScaling -> SetWalkableAreaScaling
?
Quote from: strazer on Sat 15/01/2005 19:35:33
I was wondering what would be the best approach to allow a smoother transition to future seperation of LEC and Sierra speech views (see Tracker (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=154)).
Currently, the Character.SpeechView property applies to both, so renaming it is not an option...
Interesting point. I suppose it could be changed to two seperate properties SierraSpeechView and LECSpeechView or something. As we're still in beta, it's viable to scrap the current SpeechView property and replace it with those two; but on the other hand people wouldn't be able to easily switch between speech styles if they had to set seperate properties.
QuoteI've only noticed that the Item width & height properties override the old SetInvDimensions function, it has no effect. To preserve compatibility with old scripts, I think the function should have priority.
SetInvDimensions is supposed to override all ItemWidth and ItemHeight properties of inv windows for backwards compatibility; does that not seem to be working at present?
QuoteThe Character.GetAtScreenXY in the manual still refers to "GameCharacter" though.
Well spotted, I'll fix it.
Quote
This should make a lot of people happy. Great job, CJ!
Hopefully, yes ;) It's one of those funny ones where the main thing holding me back from implementing it was a clean way of doing it; the new OO system provided the perfect opportunity ;)
QuoteOh, and may I re-suggest to rename
GetLocationName -> GetNameAtScreenXY
GetLocationType -> GetTypeAtScreenXY
SetAreaScaling -> SetWalkableAreaScaling
Although I do agree in principle, I'd rather not rename functions if they haven't actually changed. In 2.7, a lot of things have new names from 2.62 because of changed functionality; and I'd rather not confuse people by renaming a few functions where they actually do the same thing.
Quote
Mouse.SaveUntilLocationChange -> Mouse.SaveCursorUntilChange
I agree with renaming this, but finding a good name for it seems to be impossible. "SaveCursorUntilChange" implies that it waits for the cursor to change, but that's not the case. Anyone got any bright ideas?
QuoteShouldn't we obsolete the GetPlayerCharacter function since we now can simply use player.ID?
Good point, will do.
Quote from: Pumaman on Sat 15/01/2005 21:40:57SetInvDimensions is supposed to override all ItemWidth and ItemHeight properties of inv windows for backwards compatibility; does that not seem to be working at present?
It didn't work for me. I loaded my v2.62 game up, changed a few local variable names (gui, object and so on), then tested it. The inventory items didn't show up (as they used to).
I resized the inventory control to the default dimensions set in the properties window, then they showed up.
I had used SetInvDimensions in game_start.
Quote from: Pumaman on Sat 15/01/2005 21:40:57Although I do agree in principle, I'd rather not rename functions if they haven't actually changed. In 2.7, a lot of things have new names from 2.62 because of changed functionality; and I'd rather not confuse people by renaming a few functions where they actually do the same thing.
Ah, ok. I'll shut up then. ;)
Quote from: Pumaman on Sat 15/01/2005 21:40:57I agree with renaming this, but finding a good name for it seems to be impossible.
I know what you mean... :P
Another thing: Is InventoryItem.RunInteraction still a delayed function? If so, it should be noted in the manual.
Greet job indeed!
Quote* Ctrl+Space now allows you to pop up the autocomplete list at any time, like in Visual Studio.
Sweet!
May I, however, suggest one more thingy about the autocomplete list? :)
All the names in autocomplete are alphabetically sorted (and that's cool I think, because we can for example group the related properties, variables and functions together by adding a lowercase prefix). But would it be possible to make sorting case-sensitive so that instead of:
cEgo
CentreGUI
ChangeCharacterView
cHero
ClaimEvent
cMan
there would be:
cEgo
cHero
cManCentreGUI
ChangeCharacterView
ClaimEvent
I think people will find this useful in getting used to using of pointers (o-names) :)
Quote"SaveCursorUntilChange" implies that it waits for the cursor to change, but that's not the case. Anyone got any bright ideas?
Mouse.SaveCursorUntilLocationChange ?
A bit unwildy but the autocomplete feature should safe us there :)
QuoteMouse.SaveCursorUntilLocationChange ?
A bit unwildy but the autocomplete feature should safe us there Smiley
Yeah, "Cursor" should definitely be in it, since that is what will be saved, but I think we should avoid using the term "Location".
Hm, Mouse.SaveCursorUntilLeave?
QuoteIt didn't work for me. I loaded my v2.62 game up, changed a few local variable names (gui, object and so on), then tested it. The inventory items didn't show up (as they used to).
I resized the inventory control to the default dimensions set in the properties window, then they showed up.
Ah yes you're right, it's not working as it should; I'll get it fixed.
QuoteAnother thing: Is InventoryItem.RunInteraction still a delayed function? If so, it should be noted in the manual.
No, the RunInteraction commands aren't delayed. However, obviously if the interaction runs a script then that won't happen until the calling script finishes.
QuoteAll the names in autocomplete are alphabetically sorted (and that's cool I think, because we can for example group the related properties, variables and functions together by adding a lowercase prefix). But would it be possible to make sorting case-sensitive so that instead of:
I can see how that'd be handy, but I'm not sure whether scintilla (the text editor control that AGS uses) supports this behaviour. I'll look into it.
QuoteMouse.SaveCursorUntilLocationChange ?
A bit unwildy but the autocomplete feature should safe us there
Yeah, perhaps that would be best.
As strazer says, I don't really like "Location"; it's a pity there's no one word meaning "interactable thing" I guess ;)
QuoteNo, the RunInteraction commands aren't delayed. However, obviously if the interaction runs a script then that won't happen until the calling script finishes.
Heh, right, I completely forgot about those strange interaction editor commands... ;)
QuoteAs strazer says, I don't really like "Location"; it's a pity there's no one word meaning "interactable thing" I guess
Hey, how about "entities"? Mouse.SaveCursorUntilEntityChange? Or Mouse.SaveCursorUntilLeaveEntity?
Oh brother, here I go again.
checkhot=GetHotspotAtLocation(mouse.x, mouse.y);
"checkhot" is something I globally defined as a "hotspot". HOW do I set it to "whatever hotspot the mouse is over" with the new functions?
EDIT - This is probably silly and very easy, but my brain's fried right now...
Quote from: strazer on Sat 15/01/2005 22:26:09Hey, how about "entities"? Mouse.SaveCursorUntilEntityChange? Or Mouse.SaveCursorUntilLeaveEntity?
That's not a bad idea; but then, I don't really want to confuse people with too much new terminology, and 'Entity' would only cause questions I feel. It's a tricky one to be sure.
QuoteOh brother, here I go again.
checkhot=GetHotspotAtLocation(mouse.x, mouse.y);
"checkhot" is something I globally defined as a "hotspot". HOW do I set it to "whatever hotspot the mouse is over" with the new functions?
I'm not entirely sure what you're asking, but the replacement for GetHotspotAtLocation is Hotspot.GetAtScreenXY, so you'd just do:
checkhot = Hotspot.GetAtScreenXY(mouse.x, mouse.y);
Oh? I can use "Hotspot"? I thought I HAD to use a specific hotspot in there, a hotspot name or a hotspot[2] or something. Great! I thought objectised functions made these more generic things impossible... but if in things like this I can use Hotspot, Character and whatnot... yay! I thought flexibility had gone, and yet it's still here! Thankee sai!
QuoteHey, how about "entities"? Mouse.SaveCursorUntilEntityChange? Or Mouse.SaveCursorUntilLeaveEntity?
Or maybe SaveCursorUntilLeaveArea - meaning some screen area where interactable thingies are. Then again, not the perfect and can be confused with a walk-able area. Is there some equivalent word to "leave" accenting its mouse-to-move relation?
Quote from: Rui "Puss in Boots" Pires on Sun 16/01/2005 23:37:49
Oh? I can use "Hotspot"? I thought I HAD to use a specific hotspot in there, a hotspot name or a hotspot[2] or something.
Yeah, you type "Hotspot" to access general (not a certain hotspot specific) functions and "hotspot[ x ]" or a hotspot script-o-name if you mean a certain hotspot to work with.
Quote
Or maybe SaveCursorUntilLeaveArea ...
How about something like SaveCursorUntilPositionChange or SaveCursorUntilDeltaXY
Rick: but its not an XY change that restores the cursor, its moving off the char, object or HS
I found a problem with dynamic sprites: I can't have an array of them either inside or outside of a struct! Arrrgh!
A way to solve this problem would be to have a function:
DynamicSprite *GetDynamicSpriteFromSpriteNumber(int spriteno)
which basically does the opposite of the dyanmic sprite Graphic property. That way I can have an array of sprites like I used to before 2.7
Oh, and the manual page for CreateFromSaveGame still has a link to DeleteSprite at the bottom
That AGS QuickRef is gonna need an overhaul SSH ;D
As for the CursorChange , can it not simply be simplified, Mouse.SaveCursor
I see no reason why if needs to be elaborate, and like someone said above If you do make it lengthly Mouse.SaveCursorModeUntillItLeavesTheHotspotLocation then we still have the autocomplete ^^
QuoteOh? I can use "Hotspot"? I thought I HAD to use a specific hotspot in there, a hotspot name or a hotspot[2] or something. Great! I thought objectised functions made these more generic things impossible... but if in things like this I can use Hotspot, Character and whatnot... yay! I thought flexibility had gone, and yet it's still here! Thankee sai!
Yep, these are what's called "static functions". I'll add some sort of explanation to the Upgrading Guide.
QuoteOr maybe SaveCursorUntilLeaveArea - meaning some screen area where interactable thingies are. Then again, not the perfect and can be confused with a walk-able area. Is there some equivalent word to "leave" accenting its mouse-to-move relation?
How about SaveCursorUntilLeavesArea (with the 's' implying the fact that it's talking about the cursor leaving)?
Quoteor a hotspot script-o-name
Ooooh, "script-o-name", I like it. Sounds like something you'd find at a fairground :)
QuoteI found a problem with dynamic sprites: I can't have an array of them either inside or outside of a struct! Arrrgh!
Good point. The easiest solution here might be to implement arrays of pointers, I'll look into it.
QuoteOh, and the manual page for CreateFromSaveGame still has a link to DeleteSprite at the bottom
Thanks; it also occurs in a couple of other places, I'll fix it.
QuoteAs for the CursorChange , can it not simply be simplified, Mouse.SaveCursor
I see no reason why if needs to be elaborate, and like someone said above If you do make it lengthly Mouse.SaveCursorModeUntillItLeavesTheHotspotLo cation then we still have the autocomplete ^^
Well, it's such an odd piece of functionality that "SaveCursor" could well mislead people about what it does, so I think it justifies a longer name.
QuoteHow about SaveCursorUntilLeavesArea (with the 's' implying the fact that it's talking about the cursor leaving)?
I like that, although I'm not too fond of the "Area" part.
Doesn't SaveCursorUntilItLeaves basically say the same thing?
I vote for SaveCursorUntilTheMouseMovesOverADifferentObjectHotspotOrCharacter
Quote from: Pumaman on Mon 17/01/2005 19:20:31Ooooh, "script-o-name", I like it. Sounds like something you'd find at a fairground :)
Hehe, I don't even know how I came to type it like that - probably, that's how Script O-name remained in my mind. :)
QuoteGood point. The easiest solution here might be to implement arrays of pointers, I'll look into it.
Oh, arrays of pointers -- this would be an ultimate feature to have for the new OO system.
By the way, about having pointers within structs: if that were possible then how would a circular reference be made?
Quote from: strazer on Mon 17/01/2005 21:05:39I like that, although I'm not too fond of the "Area" part.
Doesn't SaveCursorUntilItLeaves basically say the same thing?
With this "s" at the end it seems rather suitable to me. At least we won't have "location", "area" or other a bit of confusing terminology that way. :)
EDIT:
Quote from: SSH on Mon 17/01/2005 21:41:49
I vote for SaveCursorUntilTheMouseMovesOverADifferentObjectHotspotOrCharacter
...OrLeavesInventoryItemsGUI ;D (it's not in the manual but seems to behave like that)
I'll say:
Mouse.SaveCursorHere()
So it may be changed when it leaves here and goes there. :=
Kidding of course. ;D
Quote... implement arrays of pointers, I'll look into it.
As Homer Simpson would say "Ummmmm, arrays of pointers...".
Quote... SaveCursorUntilTheMouseMovesOverADifferentObjectHotspotOrCharacterOrLeavesInventoryItemsGUI()
Hehe, That would make a swell easter egg to lay on some noob asking for advice. :=
First of all, many thanks CJ for updating the scripting to OO. This should make things a lot more powerful and flexible :)
Now, I can't seem to get my game to convert to 2.7 beta 12. When I load it I get prompted to update all the rooms to the new version, only every one fails with the following error:
There was an error compiling your script. The problem was:
Error (line 30): expected variable or function after import
Your room has not been saved.
Its the same error for every room, which is strange since line 30 is different for each one. The wording of the error led me to believe it was something to do with the script header, but it seems fine:
import function UpdateGUI(int, int, int);
import function RespawnChar(int, int);
import function DeadChar(int);
If I then make a change to the room script and try to recompile I get:
There was an error compiling your script. The problem was:
In: 'Internal character defines'
Error (line 30): expected variable or function after import
Only the line number changes depending on what I do to the script (add/remove lines).
Sorry for the long post, which I post here since I think it may be a bug ;D Any ideas? I can upload the game somewhere if it will help.
Thanks m8s,
Dan.
The problem is a certain line in your script, hence QuoteOnly the line number changes depending on what I do to the script (add/remove lines).
What is the line? Most likely, it's something that got outdated.[/s]
Nevermind, I didn't read closely. But do check your variables and the lines. This new version made some interesting changes. Double-check everything. I've had similar trouble before, and it was ALWAYS something I'd overlooked. Pay special attention to the variables used in line 30.
And just to be on the safe side, check line 30 of the Global Script too.
Thanks for the quick reply Rui.
I've checked the scripts, and everything seems okay? I've tried commenting out the imports in the header, so I don't think the problem lies there. I also commented out the functions in the global script, and still the same error (line 30 of the global script was in one of those functions). The room scripts have various commands at line 30, none of which use any vars at all (Display, RawSaveScreen, etc).
So whatever the problem with my script is, its not at line 30 ??? I'll just add that it compiles fine in 2.62.
I've upped it to http://freetohost.co.uk/dan/noworky.rar (2.63MB) if anyone has a minute to have a look
EDIT: Problem solved, many thanks :)
Cheers,
Dan.
I gave it a check. It really is odd. I didn't look at it in-depth, though. I'll leave it for someone more experienced.
QuoteDoesn't SaveCursorUntilItLeaves basically say the same thing?
Yep, I like it, "SaveCursorUntilItLeaves" it is.
QuoteBy the way, about having pointers within structs: if that were possible then how would a circular reference be made?
Well, the circular reference problem would only come up if custom managed structs were allowed. Since that may well happen in a future version, I don't want to completely rule it out by adding support for pointers in structs now.
In case anyone is wondering what a circular reference is, it's basically this:
struct A {
Ã, B *ptr;
};
struct B {
Ã, A *ptr;
};
A *a;
B *b;
function game_start() {
Ã, a.ptr = b;
Ã, b.ptr = a;
}
Because of the reference counting used to determine when objects are no longer in use, in this situation both instances have references to each other, so the memory will never be freed.
QuoteNow, I can't seem to get my game to convert to 2.7 beta 12. When I load it I get prompted to update all the rooms to the new version, only every one fails with the following error:
There was an error compiling your script. The problem was:
Error (line 30): expected variable or function after import
Your room has not been saved.
Thanks for uploading the game. The problem is that you have a GUI with a script name "GUI". This is conflicting with the new "GUI" type in the OO scripting language, and causing a rather un-useful error message.
I'll put a check for this into the next editor -- but the fix is to rename your GUI to something else.
The key to spotting that the problem isn't in your scirpt is this:
There was an error compiling your script. The problem was:
In: 'Internal character defines'Error (line 30): expected variable or function after import
That indicates that the problem occurred in an internal AGS script.
Beta 13 is now up. This must be some sort of record, I don't think we've ever had this many betas for a single release before ;)
Anyway, it includes the long-awaited Script Module support, as well as arrays of pointers. No documentation for these is provided yet, but hopefully they're self-explanitory.
As it's the initial release there are bound to be problems; so please do let me know of your experiences.
Script modules - just in time for the ATC, eh?
Quote* Added script module support, so that you don't have to cram everything into the global script. This also allows you to easily share code with other people by exporting the module.
Holy crap, this is so sweet!
But do you have to import custom functions from the module script somewhere to be able to use them in the main global script?
If I don't, it returns an undefined token upon compiling, if I do (module script header or main script header), I get
QuoteScript link failed: Runtime error: import address too high
when testing.
Edit:
Hm, I suppose script modules are put AFTER the global script by default, right?
Then how about a dummy entry for it in the module manager, so we can specify where we want the modules?
Edit 2:
QuoteThis must be some sort of record, I don't think we've ever had this many betas for a single release before
Yeah, and I think it's good we do. Since a lot has changed, we shouldn't rush the final until it's rock-solid.
QuoteThe problem is that you have a GUI with a script name "GUI". This is conflicting with the new "GUI" type in the OO scripting language, and causing a rather un-useful error message.
That was about the only place I never thought to look! That of course sorted it straight away :)
I have just one more question, would it be possible to allow numeric characters in object/gui/etc script names since I sometimes like to call things object1, object2, so on and the current version wont allow it from the editor. I guess calling them objecta and objectb is a suitable workaround though.
Thanks for the help and speedy support.
Dan.
Dan - I sometimes do it like that too. My workaround is, for instance, lblSaveI, lblSaveII, lblSaveIII... works for me. ;)
About module thingie - W00t! Man, I don't even know what that's good for! Heh, I'll be waiting for the documentation to magically appear on the manual.
About CJ's program - <looks under brilliant in the dictionary> Hey! There's a picture of CJ in my book! Whow, it must be worth a fortune... could you sign it, please?
Mildly annoying autocomplete "feature" when trying to use GUI.GetAtScreenXy... after typing GUI in caps, autocomplete keeps changing it to gui lowercase when I hit ".".... in general if the autocompleter finds multiple capitalised versions of completions, the default should be the one that matches in case that which is already typed.
Also confusing is InvWindow.GetAtScreenXY when you mean InventoryItem.GetAtScreenXY... maybe the helpfile (and editor error message when you use the wrong one) can point out the mistake.
The game templates will also need updating. For example:
function on_mouse_click(MouseButton button) {
and objectisation of all the stuff
Be nice if those (arrays of) pointers coudl be INSIDE structures, too.
The module stuff is great, but it would be even greater if we could associate individual GUIs with it too. And ideally, inventory items, characters, sprites and views.
ALso, having previously saved my game OK and I don't thinkm I made any changes, got this when saving to Test game:
(Exception 0xC0000005 at EIP=0x0048EC58,
AGSEDIT v2.70.569, SIP=26)
This also corrupted my previuously saved game >:(
Maybe it's me... see if you can replicate it, and if you can, it's NOT just me. It's just that, not matter WHAT values I set invMain.ItemHeight and Width, both in the script AND in it's properties, all I get is one INV item displayed at a time, tops, even if I have more. The one that is displayed is the first one I got, and clicking ANYWHERE inside the INV window with it selected gives me my standard "use item with itself" response... it looks as though the item's size is exactly the size of the INV window. No matter how much I fiddle with the height/width settings.
EDIT - I am really baffled by this... I wonder if someone could try and replicate it? That way I'd know if the problem was mine and mine alone, or whether...
EDIT 2 - I found it. It's not my mistake, either. The following line of code
Display("%d,%d,%d", invMain.ItemHeight, invMain.ItemWidth,invMain.ItemCount);
yielded the response
171,185,2
Now, 171 and 185 are the dimensions of MY INV WINDOW... and in it's properties, I set 20 and 30 to item size - to no avail. Neither is there ANY code in my script which changes this size. It seems to be a bug in AGS.
Quote from: Pumaman on Wed 19/01/2005 19:50:47Well, the circular reference problem would only come up if custom managed structs were allowed. Since that may well happen in a future version, I don't want to completely rule it out by adding support for pointers in structs now.
I see... There could then probably be some sort of a soft referencing available, so that the engine won't count references for such pointers, but then again it would mean that such pointers are not safe to use anymore which shadows the whole beauty of the automatic object-management system.
Anyway, I guess it's a topic to be left to discuss for a future version. :)
Quote* Added script module support, so that you don't have to cram everything into the global script.
Just amazing!!1Ã, :D
Quote* Added script call stack when an error occurs, rather than just the current line number.
Great, thanks for that -- I wanted to suggest this feature a couple of months ago and it's already there.
By the way, would it be possible to raise an error from the script? some kind of the AbortGame function, would be very handy since modules have been implemeted:
if ((value < min) || (value > max)) AbortGame("Error setting the value = %d! It's out of range %d..%d", value, min, max);
Quote* Added support for arrays of pointers.
Cool! From now we can iterate through things without using their IDs but by setting up an array(s).
Quote from: strazer on Wed 19/01/2005 23:13:06But do you have to import custom functions from the module script somewhere to be able to use them in the main global script?
I guess the script modules are additional global scripts that remain in the memory all the time until game is quited. And all the module headers are placed before the main script header, so I think putting import declarations into the module header should make the function/variable be available to use from within both the main global script and all room scripts.
QuoteIf I don't, it returns an undefined token upon compiling, if I do (module script header or main script header), I get
QuoteScript link failed: Runtime error: import address too high
when testing.
That's strange. I think that should work.
QuoteHm, I suppose script modules are put AFTER the global script by default, right?
Then how about a dummy entry for it in the module manager, so we can specify where we want the modules?
You mean module headers? I think they are already put before the script header.
By the way, it would be ultimately useful if we could declare event handler functions within script modules (i.e. repeatedly_execute, game_start, on_event, on_key_press, etc.). Would be cool if they were called before other handlers from the main and room scripts.
Then we wouldn't ask someone who uses the module to put some module functions within repeatedly_execute just for the module to work properly, for example.
QuoteBy the way, it would be ultimately useful if we could declare event handler functions within script modules (i.e. repeatedly_execute, game_start, on_event, on_key_press, etc.)
Yes, that would be nice.
QuoteBut do you have to import custom functions from the module script somewhere to be able to use them in the main global script?
If I don't, it returns an undefined token upon compiling, if I do (module script header or main script header), I get
Script link failed: Runtime error: import address too high
when testing.
You put any module functions import statements into the module's header.
The "address too high" message you're getting indicates that an assumption I made when coding the feature was wrong, and so script modules won't work on all computers. Therefore, I'll re-code that bit for the next beta.
QuoteHm, I suppose script modules are put AFTER the global script by default, right?
Then how about a dummy entry for it in the module manager, so we can specify where we want the modules?
Script modules are processed in the order specified, BEFORE the global script. The global script is always the last one, so that it can call functions in the modules. Due to the way script linking works, modules can only call functions in modules before them in the list.
QuoteI have just one more question, would it be possible to allow numeric characters in object/gui/etc script names since I sometimes like to call things object1, object2, so on and the current version wont allow it from the editor. I guess calling them objecta and objectb is a suitable workaround though.
That could be possible ... but if you're just calling it "object1" then why bother giving it a name at all, and just use its number instead. The aim of the script name is to allow you to, well, give it a name :P
QuoteMildly annoying autocomplete "feature" when trying to use GUI.GetAtScreenXy... after typing GUI in caps, autocomplete keeps changing it to gui lowercase when I hit ".".... in general if the autocompleter finds multiple capitalised versions of completions, the default should be the one that matches in case that which is already typed.
I've noticed this too and it is quite annoying; unfortunately, the scintilla text editor control that AGS uses doesn't seem to allow the behaviour that we're after.
QuoteAlso confusing is InvWindow.GetAtScreenXY when you mean InventoryItem.GetAtScreenXY... maybe the helpfile (and editor error message when you use the wrong one) can point out the mistake.
What I'll do for this one is remove GetATScreenXY from the InvWindow autocomplete -- it's counter-intuitive being there anyway since it only returns a GUIControl* and not an InvWindow*.
QuoteThe game templates will also need updating. For example:
Yeah, I'm aware of that; there's various clean-up tasks that will need to be done before 2.7 Final. I've been leaving this until the OO language is finalized to save having to keep re-doing it.
QuoteBe nice if those (arrays of) pointers coudl be INSIDE structures, too.
As I've said before, pointers within structs are not likely to happen, due to various different reasons. Sorry.
QuoteThe module stuff is great, but it would be even greater if we could associate individual GUIs with it too. And ideally, inventory items, characters, sprites and views.
How about full 3D support and tea-making abilities while I'm at it? :P
QuoteALso, having previously saved my game OK and I don't thinkm I made any changes, got this when saving to Test game:
Hmm that's a bit worrying, as far as I was aware all the editor problems were fixed. Did your game have any script modules?
QuoteMaybe it's me... see if you can replicate it, and if you can, it's NOT just me. It's just that, not matter WHAT values I set invMain.ItemHeight and Width, both in the script AND in it's properties, all I get is one INV item displayed at a time, tops, even if I have more.
Yes I apologise, I broke the custom inv window for beta 13. Looks like it's living up to its number after all ;)
QuoteBy the way, would it be possible to raise an error from the script? some kind of the AbortGame function, would be very handy since modules have been implemeted:
That's not a bad idea actually, I'll look into it.
QuoteI guess the script modules are additional global scripts that remain in the memory all the time until game is quited. And all the module headers are placed before the main script header, so I think putting import declarations into the module header should make the function/variable be available to use from within both the main global script and all room scripts.
Correct!
QuoteBy the way, it would be ultimately useful if we could declare event handler functions within script modules (i.e. repeatedly_execute, game_start, on_event, on_key_press, etc.). Would be cool if they were called before other handlers from the main and room scripts.
Then we wouldn't ask someone who uses the module to put some module functions within repeatedly_execute just for the module to work properly, for example.
Yeah, that's definitely something I'll consider for a future version.
Quote from: Pumaman on Sat 22/01/2005 11:50:18
QuoteBe nice if those (arrays of) pointers coudl be INSIDE structures, too.
As I've said before, pointers within structs are not likely to happen, due to various different reasons. Sorry.
Oh, I thoguht that it was just the circular ref thing, because I only wanted pointers to built-ins not pointers to user-defined stuff.
Quote
QuoteThe module stuff is great, but it would be even greater if we could associate individual GUIs with it too. And ideally, inventory items, characters, sprites and views.
How about full 3D support and tea-making abilities while I'm at it? :P
Well, modules are pretty useless for code transfer in a game without any kind of grahpics associstaed with them, since these are graphical adventures, after all . They can only really be used for organisation at the moment, not collaboration.
Quote
QuoteALso, having previously saved my game OK and I don't thinkm I made any changes, got this when saving to Test game:
Hmm that's a bit worrying, as far as I was aware all the editor problems were fixed. Did your game have any script modules?
Not really, although I might have just created an empty one while playing around with the module dialog...
Quote from: SSH on Sat 22/01/2005 13:11:47
Oh, I thoguht that it was just the circular ref thing, because I only wanted pointers to built-ins not pointers to user-defined stuff.
Well, the circular references is the main thing; but that could actually be sorted by only allowing pointers to built-in things. The rest is technical issues about ensuring that reference counts are decreased when the struct goes out of scope, but that could probably be overcome with a little effort.
So, on re-thinking about it, a cut-down version of pointers in structs might be possible.
Quote
Well, modules are pretty useless for code transfer in a game without any kind of grahpics associstaed with them, since these are graphical adventures, after all . They can only really be used for organisation at the moment, not collaboration.
I guess it depends what you'd envisiged using them for. The current implementation allows you to have handy "utility libraries" such as RickJ's INI File functions, and so forth, which the user can easily add to their game without having to cut & paste around in their global script.
Obviously if you were after a fuller implementation where you could have a whole GUI with code and graphics in a module, then this isn't there yet.
Quote
Not really, although I might have just created an empty one while playing around with the module dialog...
I've just been playing around with it and trying to get it to crash on saving, but I can't seem to manage it. Has anyone else had this problem?
QuoteI've just been playing around with it and trying to get it to crash on saving, but I can't seem to manage it. Has anyone else had this problem?
I have just managed to get it to crash. That's what I did:
- created a new game (using the Default game template)
- opened the module manager and added a new module (named "1")
- clicked on the "close" button and hit Ctrl-S to save the project
AGS complained about the room doesn't exist, and on pressinf "yes" the error message SSH reported about poped up, i.e.:
Quote(Exception 0xC0000005 at EIP=0x0048EC58,
AGSEDIT v2.70.569, SIP=26)
And yep, when I tried to load that project back (after the crash) the editor said the file is currupted or something.
Ah, thanks -- yep, the crash happens if you create a new module, but don't actually put anything in its script before saving the game. I'll get it fixed.
When using a struct in a new module, it doesn't seem to retain variable declarations, or, at least with the new stuff such as arrays and arrays of structs. I have a Main Module which holds all the general stuff including an array of structs:
char_data pc[MAX_CHARS];
And is accessed in a lower-level module named Menu Management:
StrFormat(buf1, "Level %2d", pc[cb.party[2]].level);
It generates an index out of bounds error when running the game. Do variables declared in module headers not persist throughout the code like the functions do?
Ok, beta 14 is now up.
This is a relatively minor update, which fixes a few things that were wrong with beta 13, and adds some minor new features.
Note that if you have a custom inventory window, and you saved your game with beta 13, you'll need to manually put its ItemWidth and ItemHeight back to how they were before beta 13 messed them up.
In other news, the first stage of the wiki-manual is now up -- that is, it's basically the manual online, with no Add Comment facility yet:
http://www.adventuregamestudio.co.uk/manual/
it should mirror the CHM manual exactly.
QuoteWhen using a struct in a new module, it doesn't seem to retain variable declarations, or, at least with the new stuff such as arrays and arrays of structs.
It should be fine. Because there are two array index possibilities in that line, can you try splitting it into two for debugging purposes:
int index = cb.party[2];
Display("index = %d", index);
Display("%d", pc[index].level);
What index does the error message say you are using, and what does it say the max is?
Quote* GUI control event functions now take a GUIControl* parameter, representing the activated control. This allows you to use the same handler function for multiple controls, and distinguish which was clicked. Note that if you have any existing event handlers they will no longer work -- you need to add a "GUIControl *control" parameter AS THE FIRST PARAMETER.
I'm curious - what does this benefit in? Becuase aren't those handlers created individually for each control? In practical terms, once you create the handler, isn't it linked to the control? How would this innovation benefit?
As for documentation update... great work, CJ. Crystal clear.
Quote from: Rui "Erik" Pires on Sun 23/01/2005 22:06:18
Quote* GUI control event functions now take a GUIControl* parameter, representing the activated control. This allows you to use the same handler function for multiple controls, and distinguish which was clicked. Note that if you have any existing event handlers they will no longer work -- you need to add a "GUIControl *control" parameter AS THE FIRST PARAMETER.
No, by DEFAULT there is a unique one created for each control, but if you edit the name to be one that already exists, then you can use the same function for multiple controls. In fact, this worked before in earlier betas, but this just makes it easier, as you don't have to detect where was the mouse clicking, etc.
AAaaah! Good one! Yes, very useful indeedly!
Quote from: Pumaman on Sat 22/01/2005 14:07:54
Quote
Well, modules are pretty useless for code transfer in a game without any kind of grahpics associstaed with them, since these are graphical adventures, after all . They can only really be used for organisation at the moment, not collaboration.
I guess it depends what you'd envisiged using them for. The current implementation allows you to have handy "utility libraries" such as RickJ's INI File functions, and so forth, which the user can easily add to their game without having to cut & paste around in their global script.
Obviously if you were after a fuller implementation where you could have a whole GUI with code and graphics in a module, then this isn't there yet.
Actually, I realise that if you could just import/export invidiual GUIs rather than all of them then you wouldn't necessarily need tit to be integrated with the module system. You just get someone to save a GUI and a module and load them both up...
So, pretty please on the single GUI import/export, CJ, please (does big Manga pleading eyes look) :=
I second that!
Script module suppot is superior feature I've been waiting for. How are you going to use CVS for collaboration without it? And how are you going to write more or less professional game without some sort of CVS? ;)
Quote from: Pumaman on Sat 22/01/2005 11:50:18The "address too high" message you're getting indicates that an assumption I made when coding the feature was wrong, and so script modules won't work on all computers. Therefore, I'll re-code that bit for the next beta.
Thanks, works perfectly now.
Quote from: Pumaman on Sun 23/01/2005 20:21:50
QuoteWhen using a struct in a new module, it doesn't seem to retain variable declarations, or, at least with the new stuff such as arrays and arrays of structs.
It should be fine. Because there are two array index possibilities in that line, can you try splitting it into two for debugging purposes:
int index = cb.party[2];
Display("index = %d", index);
Display("%d", pc[index].level);
What index does the error message say you are using, and what does it say the max is?
On trying the code, it seems indeed the problem lies with the cb.party[2] as it equals 1241756 instead of 1. The index bounds are 0 - 9, which are correct. I'm not sure why as its value is initialized at the same time as 0 - 4 when the NewGame Function in a higher-level Module is run (which is called at game_start). The function UpdateCharBar where the error occurs is called in repeatedly_execute.
Quote from: Jet Kobayashi Zala on Sun 23/01/2005 17:05:00Do variables declared in module headers not persist throughout the code like the functions do?
Yeah, if you declared a variable within the header of a script module then you'd get two different variables with the same names: one in the global script and the other - in the script module itself.
To share a variable you can do:
module header:struct TypeMyStruct {
Ã, Ã, int x;
};
import TypeMyStruct instance;
module script:TypeMyStruct instance;
export instance;
global script:instance.x = 10;
Quote from: Pumaman* Added AbortGame function to allow script modules to perform checks on their parameters and easily give an error.
Thanks for implementing it: along with the call stack info it is much easier to debug the script code.
I like the online version of the AGS manual and looking forward to that "add comment" thingy.
Yes, if you're declaring a variable in the script header without an 'import', you will get a seperate copy for each script. You should only ever import things in the script header, never just declare a variable there.
In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?
<raises hand>
I found it nice to be able to use the same variable NAME but its own VALUE in a couple of situations while I made LSL2.
Unless, of course, you want to optimize something, or need it out of your way for some other thing. But if it makes no difference, please leave it.
Quote
In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?
I put a variable and a tiny function in the script header once to achieve my purpose. It was a long time ago so I can't off the top of my head remember more details but it seemed to be necessary at the time. I think it had something to do with global functions not being able to access arrays declared in the room script or something similar. So instead of a global function I just made an actual copy in each room. Probably the new OO stuff would provide a better solution but I appreciate the flexibility. How about giving us a directive (perhaps #norestrictions or similar) to enable such things if we so desire and disallowing them otherwise..
Anyway thanks for the module manager. I am refining the IniFile thing and making it into a module. I'll have some comments shortly about my experience :=.
Quote from: Pumaman on Tue 25/01/2005 18:18:10
In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?
Hmmm, if the compiler can be made to stop that, that means it can be made to
detect that. In that case I'll vote
not to stop this behaviour (as it may be useful, like others mentioned) but just generates a warning to remind the coder when the header is saved.
Actually I can think of at least one more use, for example, in a 256-coloured game, if you want to save the palette of each room to an array for whatever use, you can just declare the array in the header.
I agree with possibly doing a preprocessor directive kinda deal. Like I myself, prefer to keep all my module-level variables in the header along with the import stuff just so its easy to keep functions and variables separate. Any sort of:
#importonly
#norestrictions
#allowlocaldeclares
or some such would make a better option than restricting entirely.
EDIT: Also, the export dealy fixed the problem. Thanks. I just thought that the module headers worked more like one large global header divided into sections and read sequencially rather than being more individual like they are. And thus, anything declared in a previous header would be available to lower-levels without needing to export.
Gilbot - and be reminded of that every single time we save the game? Not sure I like that. Me, being a "save early save ofter"er, I'd find it cumbersome...
Read my post carefully, I had thought of that already, I only said it's when saving the header script, and normally you won't edit it that many times anyways (as you need to recompile everything whenever it's modified), it's just a kind reminder.
Also, bear in mind that while the ability of defining variables maybe convenient to you and me, it can cause confusions and problems with average users, so it's only for those who knows what he's doing to use such feature.
On another thought, maybe it can help some people also if it warns you whenever you save a game, preferably if there's a check box like "don't show this warning again" which you can check so the warning won't appear again anymore when you save this game agaian next time.
Oh, ok. I thought that the script header was saved along with the rest of the game when using Ctrl-S, which I use more often than Ctrl-A.
Oh, oh, I see now. Not upon saving the game, but like closing the script and being asked to save changes - THAT time. Sorry, I'd misunderstood you. Twice. Heh.
It's alright, the only problem is I don't know if it's worth implemented, as currently when you save a header script the editor won't check anything (I think) and only parses it when you save the game (or a room, since the header stuff had to be inserted into the room script), if it has to generate such warnings when the header is saved it has to do extra checking (which I think is not much of a problem though).
Maybe the Save a game/room warning with checkbox idea is better.
Quote from: Jet Kobayashi Zala on Wed 26/01/2005 05:34:30EDIT: Also, the export dealy fixed the problem. Thanks. I just thought that the module headers worked more like one large global header divided into sections and read sequencially rather than being more individual like they are. And thus, anything declared in a previous header would be available to lower-levels withoutÃ, needing to export.
Yeah, I believe, headers can in fact be treated as something to construct a
resulting header from. The following scheme shows what I mean:
Suppose, we have three module scripts added in the following order:
Module #1
Module #2
Module #3
Thus, the 2nd module can use the 1st one, while the 3rd module can use
both the 1st and the 2nd ones.
So, the resulting header for each module
(as well as for room and main global scripts) is as follows:
|----------------|
|Ã, Ã, Module #1Ã, Ã, |
/----------------\
|module #1 header| >------ resulting header
|----------------|
|module #1 script|
\----------------/
|----------------|
|Ã, Ã, Module #2Ã, Ã, |
/----------------\ ---
|module #1 header|Ã, Ã, \___ resulting header
|module #2 header|Ã, Ã, /
|----------------| ---
|module #2 script|
\----------------/
|----------------|
|Ã, Ã, Module #3Ã, Ã, |
/----------------\ ---
|module #1 header|Ã, Ã, \
|module #2 header|Ã, Ã, Ã, --- resulting header
|module #3 header|Ã, Ã, /
|----------------| ---
|module #3 script|
\----------------/
|----------------|
|Ã, Main GlobalÃ, Ã, |
/----------------\ ---
|module #1 header|Ã, Ã, \
|module #2 header|Ã, Ã, Ã, \
|module #3 header|Ã, Ã, Ã, --- resulting header
|----------------|Ã, Ã, Ã, /
|gl.script header|Ã, Ã, /
|----------------| ---
|global scriptÃ, Ã, |
\----------------/
|----------------|
|Ã, Ã, Ã, RoomÃ, Ã, Ã, |
/----------------\ ---
|module #1 header|Ã, Ã, \
|module #2 header|Ã, Ã, Ã, \
|module #3 header|Ã, Ã, Ã, --- resulting header
|----------------|Ã, Ã, Ã, /
|gl.script header|Ã, Ã, /
|----------------| ---
|room scriptÃ, Ã, Ã, |
\----------------/
Thus, for example, a function/variable imported via the module #2 header will be available to use from within all the other scripts but module #1 (since its resulting header doesn't include module #2 header).
As for needing to export variables, it's just an extra step in comparison to functions because functions are exported automatically.
Quote from: PumamanIn fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?
I too find it handy for certain things, on the other hand I can also see how this can be confusing. If this will be added, I think some sort of a directive (having effect until header ends, for example) or a keyword to still allow declaring variables in headers would be nice, since with modules introduced it may be useful to control this behaviour on a per header basic rather than having a global option affecting all module headers.
By the way, I just noticed that swopping round two script modules in the module manager doesn't make AGS re-compiling them.
Thus, if I have one module using some functionality of another one and then just swop them around (without editing their scripts), the client module still has the "import function" declaration making it possible to refer the function. The problem raises at run-time, while linking, with "unresolved import declaration" error.
EDIT:
One question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?
QuoteOne question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?
While we're at it, how about the same for on_event? ::)
Quote
Suppose, we have three module scripts added in the following order:
Module #1
Module #2
Module #3
Thus, the 2nd module can use the 1st one, while the 3rd module can use
both the 1st and the 2nd ones. ...
Tis raises a couple of issues I've been thinking about since modules became possible, programming conventions and dependency management.
Programming ConventionsIf multiple modules from multiple sources are to be used together then there needs to be a means of avoiding naming conflicts. For example suppose Scorp and Rui each make really cool modules and I want to use one from each author and suppose Scrop in one module header there is "#define TRUE 42" and in the other module header there is "#define TRUE -1". In this case there aren't many options (modify one of the modles or not using one of them).
So how can programming conventions help? One of the programming conventions may be that for published modules #define names begin with the module name. So in the above example you would have "#define MODULE1_TRUE 42" and #define MODULE2_TRUE -1".
I'm sure if we put our minds to it we could come up with a minimal set of rules that we could recommend to would-be module authors. Of course would still be up to the individual authors to follow the rules but at least they would have some guidance.
Dependancy ManagementScrop's previous post also points out the need for some kind of dependancy management. I'm am not certain what form this should take but here are some ideas of what I am thinking about.
At minimum there needs to be a way, in a given module, to list other modules that are required for it to work. The list could be displayed in the module manager dialog or it could be in the module header as directive (i.e. #dependancy MyModule). The list could also be in the header comments or the module manager description field but this depends upon the discipline of the module author(s) and good programming conventions.
If the dependancy list were in the module manager or header then warnings could be generated by compiler or module manager indicating that this or that moduole is required. This would indicate not only which modules need to be included but would also be helpful in getting them in the right order.
----------
I'm thrilled with the new module stuff :)
QuoteHmmm, if the compiler can be made to stop that, that means it can be made to detect that. In that case I'll vote not to stop this behaviour (as it may be useful, like others mentioned) but just generates a warning to remind the coder when the header is saved.
Yes, I think this sort of thing would be the ideal candidate for a warning.
Now that you mention it, I've been wondering about the most user-friendly way to implement warnings in AGS. There are a couple of other things that the compiler already detects (like unused variables) that it could report as a warning.
Perhaps if warnings are generated the status bar could say so after the compile finished, and then there could be a "View Warnings" option on the File menu or something to see them.
QuoteI just thought that the module headers worked more like one large global header divided into sections and read sequencially rather than being more individual like they are. And thus, anything declared in a previous header would be available to lower-levels without needing to export.
They do work like one large header, in the manner that Scorpiorus describes in his post. However, the missing link is that you have to manually export variables in their script module. Functions are exported automatically because the chance of them being imported elsewhere is quite high; automatically exporting all variables would unnecessarily bloat the compiled script.
QuoteBy the way, I just noticed that swopping round two script modules in the module manager doesn't make AGS re-compiling them.
Good point, I'll fix that for the next version.
QuoteOne question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?
Good point. It's a bit difficult with unhandled_event though, because the second parameter can mean different things depending on the first one, so an enum wouldn't really work. It's a bit messy, come to think of it.
QuoteWhile we're at it, how about the same for on_event?
Sounds sensible.
QuoteSo how can programming conventions help? One of the programming conventions may be that for published modules #define names begin with the module name. So in the above example you would have "#define MODULE1_TRUE 42" and #define MODULE2_TRUE -1".
That's a good point. I suppose we'll see what sort of use people make of Modules, but some sort of conventions would be good.
QuoteAt minimum there needs to be a way, in a given module, to list other modules that are required for it to work. The list could be displayed in the module manager dialog or it could be in the module header as directive (i.e. #dependancy MyModule).
Interesting idea. Whether this is worth implementing depends I guess on the likelihood of modules relying on each other. I would assume that for the most part, modules will be self-contained bits of functionality that won't require anything else.
I suggest we leave it for now and see if this develops into a problem, unless you think it is likely to become one.
QuoteI'm thrilled with the new module stuff
Glad you like it :)
Finally, I'm thinking of making the next release RC1 and basically not adding any more new features to 2.7 after that. Is there anything that you guys is particularly important that should be added before 2.7 goes Final?
QuotePerhaps if warnings are generated the status bar could say so after the compile finished, and then there could be a "View Warnings" option on the File menu or something to see them.
And/or clicking the status bar could show them as well.
QuoteIs there anything that you guys is particularly important that should be added before 2.7 goes Final?
I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.
Edit:
Moreover (Sorry, couldn't resist ;) ):
Rename "No interaction" checkbox (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=90)
See my comment in there.
LECTalkView + SierraTalkView (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=154)
I think we should decide on an approach now. Unfortunately, I have no idea what the best way would be.
Import/Export single GUI (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=104)
I didn't see a practical use for this before, but now that modules are implemented, I agree with SSH that this would be pretty handy.
RunDialogOption(topic, option) (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=212)
Until more customizable dialog option GUIs are possible, this would make workarounds more flexible. See my comment in there.Display room info on "Areas" pane (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=356)
Should be an easy one and results in one less tracker entry.
And do you plan to update the text script equivalent codes for interaction editor commands to the new oo-system?
Quote
QuoteIs there anything that you guys is particularly important that should be added before 2.7 goes Final?
I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.
I agree with Strazer.Ã, It would make more complete/useful, etc...
Quote from: strazer on Wed 26/01/2005 21:24:05
QuoteIs there anything that you guys is particularly important that should be added before 2.7 goes Final?
I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.
Seconded, or thirded, or whatever...
Quote
RunDialogOption(topic, option) (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=212)
Until more customizable dialog option GUIs are possible, this would make workarounds more flexible. See my comment in there.
This would be nice, but is work-aroundable, unlike the most-important thing, the single GUI import/export
QuoteThis would be nice, but is work-aroundable
Right. Scratch that.
For the 2.7 Final:
Hmm... I'm not sure if this is a bug... has anyone tried the "Based on X-Position" option for textboxes? It seems to not work for me. I'm assuming from the help that it's based on the speaking character's X-Position, however, it doesn't seem to work for my test game. Has the new OO-izing killed the feature inadvertedly?
Hmm... can't really think of anything else to include considering all the new additions and posted recommendations made already.
Quotethe "Based on X-Position" option for textboxes
I don't understand what feature you mean. Are you referring to TextBox gui controls? Display() guis? Character.SayAt?
I think he's talking about the character portraits in Sierra-Style speech.
QuoteI think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.
Yeah, I guess it would. I'm a bit concerned about performance if repeatedly_execute is done so I"ll have to consider that, but the other handlers could definitely be added.
QuoteRename "No interaction" checkbox
See my comment in there.
Display room info on "Areas" pane
Should be an easy one and results in one less tracker entry.
These two sound reasonable, and I agree it would be a good time to clean them up.
Quote
LECTalkView + SierraTalkView
I think we should decide on an approach now. Unfortunately, I have no idea what the best way would be.
Ok, well I think the easiest solution would probably be to have a PortraitView property for the sierra style; and the normal SpeechView would then contain the lucasarts view if the combi speech style was selected.
Quote
Import/Export single GUI
I didn't see a practical use for this before, but now that modules are implemented, I agree with SSH that this would be pretty handy.
Yes, I can see the benefits of this. The GUI im/ex-port needs to be updated anyway to handle the control event handlers.
Quote
RunDialogOption(topic, option)
Until more customizable dialog option GUIs are possible, this would make workarounds more flexible. See my comment in there.
I agree with your later comment that this isn't necessary for 2.7.
QuoteHmm... I'm not sure if this is a bug... has anyone tried the "Based on X-Position" option for textboxes? It seems to not work for me.
In what way doesn't it work? The feature is supposed to determine whether the portrait appears on the left or right of the screen, depending on which character is standing to the left/right of the other. Nothing more.
CJ, could you please allow more than 20 properties? I need it, I really do. I've reached the limit of properties you can have, and I need more. I don't know how many more... how does 10 more sound?
EDIT - And I suppose we won't be seeing "SetProperty" this time around, will we? ::)
Nevermind, I worked around it. :P But:
If we can't set a properties' text... is there any chance we can set the property to a string and then access and edit the string like a common string? That'd be a workaround, I guess...
Quote
... I'm a bit concerned about performance if repeatedly_execute is done so I"ll have to consider that ...
Ouch, I was hoping to use this. Are you talking about a peformance hit because of what the user script may be doing or because of internal overhead accessing stuff in a module? If it is the former case you are concerned about then perhaps a "caveat emptor" disclaimer is all that is necessary. If it is the latter case I can only plead ignorance and leave it up to your good judgement.
QuoteOuch, I was hoping to use this.
So was I. :P
Sorry. With regards to the X-Position option, yes, I'm referring to the Sierra portraits for the Sierra-Style Speech. When I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech. I've made entire rooms walkable, walking the character from left to right, but no luck. And, indeed, I have made sure that the right character is calling the Say function.
Note: To display the text, I'm using the character[].Say(), which I think replaced the DisplaySpeech().
Would it be possible for the compiler to support operators (at least + and *) in array declarations?
I'd rather do
char threedarray[AGS_MAX_VIEWS*AGS_MAX_LOOPS_PER_VIEW*AGS_MAX_FRAMES_PER_LOOP];
than having to put a fixed value in there.
QuoteWhen I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech
When I was testing it with a single character saying something, the portrait appeared always on the right side of the screen, regardless whether he was on the left or right side of the screen.
When I had another character (char 2) say something immediately afterwards from the same interaction, his portrait appeared on the left side (char 1 was standing right of char 2). If char 1 stands left of char 2, char 1's speech appears left, char 2's right.
So it seems to depend on the number of Say commands in the script and the position of the characters relative to each other.
I agree the portrait should appear on the side of the screen the char is at if you use a single Say command.
The text dump of scripts should include modules (although maybe not if they are set to non-editable)
It would also be nice if scripts were dumped in the roder they are compiled, at the momentnb header comes last and rooms cripts first which is kind of backwards...
and I'd want a module rep_ex, too...
I have no idea if this has already been suggested, but I don't really care...
The option to modularise entire #sections would be great. It would effectively remove the need for a global script, but it would be a lot easier to keep track, especially now GUI scripts have changed the way they have.
Quote from: strazer on Fri 28/01/2005 14:30:08
QuoteWhen I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech
When I was testing it with a single character saying something, the portrait appeared always on the right side of the screen, regardless whether he was on the left or right side of the screen.
When I had another character (char 2) say something immediately afterwards from the same interaction, his portrait appeared on the left side (char 1 was standing right of char 2). If char 1 stands left of char 2, char 1's speech appears left, char 2's right.
So it seems to depend on the number of Say commands in the script and the position of the characters relative to each other.
I agree the portrait should appear on the side of the screen the char is at if you use a single Say command.
Strazer, I just tried the same test and noticed something else. If I start a set of says with two characters, they appear on the correct side. However, if I run the dialog, switch sides and talk again (just by moving char 1 to the opposite side he was on from char 2), the char 1's first textbox (which is the first dialog in the speech), still appears as if he was on the previous side for the first textbox. That is:
Char 1 Char 2
Talk, all is fine.
Char 1 walks to the right of Char 2
Char 2 Char 1
Talk, and Char 1 portrait is still shown on the left for first speech, then char 2 speech is shown with portrait on the left, then Char 1 is shown again, but on the right side.
QuoteIf we can't set a properties' text... is there any chance we can set the property to a string and then access and edit the string like a common string? That'd be a workaround, I guess...
I'm not really sure what you're asking, but changable custom properties are not something that will be implemented for 2.7.
QuoteOuch, I was hoping to use this. Are you talking about a peformance hit because of what the user script may be doing or because of internal overhead accessing stuff in a module?
Yeah it's to do with the internal overhead, however I have some ideas on how to streamline it, so this may not be an issue.
QuoteSorry. With regards to the X-Position option, yes, I'm referring to the Sierra portraits for the Sierra-Style Speech. When I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech.
This feature is by no means perfect. For example, the first character to speak will always have their portrait on the left, since on the first Say line it doesn't know who they're talking to. Also, if characters move around and switch positions in between speech lines this fact is not necessarily picked up.
QuoteWould it be possible for the compiler to support operators (at least + and *) in array declarations?
This is actually non-trivial to add but I'll bear it in mind.
QuoteThe option to modularise entire #sections would be great. It would effectively remove the need for a global script, but it would be a lot easier to keep track, especially now GUI scripts have changed the way they have.
Well, if you mean putting every single function in its own module then it would be possible, but the overhead of having 300 script modules would probably outweigh the benefits.
Quote
QuoteOuch, I was hoping to use this. Are you talking about a peformance hit because of what the user script may be doing or because of internal overhead accessing stuff in a module?
Yeah it's to do with the internal overhead, however I have some ideas on how to streamline it, so this may not be an issue.
Thanks for the effort, I hope you are able to find a suitable solution. For whatever it's worth, if the performance penalty is incurred only when rep_ex() is included then it is perhaps tolerable. It would just need to be noted in t he module description or header that this is the case. I don't mean to disuade you from attempting to eliminate the problem, but rather, to assure you that I/we are willing to work around it if need be.
QuoteThe option to modularise entire #sections would be great. It would effectively remove the need for a global script, but it would be a lot easier to keep track, especially now GUI scripts have changed the way they have.
Well, if you mean putting every single function in its own module then it would be possible, but the overhead of having 300 script modules would probably outweigh the benefits.
Quote
I don't know exactly what AGA had in mind in his original question but it made me think along the lines of having seperate modules for character interactions inventory interactions, etc. So I guess there would be something similar to one module for each character, one module for the inventory, one module for GUIs, etc. rather than one module for each interaction function.
The automatically inserted/deleted interaction functions, IMHO, can get a bit untidy/unmaganeable as a game grows in size. Perhaps another approach would be to use #section directives to manage the groups I describe above and maintain the global script as is. The editor could then have some additional bookmarks and perhaps edit buttons in the inventory and character editor tabs.
Quote from: SSH on Fri 28/01/2005 17:16:48
The text dump of scripts should include modules (although maybe not if they are set to non-editable)
It would also be nice if scripts were dumped in the roder they are compiled, at the momentnb header comes last and rooms cripts first which is kind of backwards...
and I'd want a module rep_ex, too...
If there is an overhead in accessing modules from rep_ex, does this apply to a global rep_ex calling a module function, too? That would be much more serious!
Quote from: RickJ on Sat 29/01/2005 20:56:53
I don't know exactly what AGA had in mind in his original question but it made me think along the lines of having seperate modules for character interactions inventory interactions, etc. So I guess there would be something similar to one module for each character, one module for the inventory, one module for GUIs, etc. rather than one module for each interaction function.
Yeah, that's what I meant. Not one module for every individual GUI interaction, one for every inventory item etc, but one big module for ALL GUI interactions, one for all inventory etc. So you'd end up with about 5 or 6 different, largeish modules.
QuoteIf there is an overhead in accessing modules from rep_ex, does this apply to a global rep_ex calling a module function, too? That would be much more serious!
No, it doesn't apply to that.
QuoteYeah, that's what I meant. Not one module for every individual GUI interaction, one for every inventory item etc, but one big module for ALL GUI interactions, one for all inventory etc. So you'd end up with about 5 or 6 different, largeish modules.
That's not a bad idea ... I'll bear it in mind for 2.71.
Ok, beta 15 is now up. This tidies up some bits and bobs to make 2.7 more release-worthy.
Now, that definitely is the last beta that I'm planning. The next version should hopefully be RC1.
* Added GUI OnClick handler to provide a more intuitive way to handle clicks on the GUI background.
I suppose this is related to the disappearance of GUI_MDOWN and GUI_MUP. What do I replace my GUI_MUP code with, now?
Good point. I kinda presumed that nobody actually used M_UP, and that the new OnClick would replace M_DOWN. If you find it useful, I can add it back.
Very useful indeed. I have some code that, for compatibility, is only called when the player's mouse moves up.
Besides, wasn't it vital for verb coins? I thought it was...
Quote from: Rui "Erik" Pires on Sun 30/01/2005 21:20:46
Very useful indeed. I have some code that, for compatibility, is only called when the player's mouse moves up.
Besides, wasn't it vital for verb coins? I thought it was...
Yeah, I use that function, too.
Ok, no worries, I'll add an enum for it.
It should actually still work in this version if you use the GUI_MUP, it's just that I didn't create a new-style name for the event.
Ah yes it does, if I uncheck "Enforce object-style" it works fine! Thanks for the tip.
Quote from: Pumaman on Sun 30/01/2005 15:49:01QuoteYeah, that's what I meant. Not one module for every individual GUI interaction, one for every inventory item etc, but one big module for ALL GUI interactions, one for all inventory etc. So you'd end up with about 5 or 6 different, largeish modules.
That's not a bad idea ... I'll bear it in mind for 2.71.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=501
Quote from: Pumaman on Sat 29/01/2005 10:33:33QuoteWould it be possible for the compiler to support operators (at least + and *) in array declarations?
This is actually non-trivial to add but I'll bear it in mind.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=500
Quote from: Pumaman on Sun 30/01/2005 21:18:45that the new OnClick would replace M_DOWN.
Hm, I used GUI_MDOWN to be able to change the cursor mode with a right click even when over the main GUI, since on_mouse_click isn't triggered then.
How would I do that now since OnClick isn't called when the mouse is over a GUI control?
And since we have tracker entries for label background color (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=295) and border color (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=296), I propose to rename Label.Color to Label.TextColor.
BTW, CJ, the new OnClick can't replace M_DOWN, because experimentation has showed me that it actually processes it UPON CLICKING. And some code should only be processed UPON THE MOUSE BUTTON BEING DEPRESSED, so that releasing it would "cancel and return to the previous thingie". Which is the way I did things. And after moving my (event== GUI_MDOWN && data==MIXER) to the gMixer OnClick handle and finding it did NOT work anymore, I had to move it back.
Heh. Looks like you can't remove or replace anything without risking these situations... ::)
QuoteAdded Button.TextColor property
Perfect timing ... I was just in need of that property!
QuoteAdded confirmation prompt in script editor if you choose "Discard and exit";
Thank you very very much ...Ã, ;D
Quote from: Pumaman on Wed 26/01/2005 20:45:28QuoteOne question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?
Good point. It's a bit difficult with unhandled_event though, because the second parameter can mean different things depending on the first one, so an enum wouldn't really work. It's a bit messy, come to think of it.
Ah, yeah I didn't notice the second parameter has different values for different things like
look at for object is 0 but
look at for hotspot is 1. And rearanging them now would mean the engine will not be backward compatible with games made in earlier versions if AGS.
Quote from: Scorpiorus on Mon 31/01/2005 17:10:58
Quote from: Pumaman on Wed 26/01/2005 20:45:28QuoteOne question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?
Good point. It's a bit difficult with unhandled_event though, because the second parameter can mean different things depending on the first one, so an enum wouldn't really work. It's a bit messy, come to think of it.
Ah, yeah I didn't notice the second parameter has different values for different things like look at for object is 0 but look at for hotspot is 1. And rearanging them now would mean the engine will not be backward compatible with games made in earlier versions if AGS.
*cough* implement unions *cough* :=
QuoteHm, I used GUI_MDOWN to be able to change the cursor mode with a right click even when over the main GUI, since on_mouse_click isn't triggered then.
How would I do that now since OnClick isn't called when the mouse is over a GUI control?
Ok, I'm convinced of the need to keep MDOWN and MUP. I'll add them both back in the next version.
Quote
And since we have tracker entries for label background color and border color, I propose to rename Label.Color to Label.TextColor.
Sounds like a plan, I'll do that.
QuoteBTW, CJ, the new OnClick can't replace M_DOWN, because experimentation has showed me that it actually processes it UPON CLICKING. And some code should only be processed UPON THE MOUSE BUTTON BEING DEPRESSED, so that releasing it would "cancel and return to the previous thingie".
I'm not really sure what you mean, because OnClick is called at exactly the same time as M_DOWN was. Anyway, as I say I'll add it back in the next version.
Quote*cough* implement unions *cough*
Quiet, you :P
I decided to update my main game to the new object-based scripting using AGS v2.7 Beta 15.
It compiles fine, but upon testing, I get
QuoteScript link failed: Runtime error: unresolved import
'InventoryItem::IsInteractionAvailable^1'
Here is an excerpt of my global rep_ex function that contains the part that causes the problem:
function repeatedly_execute() {
// (...)
if (IsGamePaused() == 0) {
if (GetLocationType(mouse.x, mouse.y) == eLocationHotspot) { // if mouse is over a hotspot
Hotspot *temp = Hotspot.GetAtScreenXY(mouse.x, mouse.y); // get hotspot
temp.GetPropertyText("IsExit", hotspotisexit); // check hotspot for exit
}
else if (GetLocationType(mouse.x, mouse.y) == eLocationObject) {
Object *temp = Object.GetAtScreenXY(mouse.x, mouse.y); // get object
temp.GetPropertyText("IsExit", hotspotisexit);
}
else if (GetLocationType(mouse.x, mouse.y) == eLocationCharacter) {
Character *temp = Character.GetAtScreenXY(mouse.x, mouse.y); // get character
temp.GetPropertyText("IsExit", hotspotisexit);
}
else StrCopy(hotspotisexit, ""); // nothing, gui or inventory
if (StrCaseComp(hotspotisexit, "") != 0) { // if mouse is over an exit
if (lastmodebeforeexit == -1) lastmodebeforeexit = mouse.Mode; // store current cursor mode
mouse.Mode = eModeWalkTo; // switch to walk mode
if (StrCaseComp(hotspotisexit, NoTranslateProperty("N")) == 0) mouse.UseModeGraphic(eModeN); // if mouse over exit North, change mouse cursor to North exit sprite
else if (StrCaseComp(hotspotisexit, NoTranslateProperty("NE")) == 0) mouse.UseModeGraphic(eModeNE);
else if (StrCaseComp(hotspotisexit, NoTranslateProperty("E")) == 0) mouse.UseModeGraphic(eModeE);
else if (StrCaseComp(hotspotisexit, NoTranslateProperty("SE")) == 0) mouse.UseModeGraphic(eModeSE);
else if (StrCaseComp(hotspotisexit, NoTranslateProperty("S")) == 0) mouse.UseModeGraphic(eModeS);
else if (StrCaseComp(hotspotisexit, NoTranslateProperty("SW")) == 0) mouse.UseModeGraphic(eModeSW);
else if (StrCaseComp(hotspotisexit, NoTranslateProperty("W")) == 0) mouse.UseModeGraphic(eModeW);
}
else { // if mouse is NOT over an exit
if (lastmodebeforeexit != -1) mouse.Mode = lastmodebeforeexit; // restore cursor mode (and mouse cursor)
lastmodebeforeexit = -1;
if (mouse.Mode == eModeInteract) {
if ((Hotspot.GetAtScreenXY(mouse.x, mouse.y) != hotspot[0]) || (Character.GetAtScreenXY(mouse.x, mouse.y) != null) || (Object.GetAtScreenXY(mouse.x, mouse.y) != null)) { // if mouse is over a hotspot, character or object
if (IsInteractionAvailable(mouse.x, mouse.y, eModeInteract)) { // if interaction is defined
mouse.UseModeGraphic(eModeUsermode1); // change mouse cursor to interaction indicator
}
else { // if hotspot interaction is NOT defined
mouse.UseDefaultGraphic(); // restore normal mouse cursor
}
}
//--- THE FOLLOWING PART CAUSES THE ERROR:
else if (InventoryItem.GetAtScreenXY(mouse.x, mouse.y) != null) { // if mouse is over an inventory item
InventoryItem *temp2 = InventoryItem.GetAtScreenXY(mouse.x, mouse.y); // get item
if (temp2.IsInteractionAvailable(eModeInteract)) { // if interaction for item is defined
mouse.UseModeGraphic(eModeUsermode1); // change mouse cursor to interaction indicator
}
else { // if interaction for item is NOT defined
mouse.UseDefaultGraphic(); // restore normal mouse cursor
}
}
//---
else { // if mouse is anywhere else
mouse.UseDefaultGraphic(); // restore normal mouse cursor
}
}
}
}
// (...)
}
I'm just getting used to this, so I'm sure I'm missing something obvious here.
Edit:
Changed
Hotspot.GetAtScreenXY(mouse.x, mouse.y) != null
to
Hotspot.GetAtScreenXY(mouse.x, mouse.y) != hotspot[0]
since hotspot 0 is returned if there's no hotspot there.
What I mean is that I put some MDOWN code in the GUI OnCLick handler, and it didn't work anymore. Furthermore, the kind of behaviour I expected and which WASN't there made me assume that OnClick is not really being called when the player CLICKS on it, but rather CLICKS AND RELEASES, which - I've noticed - is the stardard way of AGS processing, which makes sense 99% of the time. For the other 1%, we praise God, CJ, AGS and M_UP/M_DOWN.
Either that, or the click upon the button in the GUI overrode it, which don't make much sense anyway.
EDIT - though it don't make much sense, it seems to be what's happening.
function gAction_Click(GUI *theGui, MouseButton button) {
if (lstAction.SelectedIndex==lstAction.ItemCount-1) {
...and so on, and so on. If this is a valid check, I have no idea why clicking in the last item in the listbox doesn't work. And it does work in GUIM_DOWN/UP.
Yep, the same for me, seems like "InventoryItem::IsInteractionAvailable" just isn't linked with a certain engine's function.
Well spotted yes it's a bug, I'll fix it.
:)
Yes, that's because the GUI OnClick handler isn't called if you click on a GUI control, only if you click on the GUI background.
Ah. Heh. Well, in that case it could never replace GUI_MDOWN. ;)
We have a tracker entry for ENTER_ROOM_AFTER_FADEIN (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=479), should we rename eEventEnterRoom to eEventEnterRoomBeforeFadein to avoid confusion?
QuoteWell spotted yes it's a bug, I'll fix it.
Ah, ok, thanks. I thought I made a mistake when converting my script. :)
Edit:
I meant ENTER_ROOM_
AFTER_FADEIN of course. :P
Quote from: strazer on Wed 02/02/2005 02:45:13
We have a tracker entry for ENTER_ROOM_BEFORE_FADEIN (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=479), should we rename eEventEnterRoom to eEventEnterRoomBeforeFadein to avoid confusion?
Sounds like a plan, I'll do that.
And maybe rename the "Talking view" button in the Characters pane to "Speech view" to be consistent with the SpeechView property?
In fact, I'd suggest naming stuff closer to the respective property name, i.e.
No diagonal loops -> Diagonal walking
Can be walked through -> Solid
Edit:
Hm, we have a tracker entry for completely disabling diagonal walking (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=224), BASS-style.
It seems to me the DiagonalWalking property name is a bit ambiguous. Maybe it should be called DiagonalLoops or something?
Edit 2:
Is it possible to only exclude a struct name from the autocomplete feature?
If I try it putting "// $AUTOCOMPLETEIGNORE$" after the struct name, it disappears from the list, but none of the members for instances of the struct are autocompleted anymore.
Edit 3:
The manual still refers to "player" as an alias to character[EGO] which is not being updated.
Is there a way that the script can stop a control's click function from being called, because I've got a GUI where it seems to only work VERY intermittently: I even added a Dsiplay in there as pretty much the first hting the click function does, and it only comes up some of the time, and sometimes it shows the wrong control.ID too...
This might just be more of the GUI_MDOWN thing, though...
Quote from: strazer on Tue 01/02/2005 02:20:21
Hotspot.GetAtScreenXY(mouse.x, mouse.y) != hotspot[0]
since hotspot 0 is returned if there's no hotspot there.
Here's an intersting one, you can give HS 0 a script-o-name, but presuambaly that's only valid in that room. Maybe there should be a global script name or #define for the background hotspot?
I'd like to request an eEventSaveGame, similar to eEventRestoreGame, which would get called JUST AFTER a SaveGameSlot (I THINK that's the name) command before the screen refreshes. This is not an idle request, and that's why I'm posting in this thread. With the savegame command now being called when the script ends, we should be able to detect when the game has been saved so we can do some changes immediatly, even before the screen refreshes.
QuoteAnd maybe rename the "Talking view" button in the Characters pane to "Speech view" to be consistent with the SpeechView property?
In fact, I'd suggest naming stuff closer to the respective property name, i.e.
No diagonal loops -> Diagonal walking
Can be walked through -> Solid
Good ideas, done for beta 16.
QuoteHm, we have a tracker entry for completely disabling diagonal walking, BASS-style.
It seems to me the DiagonalWalking property name is a bit ambiguous. Maybe it should be called DiagonalLoops or something?
Good point, done.
QuoteIs it possible to only exclude a struct name from the autocomplete feature?
If I try it putting "// $AUTOCOMPLETEIGNORE$" after the struct name, it disappears from the list, but none of the members for instances of the struct are autocompleted anymore.
Not at present, no -- if you do as you describe it will ignore the whole struct.
Quotethe manual still refers to "player" as an alias to character[EGO] which is not being updated.
Whereabouts is that? I did a quick search of the manual but couldn't find anything.
QuoteIs there a way that the script can stop a control's click function from being called, because I've got a GUI where it seems to only work VERY intermittently: I even added a Dsiplay in there as pretty much the first hting the click function does, and it only comes up some of the time, and sometimes it shows the wrong control.ID too...
Can you elaborate ... do you mean the GUI or the control's OnClick; if the latter, what type of control is it? Does it not work on just one, or all the controls? Can you provide an example?
QuoteI'd like to request an eEventSaveGame, similar to eEventRestoreGame, which would get called JUST AFTER a SaveGameSlot (I THINK that's the name) command before the screen refreshes.
Sounds like a reasonable request. However, I am very aware of the feature creep that seems to be affecting this version, and I would like to get things settled down for an RC1.
Quote from: Pumaman on Sun 06/02/2005 16:46:40
Quotethe manual still refers to "player" as an alias to character[EGO] which is not being updated.
Whereabouts is that? I did a quick search of the manual but couldn't find anything.
Reference -> Scripting global variables
Quote from: Pumaman on Sun 06/02/2005 16:46:40
Quote
I'd like to request an eEventSaveGame, similar to eEventRestoreGame, which would get called JUST AFTER a SaveGameSlot (I THINK that's the name) command before the screen refreshes.
Sounds like a reasonable request. However, I am very aware of the feature creep that seems to be affecting this version, and I would like to get things settled down for an RC1.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=505
How about a "Script O-Name" display in the Characters pane similar to the GUIs and Objects pane?
Quote from: strazer on Sun 06/02/2005 18:59:11
Reference -> Scripting global variables
Thanks, I'll fix it.
Quote
How about a "Script O-Name" display in the Characters pane similar to the GUIs and Objects pane?
Well, the silly thing is I couldn't find anywhere to put it. I suppose it could go to the right of the Script Name box without looking too silly.
Any chance of a GP_NUMINVITEMS for GetGameParameter?
I use the mouse wheel to let the user scroll through his inventory items, jumping to the last one when he reached the first one.
Since it seems a character's InventoryQuantity array is only as big as the number of inventory items in the game, I can't use AGS_MAX_INV_ITEMS as a starting point for the while loop to find the last item since it produces an out-of-bounds error.
Edit:
Nevermind, I use InvWindow.ItemAtIndex and InvWindow.ItemCount now, much better!
Edit 2:
Quoterenamed Can Be Walked Through to Solid
Since you also reversed its behaviour, the tooltip needs an update. So does the tooltip for "Diagonal loops" I suppose.
Maybe they should read "
Whether other characters can walk straight through this character" and so on?
QuoteSounds like a reasonable request. However, I am very aware of the feature creep that seems to be affecting this version, and I would like to get things settled down for an RC1.
I can understand that, but this is more than a feature. While it's not in, the functionality of 2.7 will not be the same as the previous one. I am recompiling one of my template's code, and until I get this one, the code will remain broken, because the script relies on first saving the game and then extracting the screenie from the recently saved game. What happens NOW is that naturally it extracts a NULL, since the game ISN't actually saved until later on the script. I have tried working around it in MANY ways, believe you me... but unfortunately, I do think this is a case of "something that got broken during beta". That's the reason I posted here in the first place, instead of in a suggestion thread, where it would belong were it not about a previously-working thingammy.
Rui - thats why you need to use DynamicSprite.CreatefromBackground or whatever it is, to make a sprite from the current background... or anyway, you could set a variable and then check for the variable in the next repeatedly_execute,...
CreateFromBackground? Damn, why don't I keep up to date... thanks!
And about the ree.execute thing... heh, trust me, I did MANY rep.execute thingies. NONE of them worked well, because there are more factors here.
Quote from: strazer on Sun 06/02/2005 20:12:52
Any chance of a GP_NUMINVITEMS for GetGameParameter?
Ugh, GetGameParameter looks so ugly now in comparison to the new OO stuff. But I mustn't get carried away, we're done with objectising things for now!
I'll see what I can do.
QuoteSince you also reversed its behaviour, the tooltip needs an update. So does the tooltip for "Diagonal loops" I suppose.
Hehe well spotted, I'd better fix those.
QuoteI am recompiling one of my template's code, and until I get this one, the code will remain broken, because the script relies on first saving the game and then extracting the screenie from the recently saved game.
This is precisely the reason why DynamicSprite.CreateFromScreenShot was added at the same time as the save game functionality changed. Bearing this in mind, do you still require the eEventSaveGame feature?
Quote from: Pumaman on Sun 06/02/2005 22:45:39
Ugh, GetGameParameter looks so ugly now in comparison to the new OO stuff. But I mustn't get carried away, we're done with objectising things for now!
I'll see what I can do.
As I wrote in my edit above, I don't need it anymore since ItemCount and ItemAtIndex work much better.
As for objectizing, yeah, that would be nice, but is not that important. We can always add it to the tracker.
Heh, no, thanks CJ. After SSH pointed it out, I went to try it and it even worked better than before! You know, sometimes you write straight by curved lines... (or something)
I find that sometime Scripot-o-name for objects in a room dont update the autocompleter in the editor, if I load the script just after editing the object...
Also, why are Object x and y capitalised?
And it would be nice if I could insert spaces after my commas in function calls without losing the tooltip... what I mean is if you go back and edit the call later, and retype the comma it might give ytou the enumerated completions for the next arg for the function, but it doesnt autouinsert the space and if you type a space the enum completion list disappears...
QuoteI find that sometime Scripot-o-name for objects in a room dont update the autocompleter in the editor, if I load the script just after editing the object...
Ah yes, I think I see why this is happening, I'll fix it.
Quote
Also, why are Object x and y capitalised?
Because all the new OO properties start with a capital letter. So your question might be, why aren't the character x and y capitalised. The reason for that is that changing it would require people to rework tons and tons of code, for no real advantage.
Quote
And it would be nice if I could insert spaces after my commas in function calls without losing the tooltip... what I mean is if you go back and edit the call later, and retype the comma it might give ytou the enumerated completions for the next arg for the function, but it doesnt autouinsert the space and if you type a space the enum completion list disappears...
Yeah I know, it's a bit fiddly this, I'll take a look.
QuoteThe reason for that is that changing it would require people to rework tons and tons of code, for no real advantage.
I'm either a sucker for consistency or a nitpicker, but I would like to have them capitalized. :P
If object-based scripting is enforced, a lot of code has to be reworked anyway, so why not capitalize them there?
Edit:
mouse.ChangeModeGraphic doesn't work properly with the UseInv mouse cursor.
It works if it is the current cursor mode, but each time you cycle to it with mouse.SelectNextCursorMode, it resets to the active inv item's sprite.
Quote
I'm either a sucker for consistency or a nitpicker, but I would like to have them capitalized. ...
I have the same preference as Strazer. Perhaps it's possible to have both and disallow the lowercase version(s) if "object-based scripting is enforced".
Quote from: strazer on Tue 08/02/2005 16:05:06
I'm either a sucker for consistency or a nitpicker, but I would like to have them capitalized. :P
If object-based scripting is enforced, a lot of code has to be reworked anyway, so why not capitalize them there?
I have the same preference as Strazer. Perhaps it's possible to have both and disallow the lowercase version(s) if "object-based scripting is enforced".
For the sake of a capital letter, I simply can't justify making people change so much code -- especially as "x" and "y" are extremely difficult to Find & Replace due to their length. I forsee far more complaints if they were changed than if they're left alone.
Quote
mouse.ChangeModeGraphic doesn't work properly with the UseInv mouse cursor.
It works if it is the current cursor mode, but each time you cycle to it with mouse.SelectNextCursorMode, it resets to the active inv item's sprite.
Use SetGameOption with OPT_FIXEDINVCURSOR to stop this behaviour.
Maybe both should be allowed for consistency's sake... also, mouse.x and mouse.y should really be capitals, too, now...
EDIT:
Also, could we have a ModuleRequired or ModulePresent function, that can be used to check for the presence of some other module, after all, there may be dependencies between modules and it would be nice if we could specify this in some formal way... alterntaively a require keyword like Perl...
EDIT 2:
If you import a module that you are allowed to edit the properties of, you still cannot edit it's permissions.... is this right?
EDIT 3:
If you do something like this, it doesn't work:
#define OFFSET -1
x = y + OFFSET;
because it sees +- and gets confused...
EDIT 4:
enums for Cutscene Skiptype, SetDialogOption state, SetSpeechStyle, SetVoiceMode, please! The first one is the only one I actually use, but I always have to look it up in the manual...
EDIT 5:
Although in the builtin enum section, CursorMode says it is used by mouse.UseModeGraphic, the entry fro that function says it takes an int...
EDIT 6:
If I use player.Previousroom in a room script, it tell me that it is not a public member of character...
Quote
Also, could we have a ModuleRequired or ModulePresent function, that can be used to check for the presence of some other module, after all, there may be dependencies between modules and it would be nice if we could specify this in some formal way... alterntaively a require keyword like Perl...
If there were a ModulePresent function it would be nice if it could also be used iteratively to get a list of modules. Some kind of "require" keyword would probably be a better solution though.
I have been heavily using the module manager and it works great. I experienced a couple of crashes using beta-15 but haven't seen any with beta-16. The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".
The only thing that is awakward is going through edit-test iterations. You have to open the module manager, select the module, edit the module, close the module manager, test the changes. It would be nice if this could be stream-lined somehow in some future version.
I am extremely pleased, great work and thanks ...
Rick
Quote from: SSH on Wed 09/02/2005 07:53:59If you do something like this, it doesn't work:
#define OFFSET -1
x = y + OFFSET;
because it sees +- and gets confused...
Yeah, it will reasonably report an error. A general solution would be to enclose a macro definition with braces:
#define OFFSET (-1)
Quote from: RickJ on Thu 10/02/2005 06:43:10If there were a ModulePresent function it would be nice if it could also be used iteratively to get a list of modules. Some kind of "require" keyword would probably be a better solution though.
Or what about a "#error" directive, so we could raise errors upon compiling(pre-processing)?
For example, somebody declares a module name as a #defined constant (or it can be done automatically by AGS) and a client module checks for it:
#ifndef MODULE_BLAH
#error Error: Can't find module BLAH!
#endif
One thus can report an error or possibly do other useful stuff like providing an alternative code to replace a module functionality with, etc.
I appreciate it's not a very mistakes-safe solution and can be annoying for simple dependences but yet rather flexible when there is a more complex connecting mechanism with module version checking etc. I am not sure about how widely it would be used and it of course depends on amount of work to implement the #error directive.
Quote
#ifndef MODULE_BLAH
#error Error: Can't find module BLAH!
#endif
One thus can report an error or possibly do other useful stuff like providing an alternative code to replace a module functionality with, etc.
This appeals to me because of the possibility of providing alternatives if a needed module is not found. What comes to mind is the case where some features of Module-A use some functionality provided by Module-B. Using this method one could define dummy functions, variables, or whatever to disable the dependent features thus allowing Module-A to compile and it's other features used. Perhaps there should be several error levels such as: #abort, #error, #warning.
QuoteAlso, could we have a ModuleRequired or ModulePresent function, that can be used to check for the presence of some other module, after all, there may be dependencies between modules and it would be nice if we could specify this in some formal way... alterntaively a require keyword like Perl...
Thinking about this, I think the easiest solution is Scorpiorus' #error suggestion.
QuoteIf you import a module that you are allowed to edit the properties of, you still cannot edit it's permissions.... is this right?
Correct, if you are not the module's author, then you have no right to start restricting what other people can do with it.
QuoteIf you do something like this, it doesn't work:
Code:
#define OFFSET -1
x = y + OFFSET;
because it sees +- and gets confused...
That's the way #defines work, and why they're bad. It's the same in C and other preprocessors.
Quoteenums for Cutscene Skiptype, SetDialogOption state, SetSpeechStyle, SetVoiceMode, please! The first one is the only one I actually use, but I always have to look it up in the manual...
Yeah, it'd be good to bring these up to date.
QuoteAlthough in the builtin enum section, CursorMode says it is used by mouse.UseModeGraphic, the entry fro that function says it takes an int...
Well spotted, I'll fix it.
QuoteIf I use player.Previousroom in a room script, it tell me that it is not a public member of character...
That's because it has a capital R. Use autocomplete, man! :P
QuoteI have been heavily using the module manager and it works great.Ã, Ã, I experienced a couple of crashes using beta-15 but haven't seen any with beta-16.Ã, Ã, The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".Ã, Ã,Â
Hmm, that's slightly worrying -- I thought the editor issues were fixed in beta 15.
QuoteThe only thing that is awakward is going through edit-test iterations.Ã, Ã, You have to open the module manager, select the module, edit the module, close the module manager, test the changes.Ã, It would be nice if this could be stream-lined somehow in some future version.Ã, Ã,Â
Yeah, I appreciate this. Some sort of direct access to the module script from the main menu would be handy.
QuoteI am extremely pleased, great work and thanks ...
Glad you like it :)
Quote
QuoteAlso, could we have a ModuleRequired or ModulePresent function, that can be used to check for the presence of some other module, after all, there may be dependencies between modules and it would be nice if we could specify this in some formal way... alterntaively a require keyword like Perl...
Thinking about this, I think the easiest solution is Scorpiorus' #error suggestion.
Yeah, I like his idea also. Perhaps #warn, #info should be included as well, so if one wished the compile could be allowed to complete but a message still generated indicating what happened.
*** Edit *** removed unreleated quotes
QuoteQuoteI have been heavily using the module manager and it works great. I experienced a couple of crashes using beta-15 but haven't seen any with beta-16. The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".
Hmm, that's slightly worrying -- I thought the editor issues were fixed in beta 15.
I'll keep my eyes open. If it happens again I chase it for you..
QuoteQuoteThe only thing that is awakward is going through edit-test iterations. You have to open the module manager, select the module, edit the module, close the module manager, test the changes. It would be nice if this could be stream-lined somehow in some future version.
Yeah, I appreciate this. Some sort of direct access to the module script from the main menu would be handy.
I think it would be ok if there were short-cuts or menu picks to edit the previously edited module script and header.
Quote from: Pumaman on Fri 11/02/2005 19:30:37
QuoteIf you import a module that you are allowed to edit the properties of, you still cannot edit it's permissions.... is this right?
Correct, if you are not the module's author, then you have no right to start restricting what other people can do with it.
But I am the module author. I started creating the module in one game and then exported it, added it to another game and then expanded it in the new game... maybe you need a "allow users to edit permissions" permission, too!
Quote
That's the way #defines work, and why they're bad. It's the same in C and other preprocessors.
I think C does actually understand the unary "-" there properly in the example I give.
Quote
QuoteIf I use player.Previousroom in a room script, it tell me that it is not a public member of character...
That's because it has a capital R. Use autocomplete, man! :P
I spelled it wrong in my post, but not in the game. It gives that message with BOTH a lower and capital R
Quote
QuoteYeah, I like his idea also. Perhaps #warn, #info should be included as well, so if one wished the compile could be allowed to complete but a message still generated indicating what happened.
Those would of course require the compiler to support warnings, which is something that may be added in a future version.
QuoteBut I am the module author. I started creating the module in one game and then exported it, added it to another game and then expanded it in the new game... maybe you need a "allow users to edit permissions" permission, too!
To be honest, I'm not too bothered with the permissions thing. It was a bit of a silly thing to add, which I put in on a whim, and I really can't be bothered with fiddling around with it.
QuoteI think C does actually understand the unary "-" there properly in the example I give.
Amazingly enough it does indeed -- you learn something new every day. Anyway, putting parenthesis round the -1 as Scorpiorus suggests should fix it.
QuoteI spelled it wrong in my post, but not in the game. It gives that message with BOTH a lower and capital R
I just gave it a quick test and it worked fine; does PreviousRoom appear in the autocomplete list when you type "player." ?
Are you sure you're using the latest versions of all the editor files?
Quote from: Pumaman on Sat 12/02/2005 12:14:14
QuoteI spelled it wrong in my post, but not in the game. It gives that message with BOTH a lower and capital R
I just gave it a quick test and it worked fine; does PreviousRoom appear in the autocomplete list when you type "player." ?
Are you sure you're using the latest versions of all the editor files?
Oops, I must conclude in the end that I did have a typo in it, becuase I deleted it and typed it again using autocomplete and it works now. :-[
This came up in the beginner's questions forum...
We have the functions EnableRegion / DisableRegion.
We also have the functions RemoveWalkableArea / RestoreWalkableArea.
The inconsistency in naming may be a little confusing to n00bs.
(then again this may be largely irrelevant with the new 00 system)
Well, since EnableRegion/DisableRegion disappear in 2.7, hopefully that should solve the inconsistency.
Right, beta 17 is now up. It fixes up a few minor things, and adds the IMport/Export Single GUI feature.
Now, as far as I'm aware, the only things that still need to be done for 2.7 are as follows:
* module support for rep_exec, on_key_press, etc
* update Intro To Scripting tutorials to reflect OO
If there's anything else that needs to be done and I've forgotten, please do say so.
Quote from: Pumaman on Sat 13/11/2004 21:02:00
Changes from Beta 16 to Beta 17:
* Added export/import single GUI function.
* Added enums for parameters to StartCutscene, SetDialogOption, SetSpeechStyle and SetVoiceMode.
* Fixed object and hotspot o-names not being available in the script editor if you had only just created them.
;D Yay! go CJ! I might stop complaining now... for a little while!
Quote from: Pumaman on Sun 13/02/2005 16:20:37
If there's anything else that needs to be done and I've forgotten, please do say so.
You need to make a Valentine's Day reference in the thread title. ;)
Don't you think this version is the best chance you're ever going to get to fix the associativity of mathematical operators?
And the jump to OO scripting is a pretty big change, what about making this version 3.0? Or is that reserved for when AGS goes 3D? ;D
Great work as always!
Single GUI import/export and #error are just in time. :)
EDIT: And I like this Valentine thingy on opening the editor!Ã, :=
I have to agree, with the amount of changes and the rather large change to scripting, why not make this 3.0? Unless you have something -amazing- planned for that ^_-
Nooooo! Don't make it 3.0!
I won't be able to resist moving to the new version, and then I'll have to rescript my WIP games...
Ummm... you dont HAVE to rescript, just don't check "enforce object oriented scripting"
#ifndef AGS_STRING_LENGTH
#define AGS_STRING_LENGTH 200
#endif
If you indent the second line with a tab, you get
QuoteParse error: unexpected '#'
Quote from: Snarky on Sun 13/02/2005 19:58:46
Don't you think this version is the best chance you're ever going to get to fix the associativity of mathematical operators?
Yeah, it might be worth doing now, I guess, since everything else is changing.
Quote
And the jump to OO scripting is a pretty big change, what about making this version 3.0? Or is that reserved for when AGS goes 3D? ;D
The major version number should only change when there's been a pretty much full rewrite of the application, which this isn't. Except if you're the author of UltraEdit of course, in which case incrementing the major version number means you added icons to the menus.
QuoteIf you indent the second line with a tab, you get
Parse error: unexpected '#'
You and your tabs ;)
I'll get it fixed.
Quote from: Pumaman on Mon 14/02/2005 19:20:12
The major version number should only change when there's been a pretty much full rewrite of the application, which this isn't. Except if you're the author of UltraEdit of course, in which case incrementing the major version number means you added icons to the menus.
Yeah, the last time it changed from V1 to V2 was nearly a complete rewrite, and even that large change from DOS RoomEdit to WIN RoomEdit didn't make it into V3.
I think if the "Make my game" feature is rewritten and made into an icon for easier execution it can be made V3 then! ;D
Has something changed in the last beta regarding the vertical position of button text? The text is at the very top edge, touching the button ouline almost. Perhaps it is just my perception but I could have sworn that previously there was a margin at the top of the button. Is it my perception or has something changed?
Also don't you think the text should be centered vertically as is currently done horizontally? I suppose something like that is in the tracker somewhere?
I also had a crash when importing a particular TTF font file. Other TTF fonts work just fine. If there is any interest I can post the TTF file that caused the problem, otherwise I'll just dispatch it to the bit bucket and move on. Just let me know.
Cheers
*** Edit ***
Ok, I found out what changed. When I crashed the editor importing a new TTF font into slot 4, slot 4 then containd the messed up font. After that AGS crashed whenever I selected that font, so I couldn't import over it. I ended up having to revert back to the default fonts to get rid of it. That operation changed the font I was using for the buttons. So here is the conclusion: Default font-0 when used on a GUI button ends up touching the top border. Using an imported TTF Arial 12pt on the button leaves an acceptable margin at the top of the button. So I wasn't imagining things after all. I guess you can pretty much disregard most of the above but still let me know if you would like a copy of the TTF that cause the original problem.
At the risk of embarrasing myself, I seem to be having problems with the "Walk off screen edge" interactions: they don't seem to be running at all for me. Now, I haven't got this game in an older version and I never used them before, so I wonder if someone else could double-check this, please...
EDIT: I foudn the problem. I wanted to walk on an area that was also a hotspot, but the hotspot's walkto was set outside the hotspot (and outside the Top of Screen marker). Everytime I clicked walkto on the hotspot, it walked to the walkto point rather than where I clicked. This is DESPITE me NOT having "Don't automatically move char in walk mode" set in game options, which according to the tooltip thereof should mean that it behaved how I wanted. Something is wrong here , eithr in the documentation or the behaviour. I worked around it by putting
if (mouse.Mode==eModeWalkto) player.Walk(mouse.x, mouse.y) else ProcessClick...
in on_mouse_click
QuoteAlso don't you think the text should be centered vertically as is currently done horizontally? I suppose something like that is in the tracker somewhere?
Indeed: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=180
QuoteHas something changed in the last beta regarding the vertical position of button text? The text is at the very top edge, touching the button ouline almost.
This could well be related to using a TTF, where the font can draw upwards whereas a SCI font cannot.
QuoteI also had a crash when importing a particular TTF font file. Other TTF fonts work just fine. If there is any interest I can post the TTF file that caused the problem, otherwise I'll just dispatch it to the bit bucket and move on. Just let me know.
Coudl you upload the TTF, please -- t'would be handy for me to check the problem.
QuoteI wanted to walk on an area that was also a hotspot, but the hotspot's walkto was set outside the hotspot (and outside the Top of Screen marker). Everytime I clicked walkto on the hotspot, it walked to the walkto point rather than where I clicked.
This is by design, the hotspot walk-to points are used in all cursor modes (except Look if you choose its appropriate option).
If you don't want this behaviour, the workaround is as you scripted it.
Quote from: Pumaman on Sun 13/02/2005 16:20:37If there's anything else that needs to be done and I've forgotten, please do say so.
Quote from: Pumaman on Thu 27/01/2005 20:39:39
Quote
Display room info on "Areas" pane (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=356)
Should be an easy one and results in one less tracker entry.
These two sound reasonable, and I agree it would be a good time to clean them up.
QuoteThis could well be related to using a TTF, where the font can draw upwards whereas a SCI font cannot.
Yeah, I think that's exactly what happened.
Quote
Coudl you upload the TTF, please -- t'would be handy for me to check the problem.
I just tried to duplicate the problem using a new game and it seemed to work OK. However the game I am currently working on has a problem importing it. The problematic font is in the main game directory. I have imported it to slot-4 so now if you open the game and select slot-4 in the fonts tab AGS crahes.
http://www.gaia-spa.com/project/ags/IniFileGame_V002.zip
Quote
If there's anything else that needs to be done and I've forgotten, please do say so.
Just an observation regarding the previous lazy evaluation discussion ... Having a "break" instruction would be helpful in avoiding many of the difficulties previously discussed. For example ....
// Instead of doing this, which produces a bounds check exception
while ((i<SIZE)&&( (buff!=0))) {
// do something ....
i++;
}
// One could do this instead
while (i<SIZE) {
if (buff==0) break;
// do something ....
i++;
}
Setting i=SIZE is not quite adequate because many times it is desireable to retain the value of i (to operate on the next token for example). The workaround is to use another flag of course; it's just not as clean as break. Since adding "break" is possibly easier than implementing "lazy eval"and could possibly get done sooner, I thought I would add this little bit to the previous discussion and leave the rest to your good judgement.
Oh and I liked my Valentime spalsh!!! Maybe next year AGS could pour me a beer instead of giving me a picture? 8) I think this should get a higher priority than that "Make My Game" button everyone always talks about. ;)
Just thinking:
Wouldn't UpdateInventory be better arranged as a method of each InvWindow, or of each character?
Also it might be nice if GUI buttons had a ProcessClick method to simualte them being pressed, but from a script (to allow keyboard shortcuts)
Also, if you miss a semicolon from the end of a module header (in this case the last line of the header) you can get the strange error "Cannot declare body of imported function" or something like that...
edit:
Also, if you do CTRL-E after you just closed the interaction editor in a room, the room script does NOT come up. If you then change room screen and back again it works OK
edit 2:
if I access player.Room in the script, I sometimes get the error "(null) is not a public member of character"...
edit 3:
It would be nice if the debug console and single-step stuff mentioned if you are in a module script
edit 4:
Also, it would be nice if we could find out if the current room had the "Hide player" checkbox set
QuoteAlso, it would be nice if we could find out if the current room had the "Hide player" checkbox set
if (player.on == 0) {
Quote from: strazer on Thu 17/02/2005 12:44:19
QuoteAlso, it would be nice if we could find out if the current room had the "Hide player" checkbox set
if (player.on == 0) {
Is that in the manual? I can't find it and it isn't in the autocomplete, either...
It DOES compile, though!
Right, it's not in the manual and is hidden from the autocomplete.
It's just one of those things you pick up along the way. Check the link in my sig for more.
Cor, I never realised how much good stuff you've got in there, Strazer. Can't it be made an appendix to the CHM manual? ;D
Since I update it regularly, I'd prefer it to be a link or a Wiki-style part of the online manual (http://www.adventuregamestudio.co.uk/manual/).
Quotejust tried to duplicate the problem using a new game and it seemed to work OK. However the game I am currently working on has a problem importing it. The problematic font is in the main game directory. I have imported it to slot-4 so now if you open the game and select slot-4 in the fonts tab AGS crahes.
Thanks, I'll look into it.
QuoteJust an observation regarding the previous lazy evaluation discussion ... Having a "break" instruction would be helpful in avoiding many of the difficulties previously discussed.
Good point -- "break" or lazy evaluation would be handy, but I'm not convinced they're necessary for 2.7.
QuoteWouldn't UpdateInventory be better arranged as a method of each InvWindow, or of each character?
Perhaps it should be per-character, but ideally you shouldn't need to use it since Add/LoseInventory deal with it for you, so I'm not too concerned about it.
QuoteAlso it might be nice if GUI buttons had a ProcessClick method to simualte them being pressed, but from a script (to allow keyboard shortcuts)
You could always just call their handler method directly...
QuoteAlso, if you miss a semicolon from the end of a module header (in this case the last line of the header) you can get the strange error "Cannot declare body of imported function" or something like that...
I'll check the error message when this happens
QuoteAlso, if you do CTRL-E after you just closed the interaction editor in a room, the room script does NOT come up. If you then change room screen and back again it works OK
This is because Ctrl+E is mapped to Freehand drawing tool and overrides the global menu if you're in the Areas screen. I guess it needs to be remapped.
Quoteif I access player.Room in the script, I sometimes get the error "(null) is not a public member of character"...
Can you provide an example, I can't replicate this.
QuoteIt would be nice if the debug console and single-step stuff mentioned if you are in a module script
Yeah, I guess that would be handy, I'll think about it.
QuoteCor, I never realised how much good stuff you've got in there, Strazer. Can't it be made an appendix to the CHM manual?
strazer, I just realised, there's no link to your page from the AGS Resources page. Mind if I add one?
Quotestrazer, I just realised, there's no link to your page from the AGS Resources page. Mind if I add one?
Sure, go ahead.
Quote from: Pumaman on Thu 17/02/2005 20:10:40
QuoteWouldn't UpdateInventory be better arranged as a method of each InvWindow, or of each character?
Perhaps it should be per-character, but ideally you shouldn't need to use it since Add/LoseInventory deal with it for you, so I'm not too concerned about it.
It doesn't really bother me as I'm suing only 1 inventory anyway, but I use a loop to drop all inv at one point and use Update after that: it was then I noticed it wasnt really consistent with the rest of inv handling
Quote
QuoteAlso it might be nice if GUI buttons had a ProcessClick method to simualte them being pressed, but from a script (to allow keyboard shortcuts)
You could always just call their handler method directly...
Not if you're in a module you can't, becuase handlers have to be in the global script, and thus come AFTER modules are compiled. Maybe the generic solution is to have the global script as just another (albeit default) module, and then you can manually place modules before or after the global script...
Quote
Quoteif I access player.Room in the script, I sometimes get the error "(null) is not a public member of character"...
Can you provide an example, I can't replicate this.
I'll see if I can knock up a simple example tomorrow
I have just chanced on a certain similarity between struct and its instances names where the members list doesn't pop up:
script header:
struct TYPE_NAME {
int x;
};
struct TActor {
int x;
};
global script:
Ã, TYPE_NAME name;
Ã, or
Ã, TYPE_NAME name[10];
Ã, TActor Actor;
Ã, or
Ã, TActor Actor[10];
The members list doesn't pop up:
name.
name[1].
Actor.
Actor[1].
EDIT:
I don't want to start a separate thread for this but I have just noticed that when a game is restored the engine informs run-time plugins with AGSE_RESTOREGAME (that's ok) but it also triggers AGSE_ENTERROOM afterwards. And it becomes a problem when AGSE_ENTERROOM is used for purging objects left from the previous room as it would also purge everything just after the game is restored.
Quote from: SSH on Thu 17/02/2005 23:00:10
Quote
Quoteif I access player.Room in the script, I sometimes get the error "(null) is not a public member of character"...
Can you provide an example, I can't replicate this.
I'll see if I can knock up a simple example tomorrow
I can't reproduce the problem at all. Strangely enough, it was happening in a similar way to the .PreviousRoom thign I mentioned earlier: and as soon as I quit AGS and restarted it, the problem went away.... I think there is actually a bug in there: not on any specific method, but rather having AGS open editing a long time somehow screws up the room script compilation!!!
At least the workaround is save the game, restart AGS and reload, but I guess its a pretty hard bug to track down!
Quote from: SSH
I can't reproduce the problem at all. Strangely enough, it was happening in a similar way to the .PreviousRoom thign I mentioned earlier: and as soon as I quit AGS and restarted it, the problem went away.... I think there is actually a bug in there: not on any specific method, but rather having AGS open editing a long time somehow screws up the room script compilation!!!
Quote from: RickJ
I have been heavily using the module manager and it works great. I experienced a couple of crashes using beta-15 but haven't seen any with beta-16. The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".
This sounds a lot like the crash I experienced a a while back. I also had the editor open for a long time but haven't had a problem since.
QuoteSure, go ahead.
Thanks, have done.
QuoteNot if you're in a module you can't, becuase handlers have to be in the global script, and thus come AFTER modules are compiled. Maybe the generic solution is to have the global script as just another (albeit default) module, and then you can manually place modules before or after the global script...
Ah yeah I see your point. This needs further consideration.
QuoteI have just chanced on a certain similarity between struct and its instances names where the members list doesn't pop up:
Ah, well spotted, I'll get it fixed.
At least, the Actor problem can be fixed easily, the "name" problem is more tricky and I may leave fixing it on the backburner for now.
QuoteI don't want to start a separate thread for this but I have just noticed that when a game is restored the engine informs run-time plugins with AGSE_RESTOREGAME (that's ok) but it also triggers AGSE_ENTERROOM afterwards. And it becomes a problem when AGSE_ENTERROOM is used for purging objects left from the previous room as it would also purge everything just after the game is restored.
Well, AGSE_LEAVEROOM allows you to purge things when leaving the room.
ENTERROOM will indeed be called after restoring a game, because the game does switch to another room, and plugins may need to be notified of this, depending on what they're doing.
QuoteI can't reproduce the problem at all. Strangely enough, it was happening in a similar way to the .PreviousRoom thign I mentioned earlier: and as soon as I quit AGS and restarted it, the problem went away....
Hmm, that is strange .. has anyone else experienced a problem like this?
Well, beta 18 is now up. This really should be the last beta -- the next release will be RC1 unless there's a very good reason why not.
Quote* Added script module support for game_start, on_key_press, on_mouse_click and repeatedly_execute.
Nice, thank you!
Will you add _always and on_event as well?
Bug report:
If I rename a character that's referred to in a dialog script, the incompatibility between the old name and the new name will remain hidden until the next time I compile the dialog script.
Now suppose the old name occurs in dialog #1. If I edit dialog #2, I will be unable to save it because of the error in dialog #1. The error is confusing because it mentions a line number (from dialog #1) while actually dialog #2 is being edited on screen.
Hope that made sense :)
Sorry to bother you with this non-OO related bug, but it should be easy to fix...
the image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.
(both in the editor and in the game).
Quote from: Pumaman on Sat 13/11/2004 21:02:00
* Renamed intro.crm to room0.crm, so that it causes no further confusion.
Will importing my beta 17 game do the rename for me, or do I need to manaually move/copy the room file?
It will automatically rename the room file.
I'm sorry if this has already been asked, but, is this going to become the official format of AGS (the new-style coding)? If so, do we all need to be learning it and converting our scripts? I was just wondering because I just read a post by CJ that said the Demo game would become completely obsolete with the release of this version.
Old-style scripting is still supported with the "Enforce object oriented scripting" box: eave it unckeched and the old scripts still work. However, I guess that any new features will only be implemented in the new scripting style, and also the demo game is supposed to illustrate how to program a game in AGS. It no longer fulfils this role in any significant way whatsoever.
However, I am going to release my OOP MAGS game as open-source if you want to have an example...
Quote from: Pumaman on Sat 19/02/2005 19:48:28At least, the Actor problem can be fixed easily, the "name" problem is more tricky and I may leave fixing it on the backburner for now.
Thanks for fixing the "Actor" name problem.Ã, :)
And about "name", does it have something to do with struct's *_NAME being uppercased while having instance's "name" in a lowercase? I just came across these two naming variations and I don't know if there are any other conditions when the members list doesn't appear. Anyway, unlike "Actor", the "name" problem is not very critical since it's only macros that uppercased.
QuoteWell, AGSE_LEAVEROOM allows you to purge things when leaving the room.
Hehe, yeah indeed. There is a note in the API doc that says LEAVEROOM happens before the screen fades-out so I somehow thought the screen is also updated at least once more after the event and thus I wouldn't see any (already purged) graphic objects displayed. But I just tested and that's ok, the fade-out function uses the copy of the screen drawn before LEAVEROOM, I should have tested it in the first place really.
QuoteENTERROOM will indeed be called after restoring a game, because the game does switch to another room, and plugins may need to be notified of this, depending on what they're doing.
But on the other hand, it introduces several difficulties with handling the actual ENTER ROOM event, since it requires to somehow distinguish between ENTER ROOM and ENTER ROOM (load) after restoring.
Quote from: strazerQuote* Added script module support for game_start, on_key_press, on_mouse_click and repeatedly_execute.
Nice, thank you!
Will you add _always and on_event as well?
Great! Thanks a buch for adding them, CJ!
Having RE_always and on_event would be handy. Especially, on_event to easily trace room changes etc.
I'm getting a very strange behaviour with my beta testing! Everyone who tries beta testing this game says that in Room 4 that they can't leave the room if they get there by "natural" methods. However, Al_Ninio say sthat if he uses CTRL-X to teleport there, it does work. Now, it also seems that all my other "player walks off X edge of screen" interactions behave the same way. Even wierder: they work for me when I test the game, no matter which way I do it.
NB, you need to go to room 4 twice as the first time the cutscene will boot you back out again
http://www.2dadventure.com/ags/phbeta4.zip
Also, in this next version, I added a door object in room 4 which can be interacted with to leave the room. THAT works.
http://www.2dadventure.com/ags/phbeta5.zip
This was made with beta 17.
Can anyone throw some light on the problems. There's nothing complicated in the "if player goes of edge" script: just a call to player.changeroom
I created a template from this version so you can fiddle with it, too if you like:
http://www.2dadventure.com/ags/Phbeta.zip
I'd really appreciate it if someone could throw some light on the problem soon, as MAGS closing date is 25th! Worst comes to worst I can just make more door icons or something...
QuoteWill you add _always and on_event as well?
Since there seems to be general support for that, yes I will.
QuoteIf I rename a character that's referred to in a dialog script, the incompatibility between the old name and the new name will remain hidden until the next time I compile the dialog script.
Now suppose the old name occurs in dialog #1. If I edit dialog #2, I will be unable to save it because of the error in dialog #1. The error is confusing because it mentions a line number (from dialog #1) while actually dialog #2 is being edited on screen.
Heh yeah that's a long standing quirk of the dialog system. I guess it should really force a recompile if you change a character's script name.
Quotethe image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.
This is by design, the button enlarges to fit the image. It'd cause too much confusion and "bug reports" if it clipped the image.
QuoteWill importing my beta 17 game do the rename for me, or do I need to manaually move/copy the room file?
Why not try it out and see :P
QuoteI'm sorry if this has already been asked, but, is this going to become the official format of AGS (the new-style coding)? If so, do we all need to be learning it and converting our scripts? I was just wondering because I just read a post by CJ that said the Demo game would become completely obsolete with the release of this version.
Yes, this will be the official scripting format of AGS.
However, just because the old style will be obsolete, doesn't mean it won't be supported. You'll still be able to compile old-style scripts just fine -- it's simply recommended that you use new-style scripting.
QuoteAnd about "name", does it have something to do with struct's *_NAME being uppercased while having instance's "name" in a lowercase?
No, it's because autocomplete doesn't work if the variable is also the name of a member variable in a struct definition (since autocomplete isn't currently clever enough to know that when it finds the definition).
Because the Character struct has a "string name" member, and that's the first definition of 'name' that it finds, any variable called 'name' will be viewed as a string by autocomplete.
QuoteBut on the other hand, it introduces several difficulties with handling the actual ENTER ROOM event, since it requires to somehow distinguish between ENTER ROOM and ENTER ROOM (load) after restoring.
Well, you know that a RESTOREGAME will be followed by ENTERROOM so you can always set a flag in RESTOREGAME and check it in ENTERROOM.
QuoteI'm getting a very strange behaviour with my beta testing! Everyone who tries beta testing this game says that in Room 4 that they can't leave the room if they get there by "natural" methods. However, Al_Ninio say sthat if he uses CTRL-X to teleport there, it does work.
Can you provide more details? Which is room 4? How do we get there by 'natural' methods? In which direction should we be able to leave, and which direction doesn't work?
"Hugh's room", actually experienced as Room 201 in the game (uts set in a hotel) to get to that point in the game (right-click or use buttons in GUI to change cursor mode). Oops its not room 4, room 4 is the corridor. I think the correct room is 8 (not got game on tis computer)
New Game, ESC skips opening cutscene. Walk into the hotel (this works for me by just walking up to the top of the screen, but it seems that others may need to Interact with the Hotel. Talk to the recpetionist behind the desk, CHeck in, end conversation
Interact with lift, choose level 2, interact with door of left room (room 201). ESC skips cutscene, end up back outside room again. Inteact with door marked STAFF to hide in there. ESC skips next cutscene, Interact with left room (201) again. Now, here you should be able to walk tothe left OR bottom of screen to go back to the corridor, but it seems that other people find this doesn't work. For me, it does, so its impossible to debug! And the limits are set a good 10 or so pixels in.
Quote from: Pumaman on Mon 21/02/2005 19:44:50Because the Character struct has a "string name" member, and that's the first definition of 'name' that it finds, any variable called 'name' will be viewed as a string by autocomplete.
Oh, I see what we shouldn't do for now, thanks for making it clear.
QuoteWell, you know that a RESTOREGAME will be followed by ENTERROOM so you can always set a flag in RESTOREGAME and check it in ENTERROOM.
Yep, that's what I did, it just occured to me that ENTERROOM should be a pure analog of the AGS enter room events. So, should I leave that "setting a flag" workaround and rely on such behaviour (i.e. RESTORE -> ENTERROOM) in all future versions or is there a possibility it will be changed? By the way, maybe it's worth to mention about such behaviour in the API page just to avoid confusion?
Quote from: SSHNow, here you should be able to walk tothe left OR bottom of screen to go back to the corridor, but it seems that other people find this doesn't work. For me, it does, so its impossible to debug! And the limits are set a good 10 or so pixels in.
Ok, I tried it the first time and it worked fine (640x400 windowed) but then I tried once more (320x200 fullscreen) and yep I couldn't walk-off either. Maybe it has something to do with a resolution?
Quote
Quotethe image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.
This is by design, the button enlarges to fit the image. It'd cause too much confusion and "bug reports" if it clipped the image.
Er, no, not exactly. If you do 'change button image', then yes indeed, the button resizes to the image you select. That is useful. However, if you change the button size afterwards (either in the GUI editor, or with GUISetButtonSize), the button's clickable area does change, but the image is not cropped or clipped or panned or anything.
I'm making a resizable GUI. To do this I have images of the four edges at maximum size. They'll have to be clipped if the GUI is less than maximum size. And that's not currently possible :(
Quote from: Scorpiorus on Mon 21/02/2005 21:48:32
Quote from: SSHNow, here you should be able to walk tothe left OR bottom of screen to go back to the corridor, but it seems that other people find this doesn't work. For me, it does, so its impossible to debug! And the limits are set a good 10 or so pixels in.
Ok, I tried it the first time and it worked fine (640x400 windowed) but then I tried once more (320x200 fullscreen) and yep I couldn't walk-off either. Maybe it has something to do with a resolution?
Al_Ninio said that he tried various resolutions, fullscreen/windowed etc and it still didnt work for him in any of them. The code in the script run by "Player walks of edge" is just the changeroom method, nothing else so resoultion really shouldn't affect it. Something seems broken in AGS for it to behave so intermittently!
I just thought it maybe screen edges don't work under certain resolutions but I tried again and it worked regardless of resolution this time.
Anyway, here is a savegame file with that room and I can't walk off if I restore from it ( I don't know how I managed to replicate it htis time):
http://www.2dadventure.com/ags/agssave640x400.zip (saved at 640x400)
And I used the original compiled version of the game (phbeta4):
http://www.2dadventure.com/ags/phbeta4.zip
SSH: this is because in room 2 in the Interact With Hotspot event for the hotel, you have a DisableGroundLevelAreas command, which disables room edges.
You never have a EnableGroundLevelAreas command to counteract this.
Therefore if you enter the hotel by interacting with it none of the room edges will work from that point on.
In order to make this sort of problem easier to debug in future, I'll add something to the Ctrl+D display to tell you if ground-level areas are disabled.
QuoteYep, that's what I did, it just occured to me that ENTERROOM should be a pure analog of the AGS enter room events. So, should I leave that "setting a flag" workaround and rely on such behaviour (i.e. RESTORE -> ENTERROOM) in all future versions or is there a possibility it will be changed? By the way, maybe it's worth to mention about such behaviour in the API page just to avoid confusion?
I see your point, yeah you don't want to rely on this sort of 'incidental' behaviour. The problem is that the game script is shielded from this sort of thing, but because plugins hook in at a lower level you'll see every event that actually happens in the engine.
I'm not sure of the cleanest solution to this.
QuoteEr, no, not exactly. If you do 'change button image', then yes indeed, the button resizes to the image you select. That is useful. However, if you change the button size afterwards (either in the GUI editor, or with GUISetButtonSize), the button's clickable area does change, but the image is not cropped or clipped or panned or anything.
I see your point -- the trouble with this now is backwards compatibility. If I change it to clip, there will no doubt be people who find that some of their buttons are suddenly being clipped. I guess some sort of per-button flag would do the trick.
Ooops, I thought that function was room-specific. Ah well, thanks for spotting that, CJ! Glad that it's not a bug in the engine
I just noticed that GUI control script names aren't allowed to contain digits 0..9. I can undestand not wanting a name to begin with a numeral but why not allow them in subsequent character positions. For example it's not possible to use button1, button2, button3, etc for script names. There are a few cases where it makes sense to have names of this form. I was wondeing if this were an oversight or if there were some other motivation to make this restriction.
A user in the Beginner's Forum made the suggestion to rename the help file to agshelp.chm to make clear it is the help file and not program-related data.
Quote from: RickJ on Wed 23/02/2005 17:02:18
I just noticed that GUI control script names aren't allowed to contain digits 0..9. I can undestand not wanting a name to begin with a numeral but why not allow them in subsequent character positions. For example it's not possible to use button1, button2, button3, etc for script names. There are a few cases where it makes sense to have names of this form. I was wondeing if this were an oversight or if there were some other motivation to make this restriction.
Oh yes, I forgot to moan about this earlier, becuase I was too busy moaning about other things ;)
Quote from: RickJ on Wed 23/02/2005 17:02:18
I just noticed that GUI control script names aren't allowed to contain digits 0..9. I can undestand not wanting a name to begin with a numeral but why not allow them in subsequent character positions. For example it's not possible to use button1, button2, button3, etc for script names. There are a few cases where it makes sense to have names of this form. I was wondeing if this were an oversight or if there were some other motivation to make this restriction.
Yeah this has been commented on before, it's basically because I've been too lazy to add a text box validator that allows numbers only after the first character.
QuoteA user in the Beginner's Forum made the suggestion to rename the help file to agshelp.chm to make clear it is the help file and not program-related data.
I guess that can't do any harm -- but since you'd normally open the help file from within AGS, I'm not sure why you really need to access it directly.
QuoteI guess that can't do any harm -- but since you'd normally open the help file from within AGS, I'm not sure why you really need to access it directly.
- Accessing it without the editor running
- ALT-Tabbing between it and the editor
- Opening it in Linux :)
Hi everybody.
Here are a few things which I encountered during my testing of the newest beta of AGS.
====
The following code in the repeatedly execute should move a character (not standing on a walkable area) from one spot to another and then back to the original spot.
if (character[AMB].x == 300) {
Ã, MoveCharacterDirect(AMB,100,220);
Ã, }
else if (character[AMB].x == 100) {
Ã, MoveCharacterDirect(AMB, 300, 220);
}
The character starts at 300,220. It does the very first move to 100,220Ã, as it should. However it get's stuck when it reaches the point. It does not move back again.
====
Why are all my characters walking so slowly? I use the same speed-value as in the previous versions but it looks like slow-motion. Am I the only one with this problem?
====
What evil hardware combination causes the "Test-Game" Feature not to work anymore? If I accidently push "Test-Game" (which I do very often because I am so used to it) not only the game but my whole computer freezes ...
====
I think I mentioned something like this a year ago, however I coudn't find it on the Bug Tracker, so ... what about SetChannelVolume for channel 1 ... it just changes the volume of the abient sound for a split second but it doesn't last.
Is this on the to-do list?
====
When trying to compile an old game (version 2.62) to the newest beta I always get an error in the global script. It says something like
"Error in line 35: 'Object' is a global variable. You can't use it in rooms"
If I look in my global script line 35 ... it's a blank line (between two of these "Section start/end ... do not remove" lines)Ã, ... and I definitly have no global variable called "Object" in my entire script.
====
The "Character solid" checkbox doesn't seem to work for me. I can walk right through the other character as if it were thin airÃ, ;)
====
I hope I didn't sound too harsh.
I am looking forward to your ideas.
Stefan
Quote from: TheMagician on Thu 24/02/2005 14:52:36
The character starts at 300,220. It does the very first move to 100,220 as it should. However it get's stuck when it reaches the point. It does not move back again.
Did this work in 2.62 -- ie. is it related to the beta?
Basically, you have no guarantee that the character will end on the exact co-ordinate you asked it to move to -- it might actually end on X=99 or 101 instead. A better method is to check cAmb.Moving to determine when the character has finished walking.
QuoteWhy are all my characters walking so slowly? I use the same speed-value as in the previous versions but it looks like slow-motion. Am I the only one with this problem?
Character speed hasn't changed in the new version; are you sure you haven't changed the "Anti glide mode" setting?
QuoteWhat evil hardware combination causes the "Test-Game" Feature not to work anymore? If I accidently push "Test-Game" (which I do very often because I am so used to it) not only the game but my whole computer freezes ...
The Test Game feature works for some people but doesn't for others -- this is a long-standing issue and we haven't yet been able to work out what the problem is, unfortunately.
QuoteI think I mentioned something like this a year ago, however I coudn't find it on the Bug Tracker, so ... what about SetChannelVolume for channel 1 ... it just changes the volume of the abient sound for a split second but it doesn't last.
Is this on the to-do list?
Well spotted, I don't believe this is currently on the bug list. I'll get it fixed.
QuoteWhen trying to compile an old game (version 2.62) to the newest beta I always get an error in the global script. It says something like
"Error in line 35: 'Object' is a global variable. You can't use it in rooms"
This is because "object" is now a reserved keyword, so if you have any variables called "object" in your script you need to rename them.
Quote
The "Character solid" checkbox doesn't seem to work for me. I can walk right through the other character as if it were thin air ;)
Both characters must be solid to block each other -- if either character is not solid, they can pass through each other. This behaviour has not changed since 2.62.
Thanks for your reply CJ!
QuoteThe character starts at 300,220. It does the very first move to 100,220 as it should. However it get's stuck when it reaches the point. It does not move back again.
Did this work in 2.62 -- ie. is it related to the beta?
Basically, you have no guarantee that the character will end on the exact co-ordinate you asked it to move to -- it might actually end on X=99 or 101 instead. A better method is to check cAmb.Moving to determine when the character has finished walking.
Ok, I must admit it didn't work in 2.62 as well. However, I made a string which showed me the current x position of the character on the screen ... it was 100, not 99 or 101 .... however ... I'll use the way you suggested with cAmb.Moving.
Actually I am only going through this trouble with a character moving from one point to another back and forth to program a non-blocking Wait command .... you now an invisible character walks from left to right and back and then something is triggered.
... perhaps there is a much better way of doing this which I don't know?
Edit by strazer:
I was able to help him with this by suggesting to use timers:
Interaction:
SetTimer(1, 400);
rep_ex:
if (IsTimerExpired(1) == true) {
// do stuff
}
QuoteCharacter speed hasn't changed in the new version; are you sure you haven't changed the "Anti glide mode" setting?
Grrrrrr ... :P sorry, i didn't check that ... of couse I had the wrong setting.
Quote
This is because "object" is now a reserved keyword, so if you have any variables called "object" in your script you need to rename them.
Ah ... good to know. Are there any more keywords which I should know of? Are they mentioned in the manual?
QuoteBoth characters must be solid to block each other -- if either character is not solid, they can pass through each other. This behaviour has not changed since 2.62.
That's odd. It used to work for me in previous versions but it doesn't in the beta. I checked both characters ... they are solid. I can upload the file tomorrow so you can have a look at it.
EDIT:
I uploaded the room here (http://stefan.lohner-net.de/ags/probleme/solid.zip).
I found a couple of things:
After doing automatic numbering, then dumping dialog scripts, global scripts, etc. and reimporting, the numbering on my first dialog topic's options disappeared. i.e. my five options were numbere &1 to &5 but the &n all disappeared, but just on the options on the first dialog.
Also, it would be nice if leading 0s in sound/voice/room names were not significant: i.e. sound001.ogg would get picked up as sound 1. Obviously there would need to be a priority in case both existed, but I don't care which way around it is.
Quote from: SSH on Fri 25/02/2005 08:58:49
Also, it would be nice if leading 0s in sound/voice/room names were not significant: i.e. sound001.ogg would get picked up as sound 1. Obviously there would need to be a priority in case both existed, but I don't care which way around it is.
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=139
Quote from: TheMagician on Thu 24/02/2005 20:57:45
Ok, I must admit it didn't work in 2.62 as well. However, I made a string which showed me the current x position of the character on the screen ... it was 100, not 99 or 101
In that case, the problem is probably because you are calling MoveCharacter every game loop if X=100, and because he might not move a pixel on the first frame of the move, it will keep resetting the move and get nowhere. You can use the debug console to check if this is happening.
QuoteActually I am only going through this trouble with a character moving from one point to another back and forth to program a non-blocking Wait command .... you now an invisible character walks from left to right and back and then something is triggered.
An easier approach might just be to do this:
if (!cAmb.Moving) {
cAmb.Walk(100, 220, eNoBlock, eAnywhere);
cAmb.AddWaypoint(300, 220);
}
that will set it up to walk between the two points continuously.
Quote
Ah ... good to know. Are there any more keywords which I should know of? Are they mentioned in the manual?
Yes, they are listed in the Upgrading to 2.7 section:
http://www.adventuregamestudio.co.uk/manual/UpgradingTo27.htm
QuoteThat's odd. It used to work for me in previous versions but it doesn't in the beta. I checked both characters ... they are solid. I can upload the file tomorrow so you can have a look at it.
You're quite right, a bug was introduced in beta 6 which stopped solid characters from blocking properly. I'm surprised it's taken this long to be spotted -- but well done for doing so! I'll get it fixed.
QuoteAfter doing automatic numbering, then dumping dialog scripts, global scripts, etc. and reimporting, the numbering on my first dialog topic's options disappeared. i.e. my five options were numbere &1 to &5 but the &n all disappeared, but just on the options on the first dialog.
That's odd -- I just tried it myself but I couldn't replicate the problem. Rather strange one.
Would it be possible for the autocomplete feature to display custom enums according to the order they were written in the enum definition instead of alphabetically?
I like to group them according to what is used most often.
Edit:
Also, it would be nice if we could do this with global/room variables:
enum_doorstatus door1status = eDoorClosed;
instead of having to provide a number.
Edit 2:
The manual entry for Character.Walk still refers to the character[charid].walking variable.
And for the example, it says the script would not continue until the character has reached his destination. Isn't the default eNoBlock now?
QuoteWould it be possible for the autocomplete feature to display custom enums according to the order they were written in the enum definition instead of alphabetically?
I like to group them according to what is used most often.
Unfortunately I don't think this is possible. The scintilla text editor control that AGS uses requires that the autocomplete list is in alphabetical order.
QuoteAlso, it would be nice if we could do this with global/room variables:
enum_doorstatus door1status = eDoorClosed;
Oops good point, I'll fix that.
QuoteThe manual entry for Character.Walk still refers to the character[charid].walking variable.
And for the example, it says the script would not continue until the character has reached his destination. Isn't the default eNoBlock now?
Well spotted, thanks, I'll fix it.
Ok, RC1 is up -- this fixes a few minor things, and brings the plugin API up to date by adding functions to allow plugins to create objects for the script.
Quote
* Enum variables can now be initialized using the enum options.
Hm, I have this in a script module header:
enum enum_doorstatus {
eDoorOpen,
eDoorClosed,
eDoorLocked
};
and this on top of room 1:
enum_doorstatus door1status = eDoorClosed;It says:
Quote
'Room 1' script
Error (line3): Expected ',' or ';', not 'eDoorClosed'
ah, hmm, you're right; well spotted, it doesn't work with global variables. I'll fix that -- it currently only works with local variables declared inside a function.
Thanks, Chris, for the pages on how to get back up to speed with all these new and improved changes.... now I'm not that afraid to start with 2.7 without getting lost and crying like a little girl.
tell me, is this version safe now?? To start work in it, as at the begining was written that better not rush with new beta ;D
It's not guaranteed to be "safe" until the Final version is released.
However, now that it has reached the RC stage it is recognised to be more stable than a beta -- but even so, use it at your own risk.
My problem with compiling my game to the newest version of AGS still exists.
The error message reads:
"In 'Plugin definitions' Error (line 35) 'object' is a global var; cannot use as name for local"
I checked every single room script, the global script and the script headers ... there are NO variables called 'object'.
There are also no characters, objects, GUIs, views or anything called 'object'
Another stange thing is that the error occurs in EVERY room of the game if I try to save it in the new version. It always says "Error (line 35)" even if there IS NO line 35 in that room script because it's only 10 lines long.
-- by the way: now that AGS has this big version change ... isn't there a possibility to include at least two ambient sound channels? It would enhance gameplay so much!! --
Which plugins do you have installed? Try removing them and see if it works.
Yeah, it looks like one of your plugins isn't compatible with 2.7 -- try un-selecting each plugin one by one until you find the culprit, then request that the plugin author updates their plugin.
Quote
Script names can now contain the digit 0-9 after the first character.
Was this intended to include GUI buttons as well? Still can't use "gMenu0..gMenu9" for a GUI button script names.
1. I found out that the fire-plugin by Steve McCrea is probably not compatible with version 2.7.
2. If I use "player - go to a different room" interaction in "walk off left screen edge" in the "room interaction editor" it says at the bottom that the text script equivalent is "player.ChangeRoom(2);"
However, if I delete the "player - go to different room" interaction and replace it with a "run script" interaction and type in "player.ChangeRoom(2);" the behaviour is different.
"player - go to a different room" lets the character appear on the right side of the new room if it walked off the left side of the previous room .... which feels correct to me.
However, "Run Script: player.ChangeRoom(2);" lets the character appear at the same coordinates as it left the previous room (so he appears on the left side of the new room if he walked off the left side of the previous room) ...
...is this how it's supposed to be?
Actually, TheMagician, I'm pretty sure the manual does specify that your point 2 is, indeed, meant to be so.
If it does not, my bad. :) But it is meant to be so.
So the only way to SCRIPT a "natural" room change (from left side to right side) is by using "NewRoomEx" ?
Yep.
Yes, the script does not have a command to say "appear on the right hand edge" or anything.
It's not a bad idea though -- perhaps NewRoomEx could accept some special values like LEFT_EDGE and RIGHT_EDGE for the X co-ordinate that would use the room edges rather than having to specify a co-ordinate.
QuoteIt's not a bad idea though -- perhaps NewRoomEx could accept some special values like LEFT_EDGE and RIGHT_EDGE for the X co-ordinate that would use the room edges rather than having to specify a co-ordinate.
That would be perfect!
In other news, I've added a manual page on blocking scripts:
http://www.adventuregamestudio.co.uk/manual/BlockingScripts.htm
because it seems to be an issue that crops up quite frequently in questions here.
Comments on anything that doesn't make sense, etc, are welcome.
Thanks for updating the plugin API, CJ! I'm going to try and test adding managed objects via plugin.
Quote from: Pumaman on Sat 05/03/2005 18:47:56
In other news, I've added a manual page on blocking scripts:
Good work! By the way, is that
room thread kind of a new thing introduced in 2.7? I'm asking because to my experience I was unable to make AGS call scripts while on_mouse_click is running, even those within the room.
EDIT:
Kind of an unrelated note to the RC but how feasible/difficult would it be to have a confirmation (Y/N) dialog to pop up on importing a different sized room background image to prevent accidental resets of room's masks?
Original thread: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19534.0
QuoteKind of an unrelated note to the RC but how feasible/difficult would it be to have a confirmation (Y/N) dialog to pop up on importing a different sized room background image to prevent accidental resets of room's masks?
Unrelated as it may be, after TWO (count 'em, two) stressfull situations where the difference of a single pixel caused me to rebuild all walkables, walkbehinds and hotspots... I totally support this.
Surely, if you don't then save the room, you haven't lost anything?
Quote from: Pumaman on Sat 13/11/2004 21:02:00Blimey, Mother's Day is with us already!
Liar! Mother's day isn't until May 8th! ;) :P
SSH - I don't know, and I don't really care to try it again. But if that IS so, could someone kick me in the backside? HARD? Please?
QuoteWas this intended to include GUI buttons as well? Still can't use "gMenu0..gMenu9" for a GUI button script names.
Now fixed in RC2.
Quote1. I found out that the fire-plugin by Steve McCrea is probably not compatible with version 2.7.
I've fixed RC2 so that this is no longer a problem.
QuoteGood work! By the way, is that room thread kind of a new thing introduced in 2.7? I'm asking because to my experience I was unable to make AGS call scripts while on_mouse_click is running, even those within the room.
Hmm that's a good point, I might have got it slightly wrong. I'll have to check exactly how it works.
QuoteKind of an unrelated note to the RC but how feasible/difficult would it be to have a confirmation (Y/N) dialog to pop up on importing a different sized room background image to prevent accidental resets of room's masks?
Although as SSH says you don't have to save the room, I can appreciate there will be times where you've just made a load of changes and then want to import an updated background. Hence, I've added a confirmation message for this situation as requested.
QuoteLiar! Mother's day isn't until May 8th!
Hehe it's a funny one this -- I don't know why Father's Day is the same around the world, but Mothers Day varies from country to country. Probably just reflects the indecision of women ;)
If I may make a suggestion
I just upgraded from an older version and it gave me a bunch of errors and such, I read them and all but now that I'm going back through to fix things up I've forgotten all the errors, is there any chance that AGS could write a text file with the warnings in it?
Eric
And a further suggestion - if AGS DOES do that, can it be toggleable? I know some people like logs at all times, but I prefer only to have them in case of problems, and even then I'm not all that fond of them.
I can't stress enough how much I love the script module system. Easily my favorite new feature. Thanks again, CJ!
How about a Disable/Enable button in the module manager to help in debugging conflicting modules? I know you can save them to disk, remove them and later load them again, but that's a bit tedious IMO.
Quote from: MrColossal on Sun 06/03/2005 21:29:40
I just upgraded from an older version and it gave me a bunch of errors and such, I read them and all but now that I'm going back through to fix things up I've forgotten all the errors, is there any chance that AGS could write a text file with the warnings in it?
That's a pretty good idea -- it's also easy to accidentally skip over a message and then wonder what you missed. I'll look into it.
QuoteI can't stress enough how much I love the script module system. Easily my favorite new feature. Thanks again, CJ!
Glad you like it :)
QuoteHow about a Disable/Enable button in the module manager to help in debugging conflicting modules? I know you can save them to disk, remove them and later load them again, but that's a bit tedious IMO.
Something like the plugin manager's check boxes? That's a reasonable request; I may postpone it for 2.71 though.
Question about Button.Width ??
It appears that if I change a GUI button's width at runtime the button text retains it's old position instead of being recentered on the button's new extent. Should Button.Width be read only, should the text be re-centered, or is all as intended?
I don't think this is a bug specifically about this new version as I haven't checked but character.animating does not see when a character is animating it's idle view.
Is this a bug or something that was just never added?
Eric
edit: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=15174.0 and I see now that Geoffkahn brought this up but then forgot about his own post.
Quote from: RickJ on Tue 08/03/2005 00:30:51
Question about Button.Width ??
It appears that if I change a GUI button's width at runtime the button text retains it's old position instead of being recentered on the button's new extent. Should Button.Width be read only, should the text be re-centered, or is all as intended?
I just tried this out and the button text was re-centered correctly when I changed the width. Can you provide an example where it doesn't work?
QuoteI don't think this is a bug specifically about this new version as I haven't checked but character.animating does not see when a character is animating it's idle view.
This is deliberate. People tend to use loops like:
while (cEgo.Animating) Wait(1);
to wait until a specific animation has finished -- so you wouldn't want the idle animation to return 1, since it could block forever.
So basically yes, this is by design.
Quote
I just tried this out and the button text was re-centered correctly when I changed the width. Can you provide an example where it doesn't work?
Here is a code snippet where I was trying to modify button width depending upon how wid the text is. Previously I was calculating a width but in light of your response I tried just setting it to a constant value (i.e. thinking that I may have calculating crap). So I still get the same behavior. I am using a the control index/pointer/casting thing so I wonder if that has something to do with it?
I still have this gut wrenching feeling that it is I who is in error rather than the engine. Anyway here is the code snippet and a
zip file (http://www.gaia-spa.com/project/ags/WinBlu_V000A00.zip) of the whole thing in case you need it.
//-------------------------------------------------------------------
function show_menu(string widget) {
//
// External References:
// gMenu - Main menu bar containing buttons as menu items.
//-------------------------------------------------------------------
int wid, iid, event;
GUIControl *gui_element;
string item;
string action;
// Find the specified widget
wid = 0;
while (wid<WinBlu_MAXWIDGETS) {
if (StrCaseComp(widget, Widget[wid].Name)==0) {
iid = 0;
while (iid<WinBlu_MAXITEMS) {
gui_element = gMenu.Controls[iid];
if (gui_element==null) { // No more menu slots available
iid = WinBlu_MAXITEMS;
}
else { // OK found a menu slot
event = get_item(wid, iid, item, action);
if (event==WinBlu_NULL) {
gui_element.AsButton.Visible = false;
gui_element.AsButton.SetText("");
}
else {
gui_element.AsButton.Visible = true;
gui_element.AsButton.SetText(item);
// Button width was originally 25 in editor.
// Text is not centered correctly after change
gui_element.AsButton.Width = 18;
}
}
iid++;
}
return true;
}
wid++;
}
return false;
}
Just wanted to mention that "SetChannelVolume" does not work if the specified channel is not currently playing.
Perhaps the manual could mention that.
Btw, I have started using the new GUI stuff with a companion module and it's working out very well. It takes a little getting used to ... I think because of being familiar with the old way rather than having difficulty understand the new one. I am really enjoying working with the new stuff.
I know this was previusly requested and noted but I would like to briefly mention it again in light of my recent experiences. In doing the above work it quickly became apparent that both gui and companion module must travel toghter. Having a way of combining a module and one or more GUIs into a single exportable/importable would be really cool and useful IMHO. So I am hopeful something like this can make it's way in to some future version of AGS.
Anyway, I just wanted to let you know how much fun I am having :D
Cheers
Rick
Hi again.
Noticed some more things:
1. I think I found a bug in "character.AddWaypoint".
Here is a little example script:
====
#sectionstart room_a // DO NOT EDIT OR REMOVE THIS LINE
function room_a() {
// script for room: Player enters screen (after fadein)
cFra.Walk(100,100, eBlock, eWalkableAreas);
Wait(30);
SetGlobalInt(66, 1);
}
#sectionend room_a // DO NOT EDIT OR REMOVE THIS LINE
#sectionstart room_b // DO NOT EDIT OR REMOVE THIS LINE
function room_b() {
// script for room: Repeatedly execute
if((cFra.Moving == false) && (GetGlobalInt(66) == 1)) {
cFra.Walk(100,100,eNoBlock,eAnywhere);
cFra.AddWaypoint(84,164); // MoveCharacterPath(FRA,84, 164); // <-- Error in this line ------
cFra.AddWaypoint(76,164); // MoveCharacterPath(FRA,76, 164);
cFra.AddWaypoint(63,169); // MoveCharacterPath(FRA,63, 169);
}
}
====
The error reads: "character.move: int direct must be eANYWHERE or eWALKABLEAREAS"
which I think is a wrong error message.
I assume that "character.AddWaypoint" always needs a preceeding "character.Walk". However, in the example above the character already stands on the coordinate the "character.Walk" points to. Therefore it is skipped and the script continues with "character.AddWaypoint" which then doesn't work anymore.
Also, "character.AddWaypoint" produces the same (incorrect) error message if you have a plain room script with only this in your "Player enters screen after fade in" section:
====
cFra.Walk (100,100,eBlock,eAnywhere)
cFra.AddWaypoint (84,164); // <-- Error in this line --------
cFra.AddWaypoint(76,164);
====
I think this is caused because "cFra.Walk" is set to blocking. Perhaps the manual could mention that.
btw: in AGS 2.62 you could have both these things without problems.
~~~~~~~~~~~
2. In the auto-complete of "game. " in the script editor there is an entry called "game_speed_modifier". I couldn't find anything about it in the manual ... so what does it do?
~~~~~~~~~~~
3. In the global variables section the AGS help says:
mouse.y Mouse Y co-ordinate when the script was started (0-199)
I think it can take more values than 0-199 can't it?
1.) Hm, if I add a seventh script module to my game, it crashes on startup with
QuoteError: Unable to create local script: Runtime error: too many active instances
regardless of what room the player starts in.
If I remove the module, it works fine. Nothing special in it, only a struct with one static member function (Edit: It also quits if the module is completely empty.).
Is there some kind of limit to anything that we should know of?
2.) Is there currently way to make characters completely black other than using additional views and sprites?
Since there's no Character.Tint function, I tried using Region.LightLevel 0 (editor)/ -100 (script), but that doesn't make him completely black for some reason.
If I then try to also tint the region 0,0,0/100, the lightlevel automatically increases to 200. ???
I currently use a black-tinted object as character replacement, but that's kind of awkward. Why aren't there saturation and luminance parameters for regions? (Not that I understand what they are, but at least it works. :) )
Can someone explain the difference between brightness and luminance to me?
3.) I've noticed something:
// room script
function repeatedly_execute_always() {
if (object[0].Moving == false) {
if (object[0].X == 300) object[0].Move(0, object[0].Y, 3);
else object[0].Move(300, object[0].Y, 3);
}
string labeltext;
StrFormat(labeltext, "%d / %d", object[0].X, object[0].Y);
lblTestlabel.SetText(labeltext);
}
function on_mouse_click(MouseButton button) {
if (button == eMouseMiddle) object[0].Y = GetViewportY()+mouse.y;
}
If you click the middle mouse button while the object is moving, the object's Y-coordinate changes to the current mouse Y-position, it keeps moving, and it displays the new Y-coordinate in the label, as it should be.
However, once the object reaches either end of the screen, it jumps back to the Y-coordinate it started from and the label displays this Y-coordinate again.
4.) Since the Character.View property holds only the currently used/locked view, how about a NormalView property so we can determine the normal view of the character?
It could even replace the ChangeView function since that takes a single parameter anyway.
If that's too much to ask, would you be so kind to make the (undocumented) .defview variable available in strict mode as well? That's the one holding the normal view number, right?
5.) If objects have "Use region tint and lighting" enabled, shouldn't they also be affected by SetAmbientTint?
Quote from: RickJ on Wed 09/03/2005 02:30:26
Here is a code snippet where I was trying to modify button width depending upon how wid the text is.
Rick, the text is correctly being centered within the button. However, it looks wrong because you have a fixed 25x20 image for the button, so even if the button is only sized 18x20, the 25x20 image is drawn and will run off the right side of the button.
QuoteJust wanted to mention that "SetChannelVolume" does not work if the specified channel is not currently playing.
Fair point -- I'll mention it in the manual.
QuoteHaving a way of combining a module and one or more GUIs into a single exportable/importable would be really cool and useful IMHO. So I am hopeful something like this can make it's way in to some future version of AGS.
Yeah I can appreciate that -- maybe that's something for 2.71.
Quote
Anyway, I just wanted to let you know how much fun I am having
Glad you're enjoying it :)
Quote1. I think I found a bug in "character.AddWaypoint".
Here is a little example script:
Well spotted, thanks for the bug report. This is indeed broken, I shall get it fixed.
Quote2. In the auto-complete of "game. " in the script editor there is an entry called "game_speed_modifier". I couldn't find anything about it in the manual ... so what does it do?
There are several properties in the "game" object that are internal and shouldn't be touched by the script. Basically, if it's not documented in the manual, you don't need it.
Quotemouse.y Mouse Y co-ordinate when the script was started (0-199)
I think it can take more values than 0-199 can't it?
If your game is 320x240/640x480 then yes it could be up to 239; I'll reword it to say "320-resolution" to clarify what it means.
QuoteHm, if I add a seventh script module to my game, it crashes on startup with
Ah crap, adding rep_exec_always support for modules has had a side effect of limiting the number of modules you can have. I'll look into it.
QuoteIs there currently way to make characters completely black other than using additional views and sprites?
Since there's no Character.Tint function, I tried using Region.LightLevel 0 (editor)/ -100 (script), but that doesn't make him completely black for some reason.
Well, setting the LightLevel to 0 should make him as good as completely black. I suppose you could use SetAmbientTint but that would have an effect on everything else on the screen as well, obviously.
I agree that the whole tinting this is rather inconsistent at the moment. Because regions originally only worked on characters, the objects had a specific Tint function added. But now that objects can use region tints, it would make sense for characters to be able to have a specific tint setting as well.
QuoteIf you click the middle mouse button while the object is moving, the object's Y-coordinate changes to the current mouse Y-position, it keeps moving, and it displays the new Y-coordinate in the label, as it should be.
However, once the object reaches either end of the screen, it jumps back to the Y-coordinate it started from and the label displays this Y-coordinate again.
Ah -- as with characters, you shouldn't change an object's position while it's moving. I'd better document that.
Quote4.) Since the Character.View property holds only the currently used/locked view, how about a NormalView property so we can determine the normal view of the character?
It could even replace the ChangeView function since that takes a single parameter anyway.
That's a good point -- should have thought of that originally. I'm a bit concerned about removing ChangeView now that we're into the RC stage although it would be a clean way of doing it. I'll certainly add a read-only NormalView property, anyway.
Quote5.) If objects have "Use region tint and lighting" enabled, shouldn't they also be affected by SetAmbientTint?
Hmm that's an odd one, I'll look into it.
QuoteI'm a bit concerned about removing ChangeView now that we're into the RC stage although it would be a clean way of doing it.
I say do it while you still can. I doubt most people have started a serious project with v2.7 yet.
Either way, thanks! :)
Quote
Quote
5.) If objects have "Use region tint and lighting" enabled, shouldn't they also be affected by SetAmbientTint?
Hmm that's an odd one, I'll look into it.
I'm sorry, it does indeed work. I was using a sprite where you can't see that effect very well. I've tested it with a white one and it works. Sorry for the trouble.
Another small suggestion: How about the PlaySound function returning the chosen channel?
Hey CJ, I found a bug, but I am not quite sure if it is a feature or a bug. If it is a feature, though, it doesnt make much sense:
In 2.7 RC2, if there is a hotspot, and an object above it, but the object is not visible, the interaction with the object runs.
I dont know whether it was like that in previous releases.
Quote
Rick, the text is correctly being centered within the button. However, it looks wrong because you have a fixed 25x20 image for the button ...
Ah man... I knew it was me but I just couldn't see the obvious. Sorry for the false alarm... :-[
QuoteAnother small suggestion: How about the PlaySound function returning the chosen channel?
That'd be easy to do, so I think I can slip that in.
QuoteHey CJ, I found a bug, but I am not quite sure if it is a feature or a bug. If it is a feature, though, it doesnt make much sense:
In 2.7 RC2, if there is a hotspot, and an object above it, but the object is not visible, the interaction with the object runs.
I dont know whether it was like that in previous releases.
I just tried it but it worked fine for me. Which interaction is running, and can you provide an example of the problem?
Whoops, my bad.
I had changed the cursor marker positions...
Ok, RC3 is now up. That's it for 2.7 -- there will be bug fixes only between now and the Final.
Possible Bug: After copying Room2.crm to game directory, RoomEditor->RefreshList doesn't add the new room file to the list of editable rooms. If I am misunderstanding the purpose of the RefreshList function then I appologize for being a nusiance. ;)
Would you please consider fixing GUI button image clipping, as it would be something I'd be heavily using? (plus it seems to be a matter of simply adding a boundary check)...
You suggested implementing a per-button flag, for backwards compatibility, that sounds like a good idea (a SetGameParameter would also be fine)
Pretty please with sugar on top?
Quote
Quote
Quotethe image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.
This is by design, the button enlarges to fit the image. It'd cause too much confusion and "bug reports" if it clipped the image.
Er, no, not exactly. If you do 'change button image', then yes indeed, the button resizes to the image you select. That is useful. However, if you change the button size afterwards (either in the GUI editor, or with GUISetButtonSize), the button's clickable area does change, but the image is not cropped or clipped or panned or anything.
I'm making a resizable GUI. To do this I have images of the four edges at maximum size. They'll have to be clipped if the GUI is less than maximum size. And that's not currently possible :(
Quote* Increased max overlays from 10 to 20.
Cheers.
Quote from: RickJ on Mon 14/03/2005 06:51:21
Possible Bug: After copying Room2.crm to game directory, RoomEditor->RefreshList doesn't add the new room file to the list of editable rooms. If I am misunderstanding the purpose of the RefreshList function then I appologize for being a nusiance. ;)
I just tried this out but it worked fine -- does it fail repeatedly for you, or was it just the once?
QuoteWould you please consider fixing GUI button image clipping, as it would be something I'd be heavily using? (plus it seems to be a matter of simply adding a boundary check)...
Sorry, but I have to draw the line somewhere. There are always more features that people want slipped in, and then the new version never gets released.
Besides, there's nothing to stop it being added in 2.71 beta 1, it's just that I really want to get 2.7 out there so people can start getting used to OO scripting.
I have to agree. There are a couple of features I'd like to suggest but holy bajeebers, I really want this version released properly so I can start using it ^_^ It feels like it's been an eternity. I'm one of those people who won't touch the program until it's in it's absolute final release.
Yeah, just check the date of the original beta release, it's exactly 4 months and a day already, if it's not going to be released soon, we'll all rot. :=
Quote
I just tried this out but it worked fine -- does it fail repeatedly for you, or was it just the once?
It failed a couple of times but it was during the same session. I'm upgrading a game to the new version and so created a temp directory and moved all the room files there and reintroduce them back into the game one at a time. The first and second rooms seemed to have a problem being updated in that session.
I just tried adding a third room and UpdateList works now. The editor is now in a new session and I have activated the compiler via "Test" several times. I can't reproduce it now nor can I say fo certain what happened the first time. So I suppose we just write it off as a Windowism.
CursorMode prevmode = mouse.Mode; // save current cursor mode
mouse.Mode = 7; // change to Wait cursor mode
mouse.UseModeGraphic(prevmode); // override cursor graphic to look like the previous one
player.Say("I say some stuff."); // <- problem: Wait cursor reverts to default
mouse.UseDefaultGraphic(); // restore Wait mode graphic to default
mouse.Mode = prevmode; // change to previous cursor mode
It seems the Say command changes to the Wait cursor mode, even if it is already the current cursor mode, thereby restoring the cursor mode graphic, so the Wait cursor is displayed as usual.
Strangely, if I use "Wait(40);" instead of the Say command, it works like intended.
Shouldn't the Say command leave the Wait cursor graphic alone?
(I could of course use mouse.ChangeModeGraphic, but how do I return the sprite slot of the current cursor mode other than (non-universal) if-clauses? Seems like a mouse.Graphic property would be needed for this. And what about animated mouse cursors?)
Edit:
I just realized I could use SayBackground and Wait together, but I really need Say because I want all other background speech to be removed.
Edit 2:
Spelling error in manual: SetGlobalString example: contian -> contain
Strange bug: You can add buttons (and the like) onto a textbox GUI. However, once you do, you won't be able to move them by dragging, or delete them, and they won't show up in the game.
(you can remove them if you unclick 'gui is textbox')
Another one... if you set a character's speech view to something excessively large (e.g. 320 pixels wide) using Sierra-style speech, then once the character starts speaking, the game crashes with an error message "unable to allocate -166 bytes of memory"
And another one... in the dialog editor, you can surround text with /* */ and it will be highlighted as comment. But it is still compiled (and causes errors). But lines starting with * are ignored.
Okay, I'll shut up now as this has nothing to do with the recent OO developments :)
I'm having a bit of trouble accessin an object's X & Y properties. Below is a snippet of room script that procudes a compile error when compiling the line in red. The error is as follows:
"Error (line 49): '(null)' is not a public member of 'Object'."
I also get the error if I try using the script-o-name and also if I try assigning the property to an int variable. I assume I'm overlooking something very obvious but I don;t know what that might be. Perhaps someone here can see what's wrong with what I am trying to do.
function object0_a() {
// script for object0: INTERACT WITH OBJECT
if (player.y<120) {
Display("You can't reach it from up here. You'll have to find a way down the curb.");
}
else {
player.Walk(object[0].X, object[0].Y, eBlock);
GiveScore (2);
oSomething.Visible = false;
player.AddInventory(iKey);
SetDialogOption (0, 3, eOptionOff);
SetDialogOption (0, 4, eOptionOn);
}
}Btw, this line was formerly a MoveCharacterToObject() function and this was the simplest thing I could think of. If there is a better way I'd be glad to have comments about that as well.
Hmmm I made a quick check like:
Display("X=%d Y=%d", oHihi.X, object[0].Y);
and it worked for me.
Hopefully it's not a compiler bug when using them in a function like player.Walk().
This sounds like the intermittent bug that I found when doing Pixel Hunt. Basically, if you save the game (comment out error lines if need be) quit the AGS editor, reload you'll find it now compiles.
I think there must be a memory leak somewhere in the editor that is overwriting some compiler table that contains the list of valid property names of the object , or something like that
I only had this happen after I'd had the editor open in the game for several days, and it happened twice to me. But it is proably performing some specific action that causes this overwrite. To track down this bug, is there any chance that CJ could make an AGS version that logs everything done in the editor in a file, so we could then look back after fidning this occruring again for a list of suspects...?
Thanks Gilbot, SSH
I tried commenting out the offending lines, restarting the editor,and then uncommenting them, but the compile error still remains. I too have seen something like this before only with character.X,Y properties. That time I used the character.SetPosition() function instead and assumed that I had done something wrong.
Anyway here (http://www.gaia-spa.com/project/demo/Archive/DQSOD-T00.00-004.ZIP) is a link to the game where this seems to be reproducible. The offending code can be found commented out on line 49 in the Room Script of Room 102.
QuoteShouldn't the Say command leave the Wait cursor graphic alone?
Currently the Say command does
mouse.UseModeGraphic(6);
I'll modify it to check if the current mode is already Wait, and if so not change the cursor.
QuoteStrange bug: You can add buttons (and the like) onto a textbox GUI. However, once you do, you won't be able to move them by dragging, or delete them, and they won't show up in the game.
Ah yes, this one came up a while back and I forgot to fix it, I'll get it done.
QuoteAnother one... if you set a character's speech view to something excessively large (e.g. 320 pixels wide) using Sierra-style speech, then once the character starts speaking, the game crashes with an error message "unable to allocate -166 bytes of memory"
And another one... in the dialog editor, you can surround text with /* */ and it will be highlighted as comment. But it is still compiled (and causes errors). But lines starting with * are ignored.
Ok, thanks for the info, those two aren't too serious since the likelihood of them occurring is quite small, so I'll leave them for now.
QuoteI'm having a bit of trouble accessin an object's X & Y properties. Below is a snippet of room script that procudes a compile error when compiling the line in red. The error is as follows:
Thanks for posting your game.
The reason for the problem is that you have:
#define X -24000
in your script header.
This is then turning line 49 into:
player.Walk(object[0].-24000, object[0].Y, eBlock);
and the compiler is getting confused and giving up.
I'll fix #defines so that they don't apply to words preceded by a dot operator, because I can't see any useful reason for it to work this way.
Quote
This is then turning line 49 into:
player.Walk(object[0].-24000, object[0].Y, eBlock);
That makes sense. I knew it was something on my end but couldn't think of anything.
I wasn't aware of the "#define x" since I hadn't personally coded it. Thanks for the help.
*** Edit *** Arrrrrgh! I did, I did code it after all!!!! It was a template for setting up #define terms....
Ok, the pre-final is now up.
This is basically the Final version, unless any bugs are discovered. I'll leave the pre-final up for at least 2 weeks to give people a chance to use it and report any issues that they come across.
Quote from: Pumaman on Fri 25/03/2005 13:12:03
I'll leave the pre-final up for at least 2 weeks
Awww, and I had been hoping that you'd do an April 1st thread where you told everyone they'd have to rewrite all their scripts to use the new AGS.... and then tell them it WASNT a joke ;)
if (1.0 < 2.0) Display("Compiles.");
if ((1.0 < 2.0) && (1.0 < 2.0)) Display("Does not compile.");
Quote
Error: Operator cannot be applied to this type
if ((1.0 == 2.0) && (1.0 == 2.0)) Display("Compiles.");
if ((1 < 2) && (1.0 < 2.0)) Display("Does not compile.");
QuoteError: Type mismatch: cannot convert 'int' to 'float'
if ((1 == 1) && (1.0 == 1.0)) Display("Compiles.");
???
I'm getting an editor crash if I edit a room script, exit/save, and then try to edit the script header. It seems to be repeatable for me at this point. I haven't rebooted windows and tried again yet, if that fixes it I'll be back and update this post.
*** Edit ***
After further investigation it appears that the game files are corrupted. Attempting to edit either Global Script or Script Header, without doing anything else casuse a crash. I restored the main game files from a backup I made a couple of days ago and now everything seems to be working. The game that causes the crash can be found at the link below, if that is of any interest.
http://www.gaia-spa.com/project/demo/Archive/DQSOD-T00.00-005.zip
I am able to open the editor.dat file with metapad and see my files in there. I suppose I can just cut and paste to recover. Any advice or cautions would be appreciated. Thanks..
*** Edit ***
The cut and paste thing seems to work, so everything's back. The game is still up there if it's of any use.
*** Edit ***
Well, after editing one of the room scripts a few times I come to find that the editor.dat file is again corrupted, or at least the editor crashes when editing the global script or header. I can recover everything again but I don't think I'll be able to make much more progress until we figure out what's going on here.
*** Edit ***
I have reverted back to the RC3 version and haven't had a problem since. I also did a cleanup of my machine (scan disk, defrag, spybot, regclean, etc), other than a couple scan disk errors from a power button reset a while back there were no anomolies found.
I believe that RC3 version was able to read the same editor.dat file that nade the PreFinal version crash. When I reverted to RC3 I expected that I would need to restore my Global Script and Script Header by cutting and pasting as I describe above, but to my surprise they opened without crashing. I suppose that I may have done the recovery and forgot about it but I don't believe so.
Quote from: Pumaman on Wed 23/03/2005 19:04:31
QuoteAnother one... if you set a character's speech view to something excessively large (e.g. 320 pixels wide) using Sierra-style speech, then once the character starts speaking, the game crashes with an error message "unable to allocate -166 bytes of memory"
And another one... in the dialog editor, you can surround text with /* */ and it will be highlighted as comment. But it is still compiled (and causes errors). But lines starting with * are ignored.
Ok, thanks for the info, those two aren't too serious since the likelihood of them occurring is quite small, so I'll leave them for now.
Tracker'd:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=515
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=516
Ok, I've just returned from an easter break to find that my main hard drive has died, so I'm afraid it's going to be a while before I get things back up and running to continue development of AGS. I'll look at these reported issues whenever I can do so.
*Faints
Heh, well luckily I do have a backup of the AGS code itself, but I didn't think to take a backup of the various add-on libraries etc that it uses, so it's a long process now of finding and downloading them all again.
Let this be a lesson to everyone ... back up EVERYTHING, no matter how trivial it may seem to be. :)
Oh, and never buy a Maxtor hard drive. :-\
Silly question: is there any way we can help?
Quote from: Pumaman on Tue 29/03/2005 14:41:04
Ok, I've just returned from an easter break to find that my main hard drive has died, so I'm afraid it's going to be a while before I get things back up and running to continue development of AGS. I'll look at these reported issues whenever I can do so.
3 days early, CJ
hush, you
Quote from: Traveler on Tue 29/03/2005 15:35:57
Silly question: is there any way we can help?
I don't think there is, really. Thanks for the offer though.
Quote3 days early, CJ
Haha, if only :P
Quote from: Pumaman on Sat 05/03/2005 12:30:46
Yes, the script does not have a command to say "appear on the right hand edge" or anything.
It's not a bad idea though -- perhaps NewRoomEx could accept some special values like LEFT_EDGE and RIGHT_EDGE for the X co-ordinate that would use the room edges rather than having to specify a co-ordinate.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=517
I hate to do this with the harddrive crash and all (my drive crashed a little over a month ago, and it's always a bummer), but I've noticed a sort of bug in the text parser. In a very recent version, the ability to have words with a space in them has been added, which of course is great. So now you can use "pick up" as a synonym to "get". The error I have noticed is that if you have the word "pick" also, either as a synonym to this or as a seperate word, then "pick up" no longer works. It's problematic also if you want to have names "Roger" and "Roger Wilco". "Roger Wilco" will not work. Does this make sense? Thank you.
quick little thing:
I don't know if this is a feature or a bug or anything but if you hold control and scroll the mouse wheel it changes the font size of the autocomplete popup and there's no way to set it back quickly, just trial and error
I also have not checked other AGS versions...
Ok, I've now got things kind of back to normal, enough to have a think about these issues anyway:
QuoteError: Operator cannot be applied to this type
What's probably happened here is I forgot to mark the floating-point < and > operators as returning a bool, so they're passing back 1.0 and 0.0 as the result of the evaluation. Should be a fairly easy fix.
QuoteI'm getting an editor crash if I edit a room script, exit/save, and then try to edit the script header. It seems to be repeatable for me at this point. I haven't rebooted windows and tried again yet, if that fixes it I'll be back and update this post.
Hmm -- I just downloaded the pre-final and the zip file you posted, and I'm able to open it, edit room scripts and then the script header and global script without problems. Has it happened again since you rebooted? Rather strange.
QuoteIn a very recent version, the ability to have words with a space in them has been added, which of course is great. So now you can use "pick up" as a synonym to "get". The error I have noticed is that if you have the word "pick" also, either as a synonym to this or as a seperate word, then "pick up" no longer works. It's problematic also if you want to have names "Roger" and "Roger Wilco". "Roger Wilco" will not work.
Thanks for the bug report, I'll look into that.
QuoteI don't know if this is a feature or a bug or anything but if you hold control and scroll the mouse wheel it changes the font size of the autocomplete popup and there's no way to set it back quickly, just trial and error
Hmm you're right, must be some sort of default behaviour of the text editor control. I'll see if I can switch it off.
Quote
Hmm -- I just downloaded the pre-final and the zip file you posted, and I'm able to open it, edit room scripts and then the script header and global script without problems. Has it happened again since you rebooted? Rather strange.
It's was happening to me all the time until I went back to RC3. I seemd to me that RC3 was able to open one that caused PreFinal to crash. I'll give it a go again when I get a chance. I guess it could be because of the crappy WinME OS I am using.
Also I have noticed that the editor will allow 30 hotspots to be defined but a mask containing more than 16 colors can't be imported. Is this a bug or a limitation of the mask import mechanism?
Ok, Pre-Final 2 is up. What on earth is a PF2, I hear you ask?
Well, since I've had to rebuild my system I can't be sure that AGS is still building properly, plus a few bugs were found so I've fixed them.
I also decided I'd may as well merge in a couple of additions that I was going to leave for 2.71, in the form of Character.Tint and Button.ClipImage.
QuoteAlso I have noticed that the editor will allow 30 hotspots to be defined but a mask containing more than 16 colors can't be imported. Is this a bug or a limitation of the mask import mechanism?
Hmm, I was unable to replicate this. Do you have an example mask bitmap that doesn't work?
Bear in mind it's not the total number of colours on the mask bitmap, rahter it's that they've got to be the first 30 palette slots.
Quote from: RickJ on Sat 02/04/2005 21:59:40
Quote
Hmm -- I just downloaded the pre-final and the zip file you posted, and I'm able to open it, edit room scripts and then the script header and global script without problems. Has it happened again since you rebooted? Rather strange.
It's was happening to me all the time until I went back to RC3. I seemd to me that RC3 was able to open one that caused PreFinal to crash. I'll give it a go again when I get a chance. I guess it could be because of the crappy WinME OS I am using.
Also I have noticed that the editor will allow 30 hotspots to be defined but a mask containing more than 16 colors can't be imported. Is this a bug or a limitation of the mask import mechanism?
maybe you used 16 color image 1??
Oops, I left in some debug code in Pre-final 2: basically, if you call SetGameSpeed it will un-cap the game frame rate rather than setting it to what you wanted. Apologies, I'll get it fixed up.
Does this Knowledge Base entry (http://www.adventuregamestudio.co.uk/kbview.php?id=17) still apply? If so, it should be noted in the manual.
The max number of overlays mentioned in the help file still says 10. It's probably worth checking that those other limits are still valid, too.
Thank you very much for the character tint function. This relieves me of much cheating with the AmbientTint command. Does this mean that region tints will also get luminance settings in the near future?
oh another thing, will this version support 256 color ICONS for EXE file ?? And why older supports only 16 color?? :=
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=12296.msg147022;topicseen#msg147022
Edit:
eEventGUIMouseUp/-Down are missing from the enum reference page.
Quote from: SSH on Mon 04/04/2005 12:24:36
The max number of overlays mentioned in the help file still says 10. It's probably worth checking that those other limits are still valid, too.
While you're fixing the manual, you coudl document character[].on, too!
I love the enum variable type. Thank you, it makes my code so much easier to read. A question I have about it though, is that I noticed I cannot create different enum types that utilize the same parameter names.
i.e.
enum Death {fell, hurt, murdered};
enum Status {happy, hurt, angry};
will not work because both contain "hurt". must it be this way, or is it a bug?
In fact, any name already used anywhere else cannot be used as an enum parameter (i.e. Script-O names, or whatever)
thank you!
Rich
btw, thank you for fixing the parser bug with single and two-word words. works like a charm!
QuoteDoes this Knowledge Base entry still apply? If so, it should be noted in the manual.
Good point, I'll document it in the SetIdleVIew section.
QuoteThe max number of overlays mentioned in the help file still says 10. It's probably worth checking that those other limits are still valid, too.
Well spotted, I'll get it corrected.
QuoteThank you very much for the character tint function. This relieves me of much cheating with the AmbientTint command. Does this mean that region tints will also get luminance settings in the near future?
The lack of luminance in the region tints is a bit of an oversight -- it happened because region tints were the first type to be implemented, and weren't done as thoroughly as the ambient and object tints which came later. This would be a worthwhile addition to a future version, I agree.
QuoteeEventGUIMouseUp/-Down are missing from the enum reference page.
Good point, I'll fix it.
QuoteWhile you're fixing the manual, you coudl document character[].on, too!
I'm not sure about this one, actually -- I haven't yet had time to verify that the .on setting works properly and doesn't cause any strange side effects, so I'd rather it stayed as an unofficial feature for now.
Quoteenum Death {fell, hurt, murdered};
enum Status {happy, hurt, angry};
will not work because both contain "hurt". must it be this way, or is it a bug?
This is the way in which enums are implemented -- it's the same as C/C++. They are not created within a namespace for the enum, because that would mean you'd have to type things like Death.fell and Status.angry to access them, which I had a feeling would prove unpopular.
The solution is to use your own prefixes -- you could do this for example:
enum Death {DeathFell, DeathHurt, DeathMurdered};
enum Status {StatusHappy, StatusHurt, StatusAngry};
Quotebtw, thank you for fixing the parser bug with single and two-word words. works like a charm!
Glad to hear it :)
Quote from: Pumaman on Thu 07/04/2005 19:52:25
QuoteThank you very much for the character tint function. This relieves me of much cheating with the AmbientTint command. Does this mean that region tints will also get luminance settings in the near future?
The lack of luminance in the region tints is a bit of an oversight -- it happened because region tints were the first type to be implemented, and weren't done as thoroughly as the ambient and object tints which came later. This would be a worthwhile addition to a future version, I agree.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=520
Edit:
Is there a chance you could slip in a GetGameParameter option to return the actual number of inventory items used in the game?
Edit 2:
I noticed this in earlier versions too, maybe even v2.62, can't remember:
Using the "Black box out" transition, if I enter a certain room in my game, the room's background displays for a split second before going black and fading in.
Strangely, it does only seem to affect this particular room and I haven't been able to find out why. Besides a big object and a large walkbehind, there's nothing special in there.
Edit 3:
Okay, that last one seems to be related to the slightly slower frame rate in my Windows emulator, making the whole transition look kind of wrong.
I've taken a video in Windows, analysed it and everything is fine.
i encountered a strange bug in pre-final 2.
no idea whether it's my system or ags. but happens to no other programs.
ags disappears from my taskbar when i test my game and quit it by pressing ctrl + q.
it still works perfectly, but it's button isn't there anymore. it reappears when i alt-tab into ags or activate a window.
Dasjoe - I've also had that problem, but not only with AGS - eMule does that sometimes too. So I guess it's not a problem in the program, exactly... maybe something it does is a bit iffy with Windows?
Right, Pre-Final 3 is now up.
What's a pre-final 3, I hear you say?
Well, there's some sort of script editor crash doing the rounds, and I'd like to get it fixed before releasing 2.7. This new PF3 version has a fix for a potential script editor problem, so could the people who were experiencing the crash try it out with this version and see if it's still a problem.
Quote from: strazer on Fri 08/04/2005 02:53:29
Is there a chance you could slip in a GetGameParameter option to return the actual number of inventory items used in the game?
Done in PF3.
QuoteI noticed this in earlier versions too, maybe even v2.62, can't remember:
Using the "Black box out" transition, if I enter a certain room in my game, the room's background displays for a split second before going black and fading in.
Strangely, it does only seem to affect this particular room and I haven't been able to find out why. Besides a big object and a large walkbehind, there's nothing special in there.
Strange, I haven't seen this myself ... if you'd like to upload the specific room or something that demonstrates the problem I'll take a look at it.
Quotei encountered a strange bug in pre-final 2.
no idea whether it's my system or ags. but happens to no other programs.
ags disappears from my taskbar when i test my game and quit it by pressing ctrl + q.
it still works perfectly, but it's button isn't there anymore. it reappears when i alt-tab into ags or activate a window.
Is that specific to Pre-Final 2, or has it always happened? arg, the test game feature is the bane of my life :P
Quote from: Pumaman on Sat 09/04/2005 17:14:55
Quotei encountered a strange bug in pre-final 2.
no idea whether it's my system or ags. but happens to no other programs.
ags disappears from my taskbar when i test my game and quit it by pressing ctrl + q.
it still works perfectly, but it's button isn't there anymore. it reappears when i alt-tab into ags or activate a window.
Is that specific to Pre-Final 2, or has it always happened? arg, the test game feature is the bane of my life :P
i
think it happened to me before 2.7, but it doesn't happen as much as it not shutting down properly (almost every time ;) )
Quote from: Pumaman on Sat 09/04/2005 17:14:55
ags disappears from my taskbar when i test my game and quit it by pressing ctrl + q.
it still works perfectly, but it's button isn't there anymore. it reappears when i alt-tab into ags or activate a window.
Is that specific to Pre-Final 2, or has it always happened? arg, the test game feature is the bane of my life :P
Quote
I got the same problem in 2.62 for 2 weeks, but now it is ok, i don't know why, i didnt installl any new AGS or anything...
I think this is a great progam! It's obviously taken a lot of work and has cool and large community. I've played around in the creator and would like to offer some thoughts.
I know you probably have lots and lots to work on but these are mere idle wishes nothing more :D
I think the area that would be easiest to work on and yet give the best returns - is the work flow for the would be game creator.
Streamlining and improving the GUI can be done by reducing the number of mouse clicks needed where ever possible.
I assume a newbie to the program would work his way through the GUI tools avaliable first rather than jumping in to scripting. Some controls are a little odd there's an if-global-variable statement you can choose on interactions with objects, characters and the like.
In this you choose:
1. The Global Variables Name
-A drop down box would be cool here listing all the variables so far
2. It's value
Choosing to edit the contents of either brings up the same dialog.
It's has two radio buttons and I think is defaulted to "value".
Really this should create two seperate dialogs one specific to each choice. (or it shouldn't come up at all and should be handled one layer down)
Or if you fill both enteries in the pop-up dialog then both enteries should be updated rather than the one that is currently selected by the radio button.
Currently it's a bit inconsistant.
Sorry this is a little hard to describe but there are a few tiny things like this scattered through out the program that might cause a hang-up for a person new to the program.
I think minor changes to GUI would encourage far more people to stick with the creator and also allow others to develop game faster. The downside is, you have more people like me - always wanting more and bugging you :D
Quote from: Balaam on Sun 10/04/2005 11:41:08
I assume a newbie to the program would work his way through the GUI tools avaliable first rather than jumping in to scripting. Some controls are a little odd there's an if-global-variable statement you can choose on interactions with objects, characters and the like.
There is always a bit of a debate to be had around this. Basically, most people when they first use AGS will use the interaction editor, but quite quickly will switch to just using scripting. Because the vast majority of people just use the scripting system, it's difficult to justify spending too much time on the interaction editor side of things.
But as you note, it is important that it works intuitively for people new to the program.
Quote
In this you choose:
1. The Global Variables Name
-A drop down box would be cool here listing all the variables so far
2. It's value
Choosing to edit the contents of either brings up the same dialog.
Perhaps this dialog needs to be better explained in the tutorial ... the purpose of it is that for each side of the expression you can choose either a variable from the drop-down list, or a specific value. So you could select two different variables and compare them, or select a variable on one side and a value on the other.
Looking at it again, I can see how it could be a bit confusing though, because it looks like there is just one pop-up dialog that is brought up by both the Change buttons.
i got the pre-final the day before yesterday- a long time i had refused to even look at the new version because i thought it would be too much of an effort to learn ags again anew.
big mistake.
all things changed really hit the spot. it really makes sense to have an object
based language and learning the new commands is made simple both by the autocomplete and the rewritten help file. ags is as good as ever, and two days later i feel completely at home with 2.7.
chris, it has to be said again, your work really makes it possible for a large comunity to have fun making games. my humble thanks!
In order not to bump the other, older thread:
Quote from: Pumaman on Fri 06/08/2004 22:03:02
QuoteIf I place 'addinventory' and 'newroom' one after the other in a script, then on_event only gets called for the newroom event. A warning might be in order.
Same thing with two consecutive 'addinventory's.
Yeah - I'm thinking about adding some sort of on_event_always to deal with this. A warning wouldn't go amiss, though.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=521
(How about that warning?)
I have been testing the latest version now and there is always one thing wich bother me. In every time I try to press "preview the view" It doesn't work then. So what it wrong with this thing? ???
When using the special "narrator" character in dialog scripts to pop up a message box, the mouse cursor used to initiate the dialog is being displayed.
Shouldn't it be hidden or at least be the Wait or Pointer cursor?
Edit:
Manual -> Tutorial -> Advanced room features -> Character scaling: "The scaling settings effect all CHARACTERS in the game, but not objects."
Edit 2:
According to the manual, UpdateInventory only affects the player's inventory. Since we can now use InvWindows with other characters, shouldn't each InvWindow control have some kind of Update function too?
Nice work on the new release, works like a charm! :D
A little bug I've found: My player character guy only walks around solid characters if he himself is set to solid. If I deactivate solid for him, he walks through other solid characters.
I don't think that's a bug. That behaviour seems perfectly reasonable to me.
Quotei got the pre-final the day before yesterday- a long time i had refused to even look at the new version because i thought it would be too much of an effort to learn ags again anew.
big mistake.
all things changed really hit the spot. it really makes sense to have an object
based language and learning the new commands is made simple both by the autocomplete and the rewritten help file. ags is as good as ever, and two days later i feel completely at home with 2.7.
Thanks for the input -- it's good to see that people who haven't touched the OO stuff before are adapting to it nicely :)
QuoteI have been testing the latest version now and there is always one thing wich bother me. In every time I try to press "preview the view" It doesn't work then. So what it wrong with this thing?
I don't know, what is wrong with it? What doesn't work?
QuoteThe problem is, I either need a pointer to a custom struct type, or I have to make duplicate copies of the same data.
Edit by strazer: Topic has been split: New thread here (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=20328)
Rather than using a pointer to a custom struct, you can create an array of structs and just store the array index. It's a bit messy compared to having a pointer, but you don't need to duplicate any data.
QuoteWhen using the special "narrator" character in dialog scripts to pop up a message box, the mouse cursor used to initiate the dialog is being displayed.
Shouldn't it be hidden or at least be the Wait or Pointer cursor?
Well, this is normal behaviour for Display() boxes, so I would say for consistency it should stay as is.
QuoteManual -> Tutorial -> Advanced room features -> Character scaling: "The scaling settings effect all CHARACTERS in the game, but not objects."
Well spotted thanks, I'll fix it.
Quote
According to the manual, UpdateInventory only affects the player's inventory. Since we can now use InvWindows with other characters, shouldn't each InvWindow control have some kind of Update function too?
I'll amend the docs, UpdateInventory does actually affect all inventory windows.
QuoteA little bug I've found: My player character guy only walks around solid characters if he himself is set to solid. If I deactivate solid for him, he walks through other solid characters.
As strazer says, this is by design. Both characters must be solid in order for them to block each other.
Quote
Well, this is normal behaviour for Display() boxes, so I would say for consistency it should stay as is.
But in dialogs, the mouse cursor switches to the pointer mode (at least when the dialog options are displayed) so in my opinion the consistent thing would be to display the pointer cursor.
Glitch in the manual :(
I couldn't find where unhandled_event an other functions like that were, so I looked at it on the index, and when I clicked on locate to learn when it is, it points me to "Understanding blocking scripts".
I use a Linux program to view the chm file and there's no "Locate" button, but if I click on "unhandled_event" from the Index, it takes me to the correct page (Reference -> Scripting event reference). Strange.
Edit:
Speaking of the manual, I've found a few things regarding v2.7 when I read through it (again) the other day:
Tutorial -> Setting up the game -> Inventory:
"All inventory commands always operate on the current player character."
Tutorial -> Setting up the game -> Importing your own sprite graphics:
"Go to the Sprite Manager pane, under Visual Settings."
"At present you cannot move sprites between folders so they are stuck in the folder in which you create them. (...) Also, you cannot delete folders."
Tutorial -> Setting up the game -> Animations:
"Go to the "Views" pane, under Visual Settings."
Tutorial -> Setting up the game -> Characters:
"The "No interaction" checkbox..." (=> "Clickable")
"(...) the script name may only contain letters A-Z."
Missing:
- "Ignore room area lighting"
- "Do not turn before walking"
- "Diagonal loops"
- "Adjust speed with scaling"
- "Solid"
Tutorial -> Setting up the game -> Conversations:
"You can have as many lines like this as you want within the script." (Dialog script message limit is 3000?)
Tutorial -> Setting up the game -> Game options:
"Conversation on GUI" (=> "Dialog options on GUI")
"Player can't skip speech text" (=> "Skip speech" dropdown menu)
"Buttons off when disabled" (=> "When interface disabled" dropdown menu?)
"Always display as speech" (=> "Always display text as speech")
"Speech style" (QFG4-style not explained)
"No special walk-mode processing" (=> "Don't automatically move character in Walk mode" (Wouldn't "player" be more precise?))
"Use 320x240 letter-box mode" (=> "Use letterbox (320x240 / 640x480) resolution")
"Don't modify inventory cursor" (=> "Don't use inventory graphics as cursors")
"Don't automatically lose inventory" (=> removed)
"Don't scale up fonts" (=> "Don't scale up fonts at 640x400")
"Split resource files" (=> "Resources split every Mb")
"(...) clicking an inventory item will call your on_mouse_click function with LEFTINV or RIGHTINV (...)" (=> eMouseLeftInv / -RightInv)
"(...) WHEELNORTH and WHEELSOUTH (...)" (=> eMouseWheelNorth / -South)
Missing:
- "Use anti-glide mode"
- "Room transition style"
- "Save screenshots in save games"
- "Enforce object-based scripting"
- "Left-to-right operator precedence"
- "Maximum possible score"
Tutorial -> Advanced room features -> Character scaling:
"(...) by checking the "ignore scaling" box in that character's properties." (=> "Ignore room area scaling")
Tutorial -> Advanced room features -> Scrolling:
"(...) the picture could either be a scrolling room at 320x200, or a single non-scrolling screen at 640x480."
(Couldn't that be determined automatically depending on the game resolution, to avoid confusion? Am I missing something here?)
Tutorial -> Advanced room features -> Animating background scenes:
"There is a limit of 15 objects per screen, (...)" (=> I say get rid of the number and just say there's a limit so you won't have to update that part again later)
Tutorial -> Advanced room features -> Lighting effects:
"(...) depending on the individual character "Ignore lighting" and object "Use lighting" settings (...)" (=> "Ignore room area lighting" & "Use region tints and lighting")
That's it for now. :)
Hmmm works for me in windows too, try again, it's possibly you just clicked a bit off the item, the item just above 'unhandled_event' is 'Understanding blocking scripts'.
Feedback on Porting Old Code to New -
So far it's pretty painless. The one thing that comes to mind though is the lack of the old function prototypes. The "(Formerly known as MoveObject, which is now obsolete)" type info would be much more helpful if it included the parameter list. I know that generally they are the same as the new function but not in all cases (I think). Having the former parameter list available would inspire confidence in the porting process, IMHO. Just my two cents worth.
Hmmm I think the manual is for general users (correct me if I'm wrong), for users who start up their games with V2.7 wouldn't need these info. If you're upgrading the scripts you can always open up 2 AGS help files of the 2 versions to make a comparison yourself.
I know these kind of info. can help those upgrading their games, however adding more stuff to the manual can just make it large and more difficult to read, which doesn't help for people who start from this version.
Moreover, when time passes all people would have to move to new format when they start their games anyway, those info. would just become more obsolete by that time.
I don't think replacing this
"(Formerly known as MoveObject, which is now obsolete)"
with this
"(Formerly known as MoveObject (object, x, y, speed), which is now obsolete)"
would bulk up the manual very much. I know it would be a bit of work to go back and add the information and that it may or may not be worth the effort. I'll leave that determination to CJ or whomever. Cheers.
Quote from: GarageGothic on Sat 16/04/2005 11:46:43It turns out it was caused by a (possible?) gui editor bug in abbreviating long function names.
My textbox names were quite long to begin with ("txtReplaceDescription" was one), and when the editor autocreated the script, the function was abbreviated as "txtReplaceDescription_Activa". However, in the "Run Script" selection, it had been titled "txtReplaceDescription_Activat". So the correct script was never run. This also explains why one textbox, with the shorter name txtSaveDescription, worked while the others didn't.
I haven't checked AGS for long time and now I see that all the script commands I knew are deleted ;D
Anyway that was a great work again Chris. Congrats , and I'll try to take a look at the latest version soon
Bug: if you change a gui button's graphic at runtime the button will always display the whole graphic, regardless of whether the actual button is smaller than the image and ClipImage is on. In effect, from the moment you change the graphic at runtime, ClipImage seems to be disabled.
Possible Bug:
When trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error "stack corrupted after function call". If I put the identical statement in the room script it works just fine. Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()?
I have only just discovered script modules, and Chris, I have to tell you how much I love you! This is frickin' awesome. Now it will be much easier for users to port my dialog system into their games. As soon as I finish this next version and release it. I'm sure that this will probably come to replace the role played by a lot of templates previously as it's much easier just to import a module than cut and paste and import all your characters and the like into a new template. I only had one problem getting it to compile (struct type call from within interface_click) but I resolved that by creating a custom function in my script module. THANK YOU AGAIN SO MUCH!!!
If you place a button on an InvWindow and that button is in front of it (z-order-wise), you can't click on inv items anymore, as it should be. However, the button is drawn behind the inventory items.
Likewise, if the button is behind the InvWindow, you can click the inv items but the button is drawn in front of the items.
I'm displaying an indicator behind the currently activated item, so it would be nice if that behaviour could be fixed/reversed.
RE Strazer's: Hmmm... it IS illogical, yes, but it sounds like JUST what I need for a little something I haven't experimented yet. Since it's illogical, it should be fixed, but since it's also useful as it is, could it be made toggleable?
In that case, since someone might rely on GUI controls still being clickable when disabled, how about a GUIControl.Clickable property?
I second that, too, BTW. Mighty handy that could be. I was thinking of making a workaround with a non-clickable GUI on top of a clickable one - the property you're suggesting would be mighty fine.
Quote from: Pumaman
Quote from: strazer
Shouldn't the Say command leave the Wait cursor graphic alone?
Currently the Say command does
mouse.UseModeGraphic(6);
I'll modify it to check if the current mode is already Wait, and if so not change the cursor.
A blocking Object.Animate (and I suspect a lot of other blocking functions) seems to do the same.
The reason I asked for this in the first place is because in some situations I want the user not to notice that the game is blocked for a moment.
To do this, I change to the Wait cursor first, change its graphic to the previous cursor mode, do the stuff, then revert to the previous mode.
So wouldn't it be better to modify Mouse.UseModeGraphic itself to check if the cursor is already in the same mode, and if so, not change the cursor?
In addition to Strazer: or a mouse.Graphic property. Or, if not like that, at least a read-only. Ok, so maybe this is too specific a suggestion (if so, any Mod feel free to split the thread), but it's another things I've missed many times. Makes some checks much more comfortable.
QuoteSpeaking of the manual, I've found a few things regarding v2.7 when I read through it (again) the other day:
Thanks for all that, I'll get them fixed.
QuoteThe one thing that comes to mind though is the lack of the old function prototypes. The "(Formerly known as MoveObject, which is now obsolete)" type info would be much more helpful if it included the parameter list.
I can appreciate that, but at this point I simply don't have the time to go back and add all that back in, sorry. You can always have a copy of the 2.62 manual open in order to look those things up.
QuoteMy textbox names were quite long to begin with ("txtReplaceDescription" was one), and when the editor autocreated the script, the function was abbreviated as "txtReplaceDescription_Activa". However, in the "Run Script" selection, it had been titled "txtReplaceDescription_Activat". So the correct script was never run.
I just tried this, but it correctly abbreviated both the control's event name, and the actual script function name, to the same thing. Has anyone else experienced this?
QuoteBug: if you change a gui button's graphic at runtime the button will always display the whole graphic, regardless of whether the actual button is smaller than the image and ClipImage is on. In effect, from the moment you change the graphic at runtime, ClipImage seems to be disabled.
This is because changing the NormalGraphic changes the button's width and height to the size of the new image. You can set the width and height back down if you want to clip it. I will add a statement to the manual to mention this.
QuoteWhen trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error "stack corrupted after function call". If I put the identical statement in the room script it works just fine. Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()?
Thanks for the report, I'll look into it.
QuoteI have only just discovered script modules, and Chris, I have to tell you how much I love you! This is frickin' awesome. Now it will be much easier for users to port my dialog system into their games.
No problem, glad to hear you're finding it useful :)
QuoteIf you place a button on an InvWindow and that button is in front of it (z-order-wise), you can't click on inv items anymore, as it should be. However, the button is drawn behind the inventory items.
Likewise, if the button is behind the InvWindow, you can click the inv items but the button is drawn in front of the items.
Well spotted, the clickable z-order is the reverse of the visual z-order. Thanks for pointing it out, I'll get it fixed.
QuoteIn that case, since someone might rely on GUI controls still being clickable when disabled, how about a GUIControl.Clickable property?
What are we talking about here? Having a disabled control that it still clickable, or an enabled control that is not clickable?
Either way, this is leading to feature creep again, so can we please not have any new suggestions in this thread.
QuoteSo wouldn't it be better to modify Mouse.UseModeGraphic itself to check if the cursor is already in the same mode, and if so, not change the cursor?
That might be a good idea, but it's the sort of change that could break someone's existing script, and be a bugger to track down when they start noticing problems with it. I think it's best left as is.
Quote
Quote
In that case, since someone might rely on GUI controls still being clickable when disabled, how about a GUIControl.Clickable property?
What are we talking about here? Having a disabled control that it still clickable, or an enabled control that is not clickable?
Either way, this is leading to feature creep again, so can we please not have any new suggestions in this thread.
GUI controls that are disabled are still clickable, aren't they?
I just suggested it as a workaround in case you decided to leave the z-order as it is.
Edit:
As Rui said, by clickable I mean they won't let clicks through to the GUI control beneath it.
QuoteWell spotted, the clickable z-order is the reverse of the visual z-order. Thanks for pointing it out, I'll get it fixed.
You're sure you won't make it toggleable (since it's already in)? In some instances, that's a feature rather than a bug... and my 2 cents on the "Clickable property" (not insisting, - feature creep indeed! - just clarifying): having a visible button (or InventoryWindow) that's not clickable, and instead the control BEHIND it gets called.
Quote from: Pumaman
QuoteWhen trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error "stack corrupted after function call". If I put the identical statement in the room script it works just fine. Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()?
Thanks for the report, I'll look into it.
Here is some additional information about this that may be helpful. After further experimentation I have found that it seems to work just fine when called from a Script Module's repeatedly_execute() handler. It was a pleasant surprise 8).
Does everybody agree that with the new Button.ClipImage the ProgessBar GUI control (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=252) is not needed anymore?
I feel it's now easy enough to workaround that it doesn't warrant a specialized GUI control that wouldn't get used that often anyway.
QuoteGUI controls that are disabled are still clickable, aren't they?
Oh yes, so they are, I forgot which way it worked.... it had been a long day ;)
QuoteYou're sure you won't make it toggleable (since it's already in)? In some instances, that's a feature rather than a bug...
Well, I can't really see any use for it. It's an obviously broken feature that needs to be fixed, rather than just changing the way something works. Or are you saying that you'd really need the Clickable property if this was to be fixed?
QuoteHere is some additional information about this that may be helpful. After further experimentation I have found that it seems to work just fine when called from a Script Module's repeatedly_execute() handler. It was a pleasant surprise.
Thanks, I've found the bug. It happens if you call RunAGSGame from a nested script function (ie. a script funciton that has called another). Thus if you call it directly from an interaction script or a function like rep_exec, on_key_press, etc it will work fine.
QuoteDoes everybody agree that with the new Button.ClipImage the ProgessBar GUI control is not needed anymore?
I feel it's now easy enough to workaround that it doesn't warrant a specialized GUI control that wouldn't get used that often anyway.
I agree. I think that between them, the Slider control, RawDrawRectangle and Button.ClipImage should cater for all possible progress bars.
QuoteOr are you saying that you'd really need the Clickable property if this was to be fixed?
Well, it's not 100% life-or-death, since as I said I can superimpose 2 GUIs... but yeah, if I was to ditch the "2 GUI" idea, which is not fatal but quite cumbersome, that's just what I'm saying. ::)
I'm just salivating in anticipation for this thing to finally come out ^_^ Hurry up, guys! (I'm glad you're being thorough, though)
I think in the documentation for the RawDraw functions, it should be made clear that the coordinates are room coordinates.
Currently, it says "onto the screen at location (X, Y)" which is a bit misleading IMO.
The dialog script doesn't seem to recognize character names with numbers in it. I couldn't find any mention of it on the recent topic pages and the search didn't produce anything either, so I thought I'd point it out.
QuoteI think in the documentation for the RawDraw functions, it should be made clear that the coordinates are room coordinates.
Currently, it says "onto the screen at location (X, Y)" which is a bit misleading IMO.
Good point, I've added that fact to a few sections of the RawDraw functions manual reference.
QuoteThe dialog script doesn't seem to recognize character names with numbers in it. I couldn't find any mention of it on the recent topic pages and the search didn't produce anything either, so I thought I'd point it out.
Thanks for the report, I'll get it fixed.
Right, 2.7 Final is now out. This fixes all outstanding bugs and should be the very final version.
From this point on,
BUG REPORTS ONLY IN THIS THREAD.
The new version will become the official 2.7 Final in a week or so if no major bugs are found.
Bug: ChangeRoom()
When the player character is set to start in room 1 and in the room 1 "Player Enters Before Fadein" you attempt to do a player.ChangeRoom(1,77,198) the background image is not displayed. (Music is played however). Seems to happen only with player character.
This is an acrade type game and the apparent redundancy (i.e. CHangeRoom()) is there to establish a generic pattern for additional levels. So although it doesn't serve a useful purpose in the first level, it would in subsequent levels.
It seems that the easy fix on my part is to just start in room 0 as a blank screen and immediately go to room 1. However, CJ, I thought this would be somthing you would want to be made aware of.
Hmm, changing room within Player Enters Screen Before Fadein is a bit of a dodgy thing to do; I guess perhaps the best solution would be for it to error out if you attempt this, unless it is a scenario that's useful?
(Graphic) Bug:
When I start AGS 2.7 Final (extracted from the ags27final.zip file) I still see "BETA VERSION". Not anything terribly important, but if it's a final version then it's clearly not BETA any more... ::)
Quote from: monkey_05_06 on Tue 26/04/2005 22:35:07
(Graphic) Bug:
When I start AGS 2.7 Final (extracted from the ags27final.zip file) I still see "BETA VERSION".Ã, Not anything terribly important, but if it's a final version then it's clearly not BETA any more... ::)
because it is a Beta!!! As you can see at the first site of this Thread.
The Current Version is Still 2.62 as you can see oon the Main Page.
The Version you got is the last Beta, its finished but not released, to fix the last bugs.
Quote
Hmm, changing room within Player Enters Screen Before Fadein is a bit of a dodgy thing to do; I guess perhaps the best solution would be for it to error out if you attempt this, unless it is a scenario that's useful?
Displaying a descriptive error message would be fine. It's easy enough to work around once you realize what's happening. Getting a black screen like that is a bit unsettling. :'(
When an inventory item with an alpha-channelled sprite is active, the cursor hotspot dot isn't drawn. Instead, there's a hole in the cursor graphic where the hotspot dot/sprite should be.
QuoteWhen the player character is set to start in room 1 and in the room 1 "Player Enters Before Fadein" you attempt to do a player.ChangeRoom(1,77,198) the background image is not displayed. (Music is played however). Seems to happen only with player character.
I was just thinking about this further.
If you put ChangeRoom(1) in Player Enters Screen for room 1, then you're effectively creating a recursive loop of ChangeRooms, because each time it runs it changes to room 1 and then runs the script again. So really, a black screen in this situation is kinda what you'd expect since the new room will never get to fade in.
QuoteWhen I start AGS 2.7 Final (extracted from the ags27final.zip file) I still see "BETA VERSION". Not anything terribly important, but if it's a final version then it's clearly not BETA any more...
As has been stated, this isn't the Final Final, it's just the Final, if you see what I mean ;)
QuoteWhen an inventory item with an alpha-channelled sprite is active, the cursor hotspot dot isn't drawn. Instead, there's a hole in the cursor graphic where the hotspot dot/sprite should be.
Thanks for pointing that out. I'll fix the hotspot dot side of things, but for the hotspot sprite you'll need to use an alpha-channeled hotspot sprite in order to get it to work.