OK, so here's some suggestions for AGS:
It would be nice if each of the inbuilt arrays like character, object, etc all had one or two extra members per item that were read/writeable and available for the use to use as they wished. Ideally, the user could control the number/type and names of these, but even if there were 1, called userdef1, then that would be great. I suppose these are like read/writeable propertty schemas, so it could be doen through that. Or through a way of getting OO extends to work on those builtins
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.
OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.
Character editor should show view NAMES when choosing default, idle, talking views, etc.
Also be nice if characters, like GUIs, could have a named handler function
Be good if you could specify whether the dialog GUI goes away after an option is selected, or if it stays. Alternativley, specify a function to be called before and after any dialog
A GUI could have its own on_key_press and repeatedly execute handlers, and it would be nice if a GUI could have a click handler rather than just GUI controls, because lots of GUIs have a regularity to them that means that individual handlers would mean lots of cut-and-paste
Quote from: SSH on Wed 05/01/2005 15:05:18
Be good if you could specify whether the dialog GUI goes away after an option is selected, or if it stays. Alternativley, specify a function to be called before and after any dialog
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=289
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=380
Quote from: SSH on Wed 05/01/2005 15:05:18
and it would be nice if a GUI could have a click handler rather than just GUI controls
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=198 ?
Quote from: strazer on Wed 05/01/2005 16:17:45
Quote from: SSH on Wed 05/01/2005 15:05:18
and it would be nice if a GUI could have a click handler rather than just GUI controls
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=198 ?
That's not the same. I mean that as AGS 2.7 is adding that individual GUI buttons can have their own script, it would be nice if the GUI as a whole had a script, so that buttons which do NEARLY the same function can run in the old way (e.g. verb buttons on a SCUMM gui)
While we're here, I wish that you could access GUI controls with something like gui[2].item[3]
Quote from: SSH on Wed 05/01/2005 15:05:18
It would be nice if each of the inbuilt arrays like character, object, etc all had one or two extra members per item that were read/writeable and available for the use to use as they wished. Ideally, the user could control the number/type and names of these, but even if there were 1, called userdef1, then that would be great. I suppose these are like read/writeable propertty schemas, so it could be doen through that. Or through a way of getting OO extends to work on those builtins
Well, a cleaner solution here would be to make custom properties changeable at run-time, I think. It has been requested, but not a high priority.
Quote
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
Yeah, that's a pretty good idea; I can see it coming in handy.
Quote
If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.
I suppose an equivalent would be to add a set of Game custom properties, along with GetGameProperty/etc, since that's effectively what you're asking for. I can see the benefits, but again it's a fair bit of work for something that may well not get used very often.
Quote
OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.
I agree, script modules is something I'd really like to add. However, there are loads of things I'd really like to add and it's all a matter of time. Once all the object-ising stuff is out of the way, I will give script modules quite a high priority.
Quote
Character editor should show view NAMES when choosing default, idle, talking views, etc.
I'd prefer to change it to a proper graphical selection dialog, with a view preview and so on. Again, I'd like to, but I can't promise when.
Quote
Also be nice if characters, like GUIs, could have a named handler function
Not so sure about this one ... the interaction editor is there to handle clicks on characters, but GUIs don't have the interaction editor to handle things for them.
Overall, after reading your post I do like and agree with most of your suggestions. However, as always, there is only a finite amount of time and features that can go in, so I'm afraid I can't promise anything.
If anyone else wants to comment on any suggestions from SSH's post that they think would be particularly useful, feel free.
Quote from: Pumaman on Wed 05/01/2005 20:46:35
[Quote
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
Yeah, that's a pretty good idea; I can see it coming in handy.
Or, if it can be made that you can set manually which character's inventory you're displaying on a specific inventory window in a GUI (
WITHOUT the need to change to that character) that'll be okay too.
Quote from: Pumaman on Wed 05/01/2005 20:46:35
Overall, after reading your post I do like and agree with most of your suggestions. However, as always, there is only a finite amount of time and features that can go in, so I'm afraid I can't promise anything.
Of course. You're doing a great job, CJ, and its only becuase of the great new stuff you've added in 2.7 already that I felt inspired to ask for more! I just wanted to get these in the tracker. Thanks for doing the builtin defines so quickly, btw!
As for the dialogs, you can check out my work-around for scrolling dialogs:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=18466
With a bit of modification, "you could [easily] specify whether the dialog GUI goes away after an option is selected, or if it stays" (SSH). I think, if I understand you correctly, that you would want to do something like:
// RunningDialog(dialog, option)
if (dialog == XXXX) {
if (option == XXXY) {
DisplaySpeech(CHAR, "Speech");
// blah
SetupDialog(dialog); // turn DIALOG GUI back on
}
else if (option == XXYX) {
DisplaySpeech(CHAR, "More speech");
// blah
EndDialog(); // turn DIALOG GUI off
}
}
You have to script everything manually with this workaround, but it's a bit more customizable. Just re-setup the dialog if you want to make the dialog GUI "stay", or end it if you don't. I suppose a similar setup would work with the built in dialog system:
// main global script
function dialog_request(int parameter) {
if (parameter == 1) RunDialog(CURRENTLYRUNNINGDIALOG);
else if (parameter == 2) GUIOff(DIALOGGUI);
}
// dialog script
@s
return
@1
char: Speech
// DIALOG REQUEST 1 ?
@2
char: More speech
// DIALOG REQUEST 2 ?
stop
Or something like that. I don't remember exactly how that's supposed to work... Since I scripted that scrolling dialog workaround, I kind of don't recall how the built in dialogs work... Well, let me know if this helps.
Quote from: Pumaman
Quote from: SSHI suppose these are like read/writeable propertty schemas, so it could be doen through that.
Well, a cleaner solution here would be to make custom properties changeable at run-time, I think. It has been requested, but not a high priority.
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=191
Quote from: SSHit would be nice if the GUI as a whole had a script, so that buttons which do NEARLY the same function can run in the old way (e.g. verb buttons on a SCUMM gui)
Why not keep using the interface_click function? I'm not aware of any plans to remove it?
Quote from: Gilbot V7000a
Quote from: Pumaman
Quote from: SSH
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
Yeah, that's a pretty good idea; I can see it coming in handy.
Or, if it can be made that you can set manually which character's inventory you're displaying on a specific inventory window in a GUI (WITHOUT the need to change to that character) that'll be okay too.
That would be a nice workaround for now, we even have a tracker entry already:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=245
Quote from: strazer on Mon 10/01/2005 05:08:12
That would be a nice workaround for now, we even have a tracker entry already:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=245
Heh, because as far as I remember I suggested it long time ago. ;)
Indeed, there's lots of ways to work around some of the probolems I mention, but I wanted to suggest what I considered as the optimal solution, rather than what might be a way of simplifying a workaround.
Quote from: Pumaman on Wed 05/01/2005 20:46:35
Quote from: SSH on Wed 05/01/2005 15:05:18
If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.
I suppose an equivalent would be to add a set of Game custom properties, along with GetGameProperty/etc, since that's effectively what you're asking for. I can see the benefits, but again it's a fair bit of work for something that may well not get used very often.
... and you would need the ability to have different schemas for game, character, object, etc.
Quote from: Pumaman on Wed 05/01/2005 20:46:35
Quote from: SSH on Wed 05/01/2005 15:05:18
OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.
I agree, script modules is something I'd really like to add. However, there are loads of things I'd really like to add and it's all a matter of time. Once all the object-ising stuff is out of the way, I will give script modules quite a high priority.
Oooooo baby := I can't wait :)
Quote from: Pumaman on Wed 05/01/2005 20:46:35
Quote from: SSH on Wed 05/01/2005 15:05:18Character editor should show view NAMES when choosing default, idle, talking views, etc.
I'd prefer to change it to a proper graphical selection dialog, with a view preview and so on. Again, I'd like to, but I can't promise when.
I know I am, more or less outspoken on this issue, but I have a somewhat different way of looking at this; It seems to me that animatable entities such as characters, objects, etc should own their own views. The main objection seems to be that if this were the case views couldn't be shared. I am not so sure this has to be the case anymore with the new scripting methodology.
For example suppose that the editor for each of the animatable entities (character, object, etc) had a View Editor tab. Only the views owned by the animatable entity (i.e. character, object, etc) would be listed. Views would be named and numbered much as they are now, except that numbering would begin from '1' for each entity. The names would have global scope and be enums (i.e. vEgoWalk). The enum value then would be what is now the global view number.
We would end up with each animatable entity having a property array called View. The array index then is the local id number. The value contained in the array element is the enum value (i.e. what is now the view number). For example if we define a view named vEgoSmile for character Ego we could do something like this:
// We used the view editor to define Ego's view number 7 to be vEgoSmile.
// This means that Ego.View[7] is equal to vEgoSmile.
// To assign this view to Ego's thinking view we could do this ..
cEgo.ThinkView = vEgoSmile;
// or we could do this.
cEgo.ThinkView = cEgo.View[7];
// Now suppose we wanted to assign this view to Bob's thinking view, again this ...
cBob.ThinkView = vEgoSmile;
// or we could do this.
cBob.ThinkView = cEgo.View[7];
// And just to be clear cBob.View[7] is not equal to cEgo.View[7].
SSH's original suggestion, in this case can just be a drop list as he suggests or a right click menu in the view editor. The current global View Editor (if desireable) could show and allow edits on all views as it does now, with the only difference being in the way views are named and numbered, using enums instead of name and number.
Sorry for the long post, didn't know how to express the idea otherwise. Hope you find it. I know it's a lot of work to implement so I understand if it never gets done.
Cheers everyone....
QuoteIt seems to me that animatable entities such as characters, objects, etc should own their own views.
I see where you're coming from on this one. I guess it would make things easier since you wouldn't have to remember that Ego's swimming view was view 145, but rather that it was ego.view[2].
But views do have (old-style) script names now at least, so it's not as bad as it once was.
What you're suggesting could probably be implemented by allowing you to link views to characters in some sort of character view list -- so they'd still all exist in the main VIews pane, but the character could have a list of relevant ones, perhaps.
Again, this won't happen for 2.7, but it's an interesting thought for the future.
I was thinking something similar to gilbot for the inventory items...
Why not allow next to each item to put an item type number. Eg 1, or 2, or3 etc...
When you put an inventory window on a gui, you specify in a text area which item types to display, 1, or 2, or 3 etc...
Here comes a suggestion really not on par with the previous ones in this thread....
Could you add the ability to copy the additional background frames to clipboard? We have the ability for the current main bg, but not the animating ones.
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=177
I knew I should have looked there.Ã, Ã, :( Thanks. Won't happen again.
Hey, no prob. :)
I just posted it so you can write your comment in there.
If we had some kind of voting system for tracker entries, I'm sure more people would actually read that list...
While we're at suggestions, I was suddenly inspired, that since we can have dynamic ingame sprites now, it may be useful to have the following function:
CreateSpriteFromBackground(int x1, int y1, int x2, int y2);
Which will snap the rectangular area (defined by the corners (x1,y1) and (x2,y2) ) of the current background frame (i.e. no need to care about if there're objects, characters on top of it) into a dynamically created sprite (returns sprite number like LoadImageFile() ).
This is useful in the sense that for example, if you want to draw some simple polygons ON TOP of the screen, you can make the room larger, with some areas that it'll never be scrolled to (hence invisible), you can just do whatever raw drawing on that offscreen part of the background, and then use this function to grab that area as a sprite, so, viola! we can display that sprite as an overlay, object, etc. now.
Furthermore, since the engine can save graphics as BMP or PCX format already (check SaveScreenShot() ), it may also be interesting if we can save a sprite as a graphics file, like for example:
SaveSpriteToFile(12, "face.pcx");
This is useful in places like for example you can pixel paint your face in a game then save it for later use (or for example save the face made in Esseb's good old Perpentrator for fun ;) ), etc.
These are not important things, and are just sudden ideas, so I don't really care when they'll be implemented or will they ever be implemented at all. ;)
If you're going to use it for savegame with srceenshots thumbnails, then you need to have the ability to scale the sprite to whatever size your thumbnails will be.
It would be nice to be able to crop dynamic sprites, too. For example, if you want to cut a GUI off of a savegamescreenshot. Maybe the cropping could be done before the screenshot is added to the game, with game.screenshot_area_left, game.screenshot_area_right, game.screenshot_area_top and game.screenshot_area_bottom.
Quote from: Pumaman on Mon 10/01/2005 19:48:51
What you're suggesting could probably be implemented by allowing you to link views to characters in some sort of character view list -- so they'd still all exist in the main VIews pane, but the character could have a list of relevant ones, perhaps.
Again, this won't happen for 2.7, but it's an interesting thought for the future.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=498
I have a couple things I'd like, and I didn't see 'em in the tracker yet...
First, the ability to use voice speech with a character's THINKING action/view. (I'm making a game in which I want character.Think to be the usual response to looking at objects, etc. I would just use Display with always display text as speech enabled, but the way the characters are in this game they would have to point out EGO talking to himself.)
Also, any way to make the "mouse Y-pos" pop-up GUIs work with OTHER direction? That didn't make much sense, let me rephrase. I'd like to make a GUI that pops up like the basic Sierra one, but at the bottom (or side) of the screen. The ideal would be the ability to set X-min, X-max, Y-min, and Y-max, so you could set EXACTLY where you move the mouse to get the GUI to pop up. It wouldn't be TOO terribly hard to work around this with scripting, checking the mouse position in rep_ex, it's just that this would make things easier for someone who wanted to do this.
HoN
Quote from: HeirOfNorton on Wed 19/01/2005 05:27:03
Also, any way to make the "mouse Y-pos" pop-up GUIs work with OTHER direction? That didn't make much sense, let me rephrase. I'd like to make a GUI that pops up like the basic Sierra one, but at the bottom (or side) of the screen. The ideal would be the ability to set X-min, X-max, Y-min, and Y-max, so you could set EXACTLY where you move the mouse to get the GUI to pop up. It wouldn't be TOO terribly hard to work around this with scripting, checking the mouse position in rep_ex, it's just that this would make things easier for someone who wanted to do this.
Actually I really agree on this one, such kind of automatic popup feature should either be nonexistence or at least supports more edges.
Edit: just added this to the tracker.
Actually, there's already a tracker entry for this:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=416
Edit:
I have updated the existing entry and removed the new one.
I see where you're coming from on this one; but as it's so easy to do with scripting it's by no means a priority to implement.
Our Product Change Request (PCR) system here at work has a number of improtant fields that might usefully be added to the tracker:
1. Customer priority: how important the suggester thinks it is
2. Developer priority: how likely CJ is to do it soon
3. Workaround: a place for people to suggest workarounds for the problem
ANother suggestion: split-screen mode
Since we can now have two character invetories on screen easily, how about having two rooms on screen simultaneously. Obviously, they would have to be half-height or half-wdith rooms...
Oops double post. SOrry!
QuoteOur Product Change Request (PCR) system here at work has a number of improtant fields that might usefully be added to the tracker:
Yeah, the tracker does need some serious work done to it, it's very basic at present. One day I'll get around to it.
QuoteANother suggestion: split-screen mode
Since we can now have two character invetories on screen easily, how about having two rooms on screen simultaneously. Obviously, they would have to be half-height or half-wdith rooms...
Alright mister, on yer bike! :=
About future suggestions...
Will there ever be an option in AGS to define different colors for dialog options depending on if player has chosen a certain topic earlier? It would be a very, very important feature for my game.
Please, tell me, if it is ever going to be implemented...
Dialogs are tricky ground in AGS at the mo - probably the most underdeveloped right now. CJ has let us now that he plans to revamp the whole shebangs, but I don't think it will be anytime soon.
There are many, many workarounds, however. Like using inventory items instead of topics, or listboxes, or labels, or whatever. You'd have to hardcode, but if it's that vital to your game...
Creating your own dialog system isn't too difficult provided you have a decent grasp of programming, and if you tend to put a lot of script in your dialogs (animations and such) it's sometimes easier to foresake the built-in dialog editor anyway. (although it is nice for organizing stuff)
QuoteWill there ever be an option in AGS to define different colors for dialog options depending on if player has chosen a certain topic earlier? It would be a very, very important feature for my game.
It's on the tracker already (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=478), so I guess it will eventually happen.
Just wanted to check if the various suggestions in this thread have been tracker'd... I think some are missing even though CJ said theyd be useful. Of course, CJ has already implemented some of them.... ;D
QuoteI think some are missing even though CJ said theyd be useful.
What suggestions are you referring to, specifically?
General prupose item list of which inv items would be a special case, as I said in my first post...
Also this one from the beta thread:
Quote
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...
Rick has already seconded this
It maybe would be worth revisting the beta thread to make sure there aren't any suggestions hiding in there that need going in the tracker. I'd volunteer to do it myself, but then I'm not a tracker moderator ;) The 2.7 beta thread is now in the top 10 threads for lenght in the whoel forums, btw...
Quote
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...
I would even go so far as to suggest that whenever a script is opened for edit the corresponding (i.e. in the case of a module script) header file also be opened for write.
Ok, I have added them:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=503
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=504
Be sure to let me know if you find anything else CJ-approved that I've missed.
Another suggestion (I've searched the forums, read TFM, but still might have missed something, so please bear with me... ;) )
Sometimes you have a character which behaves in most strange ways, jumps, falls and what not. To make sure it would stay in position, I made all it's sprites the same size, allowing room for all those actions. Silly! Eats space.
Would it be possible to include a "crop sprite at top only" feature? This way it'd still stay in position (to my limited knowledge), but it would be an easy and fast way to decrease gamesize (and increase performance speed...?).
Well, characters are pivoted at the bottom centre of the sprite, so if you ensure that your images are centered within the frames, you should be able to use the normal Crop feature on a group of frames to reduce them to an animatable size.
Sure, and it's okay with "normal" characters, but I had this guy panicing, jumping up, hitting the head and falling down, resulting in his artificial limb detaching and rolling a bit away. After cropping, he would slide a lot back and fro on the spot, naturally, since he sometimes bended over to the left, sometimes to the right, and the lying sprite was much wider. To have it animating properly resulted in a lot of character[EGO].x/Wait combinations. Same problems I had with cropping a kangaroo, as the tail stuck out in side-view. Bottom line is, the "natural center" of a character isn't always in the middle.
The solution as of now is either keeping larger sprites or calculating a lot of movement for each special animation (thus avoiding the AnimateCharacter(Ex) function(s)).
Being able to crop only the top of sprites wouldn't affect the sprite's bottom center. Another possibility would of course be to be able to always crop the same amount on each side (with AGS calculating how much to crop without changing the center). That would be a dreamÃ, ;D
Ah ok, I see what you're saying.
Well, what about if the Crop feature always cropped the same amount off the left and right sides, thus leaving the centre intact? Would that solve the problem?
Sure would! ...of course it could safely crop the top as well :)
Ok, I'll see what I can do.
talking expressions - like in lucas arts games, where at certain points within the conversation the character would shrug, point, laugh etc...
This would be UBER useful IMPO in creating more authentic games.
Cheers
Why don't you use run-script & dialog_request to play animations?
There's also the set-speech-view command to change facial expressions.
Quote from: Pumaman on Sun 06/02/2005 16:50:57
Well, what about if the Crop feature always cropped the same amount off the left and right sides, thus leaving the centre intact? Would that solve the problem?
What would be great is an option to add a one-pixel-wide transparent column to the left (or right) of a sprite. That way you can align the sprites within AGS if they somehow aren't.
(of course you can export the sprite to do the same, but this is faster and you can see the results).
When you run an idle or a blink animation that spans longer than one row, and you want that repeated, it only repeats the last row, as if the reset only goes back to the beginning of that loop, such as the fourth down, as opposed to zipping back to the beginning.
I thought it was my coding problem for several days, then it finally hit me. Then my palm hit my forhead. Then I ran outside, screamed and ripped off my shirt.
Anyways, I would prefer if it did go back to the beginning when you set a characters idle view, or blink view, and if it finished and was coming back around again, that it went back to start at the beginning. Thanks.
Quote from: Scummbuddy on Thu 10/02/2005 02:28:40
When you run an idle or a blink animation that spans longer than one row, and you want that repeated, it only repeats the last row, as if the reset only goes back to the beginning of that loop, such as the fourth down, as opposed to zipping back to the beginning.
Really, what you want (I think) is an animation that lasts more than 20 frames (or whatever the max is), rather than the "hack" that continues to the next animation.
right, but if i use animatechar i dont want to set a repeat of 20 times, or so, and then if someones in the room that long, i dont want it to stop animating in the background after awhile. And with the idle view, it can go right back into his "fake talking view".
you see, i have him talking to someone else in the background, but you come up and bother take him from his conversation.
But I'm also getting trouble doing this check in rep ex.
if (character[MO].talkview == 12)
{
Ã, SetCharacterView(SCU, 3);
Ã, }
else if (character[SCU].talkview == 14)
{
Ã, SetCharacterView(MO, 5);
}
else
{
}
thats to have the other person that they were already having a 'fake' convo with stop from just talking 'to themselves' while i start a convo with one of them.
----------------
On another note, I've noticed that if your characters name is 2 letters long, you can have that be their script name too, without a problem, but if their name is longer, like 4 letters, you get 'yelled at' and told to change it, stating they can't be identical. Why is that?
You can always do the repeat manually, by checking the animating property of the character in repeatedly_execute...
QuoteWhen you run an idle or a blink animation that spans longer than one row, and you want that repeated, it only repeats the last row, as if the reset only goes back to the beginning of that loop, such as the fourth down, as opposed to zipping back to the beginning.
This is because the idle view uses a seperate loop for each direction depending on which way the character was facing, so using multi-loop idle animations isn't generally a good idea.
QuoteOn another note, I've noticed that if your characters name is 2 letters long, you can have that be their script name too, without a problem, but if their name is longer, like 4 letters, you get 'yelled at' and told to change it, stating they can't be identical. Why is that?
I'm not sure what you mean, can you clarify/provide an example?
Quote from: SSH on Wed 05/01/2005 15:05:18
As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.
I think this could be quite a nifty little addition to the engine. I would definitely be able to find several uses for a feature like this.
Quote from: Pumaman on Fri 11/02/2005 19:10:49
QuoteOn another note, I've noticed that if your characters name is 2 letters long, you can have that be their script name too, without a problem, but if their name is longer, like 4 letters, you get 'yelled at' and told to change it, stating they can't be identical. Why is that?
I'm not sure what you mean, can you clarify/provide an example?
It was my fault. It had to do with the script name being the same as a view name. Nevermind, but thanks for the answers.
Ok, my message got deleted, along with the one that triggered it. I can understand, but I'll re-state one of the things I said (the one without which I wouldn't have replied, naturally).
I'd just like to second the "other general purpose item list" BUT mention that the new multi-inventory-system makes many workarounds possible very, very easily.
Oh, and while I'm suggesting, it would be nice if dialog scripts had autocompletion, and could pick up enumerations/defines from the (a ?) script header.
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=469
Small suggestion. It has propably been suggested before so I am ready to recieve a nice flaming. ;)
What if, when setting the views for the character, you could set the starting loop for the animation set?
Example:
If you have no diagonal cycles you could have the walking at view 1 loop 0-3.
Then you could set talking cycles at the same view but from loops 4-7.
...and idle view from 8-11.
This way you can have 1 view per character in most games. Would save resources to not have 2 views per character not to mention how much more tidy it would look.
Quote from: HeirOfNorton on Wed 19/01/2005 05:27:03
First, the ability to use voice speech with a character's THINKING action/view. (I'm making a game in which I want character.Think to be the usual response to looking at objects, etc. I would just use Display with always display text as speech enabled, but the way the characters are in this game they would have to point out EGO talking to himself.)
I was waiting for a respone from CJ regarding this, but I have now just added it as an unverified entry: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=508
Edit:
I've set this entry as completed. Don't know why I added it, it works fine, just like it did in v2.62:
cEgo.Think("&1 Hm, I wonder why...");
plays the file EGO1.wav/ogg/mp3 (put it in the game folder, not the Compiled folder).