Hi,
Slightly irritated with this.
Basically I'm attempting to make an introduction cutscene in which the following is happening:
- A conversation between two characters is playing out
- 1 object and both characters is moving up and down every 10 loops.
If I use character.say then the function blocks the script until the character has said the thing they are saying and goes onto the next command. This would be fine except that I want the vibrating objects/characters (they are in a space ship incase you are wondering) to continue to do so in the background during the conversation.
So next I tried character.saybackground method. The result of this was all the dialog being displayed immediately and at once. I was unable to find anything on creating threads in the help file or anywhere else on these forums... is it possible in AGS?
There is one option left open to me which I will only take if completely nessesary - and that is counting game loops and using a massive switch in repeatedly execute...
How does everyone else do their complex cutscenes?
Use repeatedly_execute_always() for the background animations.
Ah yes. Thank you.
I was under the impression repeatedly execute always was a single thread only usable in the global script. The help should be more specific with reguard to that.
From the Manual:
repeatedly_execute_always()
Called every game cycle, even when a blocking routine (eg. speech/cutscene) is in progress. You cannot call any blocking functions from this event handler. You can have a repeatedly_execute_always function in both your global script and in any room scripts where you require it.
(My emphasis.)
Admittedly, it doesn't mention that you can also have one in every MODULE script, but it seems specific enough to me.
Yeah, I was actually refering to the 3 thread diagram in the manual. Its misleading. It should depict the 'Room' thread parenting two fibers (which are standard and repeatedly execute always) and the 'Game' Thread should also parent two fibers.
I feel that the game's scripting language is somewhat caged. You only ever work with sections of code... even when you open the global script. It would be nice if we had access to the full script for the entire game as well as the registry for function names (eg what makes the room thread call room_a() when x happens).
I really do feel that the interface hampers me in this respect. I could really get a lot more done a lot faster if I had direct access to the whole game script.
(Please don't quote the whole previous post.)
Quote from: Sythe on Mon 10/07/2006 21:40:33I feel that the game's scripting language is somewhat caged.
This kind of programming is called object-oriented. It can be a bit hard to get used to if you are only familiar with BASIC-like languages, but you'll find that especially for e.g. an adventure game engine, it's way more convenient.
And this is also the reason why you seem to have difficulties understanding the 3 thread diagram. Things in rep_ex_always are always run in the No-Block-thread, whether the function is in one of the room scripts or not.
There's no such thing as a hidden "full game script". Everything the engine does is right there in the accessible scripts.
Of course there's a thread in the background that continuously calls the rep_exes and event, keypress and mouseclick functions when triggered, but that's it.
And why would you want to now what makes room_a() getting called? Firstly, the "x" that happens is written right at the beginning of the function, and secondly, why don't you just double-click the RunScript-Interaction you want to edit?
QuoteThere's no such thing as a hidden "full game script".
I think Sythe was refering to, for example, being able to access the Global Script AND the Room Script together, not having to quit out of one to edit the other.
I also think this is a discussion that could get way off topic - and out of hand - for a Beginners Tech thread. If you want to continue it, keep it to PMs.
Sythe: If you have any specific suggestions for changing the interface, you could try making them in the Tech Forum. However, there's no guarantee they'd be implimented in your lifetime ;)
I appreciate you taking the time to try to explain the concepts to me but you guys don't exactly get what I mean. I know what oo programming languages are - that said I know java and am in the middle of a software engineering degree.
When I said ‘caged' I was referring to only being able to edit sections of code. I had a look through the game files and it appears this is just the way the engine is built. If I were to write an adventure game engine I'd basically have my scripting language and its interpreter then build the GUI as a separate program. Its function would be to write the majority of code for you if you chose. That way the user has the option of coding the game fully in the scripting language or using the GUI as a sort of high level drag and drop interface or a combination of both.
But yes, this thread is getting off topic. I will post some suggestions in the appropriate forum when I am finished my game.
You might want to check out the Queued Background Speech module(s), too
Quote from: Sythe on Mon 10/07/2006 23:07:55
When I said ‘caged' I was referring to only being able to edit sections of code. I had a look through the game files and it appears this is just the way the engine is built. If I were to write an adventure game engine I'd basically have my scripting language and its interpreter then build the GUI as a separate program. Its function would be to write the majority of code for you if you chose. That way the user has the option of coding the game fully in the scripting language or using the GUI as a sort of high level drag and drop interface or a combination of both.
I think I understand where you are coming from. The GUI editor is only there to help newphytes get into the actual scripting, as all the true powerful stuff in AGS needs to be done in scripting. CJ has said multiple times that the GUI editor will probably get no love, and I wouldn't be surprised if it wasn't removed completely at some point.
As far as your "caged" comment, I do agree that the cryptic way AGS labels it's methods is a bit frustrating, especially when you type faster than you point and click. Personally I wouldn't mind it split a bit more with objects getting their own global object script, GUI's with their own global GUI script, just to make things a bit more readable, and if someone wanted, could do oObjectName.Look{}, oObjectName.Use{} so on and so forth. However, the way AGS is going I could actually see this in the future, or something similar (moving toward full OO).
Right now you can look at the full global script, and each full game script. However if you were doing so, and wanted to add a look interaction for hotspot 3, you would still have to go through the editor instead of typing out hHotspot3Name.look(){}.
I believe for right now, that it is the way it is because it is fairly intuitive, and allows both novice and expert users to do what they want. I've gotten away from trying to think of any scripting language as a full fledged programming language (especially with MUD scripts), which has made it easier for me to shed some of the coing norms that come with knowing code.
Which part of "If you want to continue, keep it to PMs" didn't you understand?
SSH: good suggestion, I'd completely forgotten about them.
If this becomes a general discussion of AGS's scripting methods, it'll get locked.
As for the referenced modules:
Scorpiorus's 2.62 and earlier queued speech code (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=11868.0)
SSH's 2.71 and later queued speech module (with subtitles) (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=25344.msg318366#msg318366)
monkey_05_06's 2.71 and later queued speech module (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=23806.0)