I'm very happy to see that you have a new Beta available for download, and it has improvements. When I update my computer, I'll make sure to test it.
A suggestion, that I hope you find helpful:
Would you be able to make AGS more User-Friendly for guys like me who are students and workers, who have little time or apptitude in Computer Scripting. I mean, don't stop enabling Script, but, could there be, perhaps a digital GUI switch in the program that allows the Game Designer to set a certain mode for easy designing? Just in case, the designer does not have a great deal of time and/or patience for in-depth programming, but is very artistic and loves setting the commands and typing in the names, numbers and incorporating sound, graphics and video in the production.
Perhaps for example, me. I'm a working guy, also a student, but I enjoy designing art and a Sci-Fi/Fantasy RPG/Adventure Game I'm working with some friends. This is just a hobby, so we are not making a profit from this project, at least not for a long time.
For example: Could you perhaps, design AGS to help the user make a regular Adventure Game with RPG battle elements? Just for people like me who are slow. Heh.
Again, I don't want to sound ungrateful, or stupid (though I might) but please, seriously consider this, me and my friends are very impressed at the Quality of AGS, but would like it to improve.
Sincerely,
WackyWildCard
Quote from: WackyWildCard on Sat 29/09/2007 23:42:47
I mean, don't stop enabling Script, but, could there be, perhaps a digital GUI switch in the program that allows the Game Designer to set a certain mode for easy designing?
There is one, it's called the interaction editor.
Quote
For example: Could you perhaps, design AGS to help the user make a regular Adventure Game with RPG battle elements? Just for people like me who are slow. Heh.
RPG battle elements are surprisingly non-trivial. One could make a module for that, but it's unlikely to be what everyone wants...
:)
Thanks for your reply.
If you, or anyone else can direct me to a link to a Special Module that would help me in this matter, it would be greatly appreciated.
I would like our Sci-Fi/Fantasy Game that I'm still designing, to be a lot like impressive A Tale Of Two Kingdoms: with similar Gui style where the hero can gain Wisdom and Honour. Additionally though, it would be cool if the Hero, Sir George had a strength indicator; either a power bar or number indicating his health.
Then, when he does battle with a dragon or other dangerous monster, he can lose health points if he is hurt, and if he gets hurt too much, he will die. Also the monster could have a health bar or health score indicating life, but that would be optional. And certain weapons, like a sword or bow and arrows would have varying degrees of effectiveness.
Again, would you or someone else be able to direct me to such a module? I would be thankful.
WackyWildCard
There is no such module yet, the reasons being, there's not been a lot of demand for one and the fact that all the really necessary things are already in AGS - variables you can manipulate. The way you display them may vary wildly from game to game, and that's the part that most people seem to want.
Re interaction editor - there used to be one, Radiant, but it was scrapped in this latest beta. Interesting that people are starting to miss it...
Quote from: Rui "Trovatore" Pires on Sun 30/09/2007 08:36:42
Re interaction editor - there used to be one, Radiant, but it was scrapped in this latest beta. Interesting that people are starting to miss it...
It is? Oh, that's nice. No, I hadn't missed it yet, I've never used it period (I don't even use the per-hotspot functions...) :)
I bloody well miss it and I'm surprised more people didn't fight for it sooner.
Paul.
Not a matter of fighting. :P In fact, it's been a matter of much discussion, whether to ditch it or to keep it - CJ wouldn't have done it if people hadn't come to the conclusion it wasn't necessary. If anything, I'm surprised hardly anyone stepped up in defence of the interaction editor.
Quote from: WackyWildCard on Sat 29/09/2007 23:42:47
Would you be able to make AGS more User-Friendly for guys like me who are students and workers, who have little time or apptitude in Computer Scripting. I mean, don't stop enabling Script, but, could there be, perhaps a digital GUI switch in the program that allows the Game Designer to set a certain mode for easy designing?
The thing is that features like an RPG fighting game are by their nature complicated, and it's not the sort of thing that a graphical designer would make it easy to do. You'd have so many variables and possible paths to take that in the end it's much easier to do it with scripting.
AGS could provide some sort of built-in RPG template, but it would never do exactly what you wanted and then you'd still end up in the situation where you'd want to change it but not know how.
At the end of the day, if you want to make a game with any sort of remotely complicated features, it's best to try and learn scripting or get someone on board your team who can do the complex scripting for you.
:-\ :) :-\
Thanks for your advice guys. :)
I'll seriously consider your words.
The Quest Continues... ???
I little Off-topic, but..
Quote from: Rui "Trovatore" Pires on Sun 30/09/2007 09:19:41
Not a matter of fighting. :P In fact, it's been a matter of much discussion, whether to ditch it or to keep it - CJ wouldn't have done it if people hadn't come to the conclusion it wasn't necessary. If anything, I'm surprised hardly anyone stepped up in defence of the interaction editor.
I step up! I defend.
I like the interaction editor. And the lazy ass that I am, I don't download a newer AGS version until it is out of beta, and sometimes I skip minor updates anyhow. This is why I generally don't notice changes like this until its too late.
Interaction editor is very helpful for newcomers, until they find their feet in AGS. Its what I thought was being talked about when the main AGS page said that you *could* make a game without scripting.
Maybe CJ will leave 2.72 on the download page even after he makes 3.0 final. That way folks who are new will still be able to use the interaction editor until they get their feet wet.
If you're paying attention, the IE tells you how to script each interaction. And if nothing else, you can look at the script when you've finished all your interactions to see how AGS compiles them.
:o
THAT'S IT!
I'm confident enough to say, that I start a motion that we make a petition to bring back the Interaction Editor, for the Little Man, The Underdog, The Freshman (Like Me!) - Who's with me?!
Comon'! Let your voice be heard! Don't be shy!
:o
If it is brought back it should be in a redesigned fashion, IMO. The interaction editor got in the way a little, if you're a scripter and was actually too limited to put together most games people make.
Game Maker has a drag and drop script constructor, which could serve as a model for a new interaction editor, perhaps. It basically has a set of icons organised in tabs (tabs for drawing, setting variables, conditionals) which you drop in.. The buttons map to the common script commands (and I suppose they actually generate a script behind the scenes).
It's fairly easy to understand and it's a good introduction to writing plain code because the logic is quite similar.
If any form of interaction editor is brought back it should be an optional thing, so experienced people never have to see it.
:)
I totally agree with you Scotch - the Interaction Editor would be OPTIONAL, so more experienced and skilled programmers would be able to get their hands dirty in the nitty-gritty, if they want. They would be able to switch it on or off like an electric light.
Again, I'm just suggesting that for people (like me) who are more of a WYSIWYG Mentality, the new AGS would have a WYSIWYG Interface that would allow beginners, perhaps even !children to design high quality Adventure Games, minus the frustration.
Sort of like a AGS for Dummys Mode! Heheh!
That would be soooooo cool! LOL!
Just a suggestion.
Actually, I thought the interaction editor was much too complicated.
I always got straight into scripting, because it always looked so intimidating.
I won't miss it, for sure.
QuoteRPG battle elements are surprisingly non-trivial. One could make a module for that, but it's unlikely to be what everyone wants...
CJ created Adventure Game Studio, it's designed to recreate the classic lucasarts and sierra adventures most of the people on this forum love. You
can implement your own rpg system without a massive amount of effort but that isn't what AGS was designed for, and there are other engines that do that job better, like RPGMakerXP, just as Game Maker is a superior engine for creating platform games. Use the right tool for the right job and you'll save yourself a lot of hassle (this is provided you don't know much about scripting).
Good thinking but I don't really think so.
However the help manual could add some really helpful parts from the forums. I think in order to do things you have to learn scripting. We all did. It wasn't very hard.
:-\Hmmm...
How long did everyone take to learn Scripting? Curious I am.
Don't get me wrong, I have dabbled with scripting with my game construction. I even attempted to use Ahmet's RPG Scripting, but I became very frustrated with the results.
This is all I really want with my Adventure Game: I want the hero to walk around the rooms like a normal AGS Adventure Game, picking up items, using items, having conversations with people, solving puzzles.
Earning Wisdom and Honour Points like in A Tale Of Two Kingdoms. But also, being able do battle with monsters and to lose points. If all your life points are gone, the game switches to a room that says the hero is dead. Game Over. Start again or Load or Quit.
Or, if you win the battle you must have reduced the monster's life points to 0, or you can even stun it with sleeping dart.
That's all I can think of to say at the moment...
I think you'll be less frustrated if you start scripting on your own, rather than take somebody else's RPG script and attempt to modify it to suit your own plans.
The only way to learn scripting is through a lot of patience and effort. It's impossible to tell you how long it's going to take. It depends on how easily such things click in your brain and how much effort you're willing to put in.
The problem with what you're asking is that battles in RPGs are done in a million different ways. That's why no one can just give you an RPG template, because your idea of how the RPG is supposed to work will undoubtedly be different from the template makers'.
Just start with the simple things and implement everything slowly as you go, asking questions in the beginner's technical questions board after you've spent a lot of time trying to figure it out yourself. Make sure to read the manual thoroughly.
Or, easier still, as ProgZ said, use a tool that's better suited to the job. Make your game in RPGmakerXP. It makes it very easy to create RPGs because that's what it's designed to do. AGS is not designed to make RPGs. It's just one of the many different things you can do if you're willing to put in the effort. And I haven't seen any evidence that you're willing to put in that effort.
Thanks for your advice...I will investigate...though it will be sad if I end up not using AGS, since I think AGS is a cool program...but you made some valid points. Thanks.
::)
Perhaps when I get my new computer installed, with all the updates, Install the new AGS Beta, and, have more free time on my hands - I'll start training myself with Script!
Please be patient though, it will take a long time for me to get it right.
You can't rush quality.
Thanks again for the helpful advice.
My two cents:
Converting a few IE-actions into their script-equivalent isn't that hard. You don't need to be an experienced super-programmer to do that.
There isn't that big of a difference between selecting some consecutive actions and writing some consecutive lines of code. And the latter is quicker, too.
However, implementing full-fledged Final Fantasy-style battle systems is not so easy.
My point being: scripting isn't hard by itself, it depends on what you want to achieve.
So IMO there's no need for the IE at all.
:)
I have a request...
I don't want to beat a dead horse, so to speak, but Radiant, you obviously helped with the construction of A Tale Of Two Kingdoms, a very impressive Fantasy Adventure Game, I might add. Would it be possible to have available, online, a simple Module version of your game? Or perhaps an editable demo? Don't worry, I have my own character designs and art. I just find the Wisdom and Honour Score pretty cool. I thought it might help if I had something to work with, instead of working with scratch. I could EVENTUALLY tweak the working Demo to enable a hp score so the hero can die if he loses too many points.
I would make sure to mention your website in the game credits.
I believe this could help with my group project.
:)
Quote from: WackyWildCard on Mon 01/10/2007 02:56:26
How long did everyone take to learn Scripting? Curious I am.
Don't get me wrong, I have dabbled with scripting with my game construction. I even attempted to use Ahmet's RPG Scripting, but I became very frustrated with the results.
They key to it is,
don't try to do too much too quickly. If you look at an existing complicated script, you could well be put off for life, thinking "what the hell is all that?!?!".
Start small. Just write one-line scripts for interactions doing things like Display() and player.Walk(). Gradually build this up to include more than one command at a time, and slowly but surely you'll get the hang of how it all fits together.
To me it was the Interaction Editor that got me started with AGS. I was looking for simple game creation tool for a long time. AGS's Interaction Editor made it possible to me to make a silly 8-room game with no scripting at all at the time. But with looking at Text script equivalent code all the time I slowly went from IE to scripting.
AGS is a powerfull tool, and scripting is the only way to use it at full, but IE is a very easy first step. (And it makes a game creation process a point-and-click adventure at it's own.)
Now I would't miss IE a bit, but any new user with no scripting experience would.
I say: keep the Interaction Editor.
The interaction editor really assisted the learning process for me too.
Paul.
Question: Do you know how to eat an Elephant?
Answer: One bite at a time!
Ooh, please keep the optional interaction editor! I wasn't aware it had been taken out for the beta of 3.0. It definately helped me, and now that I've been away from scripting (what little knowledge I had) for a decent while and I want to get back into it, the editor would really help.
Apologies for the poor structure of above sentences.
:o ;D
Oh! Oh! Yes please! Please include the I.E. in the new AGS! I promise to learn Script, but please! Don't remove the I.E., PLEASE!
:o ;D
Thanks!
The problem with the I.E. (and the reason of its removal) was that it's never complete to a point that it's really useful (you can't even make a simple game without any scripting), and it requires a lot of work to maintain and update it until it can really do something (IMO it's even less complete in some aspects compared to the ancient obsolete Graphical script system).
So it'd be gone forever, I think there may be some other addition to the editor which aid in game making in the future, but not now, when all the focus are put into completing the new editor.
You may find some comments on it by CJ here (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31519.msg414609#msg414609).
Just to add a bit to what Gilbot said ...
The auto-complete feature of the script editor, I think, does a great job of helping inexperienced scripters along. If you think about it, it serves a similar function that the IE dialog boxes serve (i.e. show what options can be used with a specific function).
I think that auto-complete combined with some kind code generation wizard, as CJ suggests in the thread Gilbot references (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31519.msg414609#msg414609) would make up for the absence of the IE.
Quote from: CJ
I think the way forward is to have some sort of auto script-generating tool (maybe as a plugin) that works in a similar way to the interaction editor but it basically creates the script code for you.
The OpenOffice.Org spreadsheet program has a feature where a built-in function can be inserted into a formula by selecting it from a list. Once the function is selected a dialog is provided that allows the user to fill in the required parameters. Perhaps this is all that is needed to provide beginners with a comfort zone? In the long run this is perhaps a better solution because beginners will be exposed to scripting sooner than they would have otherwise and will not be frustrated by the limitations of the IE.
:)
Alright then. Next week, I get my new hardware, re-install Windows XP Home Edition, make all the required updates and install the new AGS Beta. I look forward to taking it for a spin, train myself in the techniques and continue with my game construction.
:)
Quote from: WackyWildCard on Mon 01/10/2007 19:30:53I just find the Wisdom and Honour Score pretty cool. I thought it might help if I had something to work with, instead of working with scratch.
Oh, that's easy.
// 1. make two variables at the top of your global script,
int wisdom, honour;
export wisdom, honour;
// 2. write a score function in your global script,
function scoreup (int which, int amount) {
if (which == 0) wisdom += amount;
else honour += amount;
string buffer;
StrFormat (buffer, "Wisdom %d - Honour %d", wisdom, honour);
SetLabelText (SOME_GUI, SOME_LABEL, buffer);
}
// 3.import this in the global header,
import function scoreup (int, int);
// 4.call if from your room scripts as necessary
function DO_SOMETHING_IN_ROOM () {
if (action == TOUCH && object == 4) {
Display ("Ok, you got it!");
ObjectOff (4);
AddInventory (SOME_ITEM);
// here it is:
scoreup (0, 2);
}
}
:)
Thanks a lot Radiant! That code will be very helpful in the game programming I will be working on in the future!
Much appreciated!
Hmmm... I'm all for programming just about everything. But, there are some things I've gotten used to doing with the interaction editor. For example, "When Player first Enters room before fade-in", I've gotten in the habit of opening up the interaction editor and selecting run script under this option. Then, I open the script and write the things I want to happen in this room before fade-in. I may just not have looked hard enough, but I can find in the help an equivelant sort of way to do it with scripting alone. Is there some function like on_mouse_click I can add like "on_room_start_before_fade-in"?
I've also gotten used to doing the same things with objects... I go into the interaction editor and if the player clicks say the interact icon on the object I again say run script. This creates a function that easily activates where I can then script what I want to happen. I actually haven't figured out exactly how to do this with scripting alone. I suppose I could activate the on_mouse_click and then check what the cursor is and if the mouse is over that object.
I do like the idea of the interaction editor actually creating all the script... but until then, I just want to say I have been using both, and I would hate to see the interaction editor go for this reason.
-Rich
Quote
I actually haven't figured out exactly how to do this with scripting alone. I suppose I could activate the on_mouse_click and then check what the cursor is and if the mouse is over that object.
It sounds like you haven't tried the new AGS 3.0 beta version yet. The scripting is pretty much the same as it was before. There are interaction functions just like before but they are named after the the item and functionality they are associated with. You select the item (i.e. object, hotspot, etc and then select which interacton you want from a drop down events menu located at the right hand side of the screen. This inserts the interaction function into the script just like the IE "Run Script" command did before.
It works much like the GUI system does in AGS 2.72.
Someone correct me if the above description is less than accurate. I haven't used the new stuff much, just took it for a couple of quick test drives.
Quote from: WackyWildCard on Mon 01/10/2007 02:56:26How long did everyone take to learn Scripting? Curious I am.
If you get a week or two with nothing to do other than working on your game, you'll get a pretty good understanding of it in that time. Set yourself a goal, for example making a custom interface for your game, open up the help file and start coding it feature by feature.
The way I started out was with scripting my own save/restore interface. I hadn't coded anything since the days of BASIC on the Commodore 64 (oh god how I hated those "poke" commands), I didn't even go through the AGS tutorials. I just sat down and tried to break every function down into logical steps, one GUI element at a time. Whenever there was something I didn't know how to do, I used the help file's search function. Every time I would get a compile error (pretty much every line of code), I'd fix it, test the game to see that it worked as intended and then move on. A month into development I was coding advanced features that I'd never seen in AGS games before, such as the searchable conversation log.
Looking at my code now, there's lots of things I would have done differently (and I actually went back and optimized stuff and re-did some sections whenever new features - such as the String data type - were added to AGS). But the main thing is that the old code worked, despite sometimes getting the stuff done in very roundabout ways.
Once you understand the logic of AGS script, you'll be able to plan things out quite well even before opening up the script editor. And between the help file, the editor's auto-complete feature and the tech forum, there's very little that you won't be able to do - and do it much faster than using the Interaction Editor.
As CJ said, your shouldn't try too much too quickly, but at the same time, once you know the basics, spending a week on getting familiar with advanced features like structs, arrays and while loops will actually make things much easier further down the line.
Quote from: rich on Fri 05/10/2007 06:43:59
Hmmm... I'm all for programming just about everything. But, there are some things I've gotten used to doing with the interaction editor. For example, "When Player first Enters room before fade-in", I've gotten in the habit of opening up the interaction editor and selecting run script under this option. Then, I open the script and write the things I want to happen in this room before fade-in. I may just not have looked hard enough, but I can find in the help an equivelant sort of way to do it with scripting alone. Is there some function like on_mouse_click I can add like "on_room_start_before_fade-in"?
I've also gotten used to doing the same things with objects... I go into the interaction editor and if the player clicks say the interact icon on the object I again say run script. This creates a function that easily activates where I can then script what I want to happen. I actually haven't figured out exactly how to do this with scripting alone. I suppose I could activate the on_mouse_click and then check what the cursor is and if the mouse is over that object.
I do like the idea of the interaction editor actually creating all the script... but until then, I just want to say I have been using both, and I would hate to see the interaction editor go for this reason.
-Rich
You can still have event-based functions in AGS 3.0. Think of it as an I.E. with only a Run Script option. :P
Rich, the area you are looking for is right here:
Just click the lightning bolt in the right pane to pull up the old room interactions, then open one to the right to go to the function for it (or create it if one does not exist).
http://members.cox.net/progzmax/scr1.gif
I'll be honest and say I haven't used 3.0 yet. I think I'm waiting for the all clear on it. Should be a smooth transition for me though. Looks like everything is there that I need.
(I might be totally on the wrong track here, so please correct me in that case.)
Rich, there wasn't any (feasible) way to do everything using script only.
What "using script only" actually meant was that the only action you'll ever select in the interaction editor is "RunScript".
Everything else is then coded directly in the room's or global script, but it was inevitable to use the I.E. to make AGS create the needed functions.
So even people who did script everything had to use the I.E. in exactly the way you've described.
(Of course in theory one could put countless ifs inside on_mouse_click and repeatedly_execute to check for regions, clicks on objects and everything else, keeping the room scripts empty in the process, but that would become a horrific mess in no time.)
Oh, excellent to know! I suppose I should've downloaded the new version before making a comment. I think this new version will work out grand.
I find the interaction editor is an excellent organizational tool. My room and global scripts are completely out of order. Trying to find anything just by looking at the scripts takes me forever. It's nice to be able to click on the IE and jump right to the relevant portion of code. It also makes sure I don't get distracted and edit the wrong section.
That being able to jump to a certain piece of code is handy is unquestioned.
This thread is really about the need to include the various other actions besides RunScript.
AGS 2.8/3.0 has ditched them but kept the functionality to jump to a specific function.
Also, since the functions now have relevant names (Room_Load, oDoor_Interact as opposed to room_a, object2_f, etc) it's actually far easier to find things purely in the script, without using the Events menu. I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?
Maybe it's wrong, but I had to smile at the death of the Interaction Editor...
Quote from: Ashen on Fri 12/10/2007 10:42:47
Also, since the functions now have relevant names (Room_Load, oDoor_Interact as opposed to room_a, object2_f, etc) it's actually far easier to find things purely in the script, without using the Events menu. I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?
Maybe it's wrong, but I had to smile at the death of the Interaction Editor...
<shrug> Now I can stomach the loss without an issue, especially as you and Khris have reminded me that the core functions remain.
Eight months ago when I was deciding whether to write my game in AGS, seeing there was a shallow end to wade into first helped me start.
Quote from: WackyWildCard on Mon 01/10/2007 02:56:26
:-\Hmmm...
How long did everyone take to learn Scripting? Curious I am.
Don't get me wrong, I have dabbled with scripting with my game construction. I even attempted to use Ahmet's RPG Scripting, but I became very frustrated with the results.
This is all I really want with my Adventure Game: I want the hero to walk around the rooms like a normal AGS Adventure Game, picking up items, using items, having conversations with people, solving puzzles.
Earning Wisdom and Honour Points like in A Tale Of Two Kingdoms. But also, being able do battle with monsters and to lose points. If all your life points are gone, the game switches to a room that says the hero is dead. Game Over. Start again or Load or Quit.
Or, if you win the battle you must have reduced the monster's life points to 0, or you can even stun it with sleeping dart.
That's all I can think of to say at the moment...
The nice thing about AGS's scripting is that it is fairly generic as far as syntax goes. That is, if you bother to learn AGS's approach to things, you actually will not have a hard time learning Javascript, PHP, and other high-level scripting languages (and conversely, if you already know said languages, learning AGS's scripting is super simple, as I can attest, having just started with it a week ago and already going along at great guns).
My recommendation, if you are totally new to scripting in general, is NOT to necessarily start with AGS. Do a few Javascript tutorials that you find on the web; get used to writing basic program flow (I started Javascript by writing a tic-tac-toe program), and once you have a little comfort in at least reading scripts under your belt, come back to AGS and take a look at how it does things. (Other than the fact that AGS is often more object oriented than Javascript, it has pretty much the same syntax.)
Scripting is not all as hard as it looks -- you are basically just charting out logical actions for the interpreter to follow or things for it to check. It's also a very marketable skill -- being an AGS scripter is not something that will be very impressing on the resume, but knowing how to use Javascript and PHP can easily make you a more exciting job candidate down the line.
Just my two cents! I don't script for a living but my ability to script (Javascript, PHP, VBScript, etc.) has helped me to get many a job, as it makes me much more capable than your average candidate in my non-computer science field of work (I am a historian by trade).
Quote from: Ashen on Fri 12/10/2007 10:42:47
I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?
Look at the top of the script editor. There's a ComboBox with all the functions in the open script. Clicking on the script's name will take you to the function.
Quote from: VK Dan on Mon 15/10/2007 18:30:35
Look at the top of the script editor.
OK, so just 'not where I looked', then. Thanks for that, makes things a lot easier.
Actually, I had looked there, I just didn't realise what it did - this is a very minor quibble, but if you select a function that's currently on the screen, it moves the cursor but doesn't always scroll to the relevant line. So, it's not always obvious that it's actually done anything. That's my excuse for not having seen it sooner, and I'm sticking to it...
There were two little issues that confused me and they may be resolved in the new version but here they are anyway.
First is the different ways that things are removed or enabled...
RemoveWalkableArea(2);
RestoreWalkableArea(2);
EnableRegion(2);
DisableRegion(2);
It seems to me that it would be simpler if it were always either Remove/Restore or Enable/Disable instead of sometimes one or sometimes the other.
The other point is
SetCharacterSpeechView(2,12);
SetCharacterIdle(2,12,30);
ChangeCharacterView(2,12);
cEgo.ChangeView(12);
cEgo.SpeechView = 10;
Again, the last one is the question. Why is SpeechView with an equal sign and nothing else is?
That's it and not that it's a big deal but it would sort of streamline the code I should think.
Quote from: theatrx on Tue 16/10/2007 02:12:15
RemoveWalkableArea(2);
RestoreWalkableArea(2);
EnableRegion(2);
DisableRegion(2);
Since there're some numbers of region-related features, the EnableRegion() and DisableRegion() functions are now replaced by the structural property Region.Enabled, while the Remove/Restore-WalkableArea() functions are still used, but as there aren't many functions related to walkable areas I don't think they would be changed soon. So, in other words, en/dis-abling walkable areas and regions are still done in different ways, but I think because of the nature it wouldn't matter, at least for now.
Quote
SetCharacterSpeechView(2,12);
SetCharacterIdle(2,12,30);
ChangeCharacterView(2,12);
cEgo.ChangeView(12);
cEgo.SpeechView = 10;
Again, the last one is the question. Why is SpeechView with an equal sign and nothing else is?
It's because SpeechView is a variable (err... property, if you insist), so we don't need two functions to get/set it, and you can just retrieve its value or change it just by accessing this property directly. For the other functions, probably it's how the engine works so it won't work properly if you just change the value to a variable (moreover, for functions like SetCharacterIdle() which can take more parameters you can't do this by a single property). If you're uncomfortable with the '=' assignment, just create wrapper functions for SpeechView.
No Gilbot... you misunderstand. All I am saying is that in both instances for the sake of consistency, the coding should be reflected in one or the other way. Meaning...
RemoveWalkableArea(2);
RestoreWalkableArea(2);
This is fine since it works well with the autofill feature but then it should also be
RestoreRegion(2);
RemoveRegion(2);
This way Regions, Hotspots and Walkable area would all be removed and restored in the same way rather than bringing in another command for one of them
The other point is much the same. Chris has established that views and options have been established in much the same way except for speech view which has an "=" sign thrown in. I'm simply saying that speech view should be the same as the others.
SetCharacterSpeechView(2,12);
SetCharacterIdle(2,12,30);
ChangeCharacterView(2,12);
cEgo.ChangeView(12);
cEgo.SpeechView = 10; So, this would become
cEgo.SpeechView(10);
That's all. It's just sort of a bummer in both instances that you have to remember that that one line of code is different from all the rest. That's all I'm saying. Sorry to be a pain.
Quote from: theatrx on Tue 16/10/2007 05:29:49
No Gilbot... you misunderstand. All I am saying is that in both instances for the sake of consistency, the coding should be reflected in one or the other way. Meaning...
...
This way Regions, Hotspots and Walkable area would all be removed and restored in the same way rather than bringing in another command for one of them
I
understood what you meant, but I had already stated that regions are now objects that can have their own properties, including
Enabled, so the functions Enable/Disable-Region() are now obsolete and should not be used anymore, so it doesn't matter whether we need to change these functions to match those of walkable areas. Moreover, as I stated, that walkable areas are not made into objects yet (not much benefit in doing so ATM I think) so it's okay to still have their own pair of Remove/Restore-WalkableArea() functions instead of an Enabled property like regions.
Similarly for the view part, I had written, Character.SpeechView is a
property, not a function, so assignment with = is perfect. If it's made into a function, you need
two functions instead of one:
cEgo.
SetSpeechView(10);
cEgo.
GetSpeechView(10);
In the other cases, just changing the value of a property is possibly not enough for the engine to work, so they need functions.
theatrx, you're mixing old and new style scripting there, so of course there are inconsistencies. Character.ChangeView is a function because it permanantly changes the main view of the character, when usually one just wants to do it temporarily which is better to use Character.LockView for. So CJ tried to discourage people from doing so by making it a function rather than a property and making the NormalView property read-only.
All the properties have underlying Set/Get functions that are invisible to us, so CJ could change it if he wanted.
Just for reference:
I think this recent thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32703.0) illustrates another good reason to eliminate the IE. Note that in order to adequately explain the problem, it was necessary for the poster to grab a screenie, annotate it, upload it, and then link to it, in the thread. I may be wrong, but I think that most people who ask for help using IE are not willing or able to go to all this trouble to post a question. And I would be very surprised indeed if someone went through this process to post a reply. So typically this is all done via verbal description which IMHO is less than optimal.
Contrast this to the equivalent in script where one can just cut and paste a portion of one's script directly into a post asking for help and where people often respond by posting corrected or alternate snippets of script that can be used directly by the original poster.
So the difficulty in asking and answering IE programming questions in the forum is another reason to justify the dumping IE.
Yep indeed, and also being an external image the relevant screenshot could get deleted or something, making the original thread useless for other people looking for help at a future moment. Not to mention that the forum searching mechanism won't work with images.
I've edited the post mentioned by RickJ, to include a text version of the IE setup (the image is still there as a link). So, it IS possible to describe IE problems without using a screenshot (KhrisMUC had already included 'psuedo-IE' text in his reply, in fact) or confusing verbal descriptions, it's just a lot more time consuming than using a picture - and so even fewer people are likely to do it.
Obviously, I'm not defending the IE, just explaining why there's no image in a post that was linked to because it used an image.
Quote from: Ashen on Fri 12/10/2007 10:42:47
Also, since the functions now have relevant names (Room_Load, oDoor_Interact as opposed to room_a, object2_f, etc) it's actually far easier to find things purely in the script, without using the Events menu. I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?
Maybe it's wrong, but I had to smile at the death of the Interaction Editor...
man, I'm really glad to hear that. Honestly, I wish it had been that way all along. It makes things much easier to read and organize. New question though... what will happen to games that have been worked on in 2.72 or earlier and are updated into 3.0 or higher. Will it still understand the room_a and object2_f functions that were created in the earlier versions? Will there be a way perhaps to automatically update them into the new naming scheme automatically? If not, will there be a way to conveniently manually upate the naming scheme?
Quote from: rich on Sat 20/10/2007 00:40:45
what will happen to games that have been worked on in 2.72 or earlier and are updated into 3.0 or higher. Will it still understand the room_a and object2_f functions that were created in the earlier versions?
They will be imported and work the same as before.
QuoteWill there be a way perhaps to automatically update them into the new naming scheme automatically? If not, will there be a way to conveniently manually upate the naming scheme?
You can manually change the names. Just go to the events tab for the object/room/whatever and type in the name you want the function to have. Then make the room_a function have the same name you just typed in. It's not the most convenient way, but it works.
Quote from: KhrisMUC on Sat 06/10/2007 01:04:15
Rich, there wasn't any (feasible) way to do everything using script only.
What "using script only" actually meant was that the only action you'll ever select in the interaction editor is "RunScript".
I beg to differ.
In fact none of my games use the interaction editor
at all, not even for RunScript. Instead, the global script figures out what to do exactly, and uses CallRoomScript as necessary for hotspots etc.
:) Finally!
Got my new Computer System Humming sweetly! I've installed XP Home with all the updates, and AGS Beta! I'm so excited. I'm going to spend some time whenever I'm not working or studying to learn Script. Like CJ said, I'm going to learn a little at a time, not wolf it all down in one sitting. Rome wasn't built in a day.
I'll keep the Forum updated on progress on my group project. ;)
WackyWildCard :)
Just found out a thing that would be nice in the latest edition of AGS.
Since its Tab based it would be nice to close the tabs with a little "X" in the tab.
what you guys think?