Zeriab

I have revised the tutorial so it should now be easier to understand ^_^ I have also provided answers for exercise 1

Maybe I have returned, I was just too lazy to post a topic about it. I am glad you like my tutorial ^_^ And I have a fan. I don't really know what to say. This feels so peculiar. *hugs* - Zeriab

Common Events Note: This is aimed at intermediate eventers Common events are pretty much like map events with change that they are made common to all maps and don't have pages. (Or exactly one page) I will discuss various issues of common events though first take a look at this common event and map event: What happens when you trigger the map event? What would happen if you change the common event's trigger to Parallel instead of Autorun and then trigger the map event? What happens if you call the common event from a battle event? Basically, how does self-switches work in common events with the added question about order of execution. The call stack Self-switches The common events do not have self-switches attached to themselves, but you can still use the self-switch functionality. They work differently than in map events. To help understand how self-switches work in common events I will introduce the concept of a Call Stack. Whenever you use the Call Common Event... event command you place the common event on the Call Stack. (On top of the event which calls the common event) To help you understand the Call Stack try to imagine a stack of papers. Each time you call a common event you place on top of the stack just like you would place a piece of paper on top of the paper stack. Whenever you have processed the top common event you remove it from the stack and look at the event which called the common event since it is now on top. This event is then continued from where it called the common event. A bit like you read the paper on top of the stack. You come to a 'call common event' and place another paper on the stack. Once you have read that paper you go back to the previous paper and read from where you left it. All except the bottom event (the event which is not called with the Call Common Event... event command) in the Call Stack are common events because only common events can be called. The bottom event can be a map event, battle event or a common event. The bottom event is the important event when considering self-switches since the Control Self Switch... command only makes any difference when the bottom event is a map event. If the bottom event is a map event then the self-switches changed will be the map event's self-switches. Likewise is the self-switches of the map event considered in conditional branches. If the bottom event is not a map event then all self-switches are OFF and you cannot turn them ON. You can have several map events call the same common event. When each map event is interpreted it is used for considering self switches. Here is an example of a chest (2 pages) and a common event: Set move route As you can see I have used a Set Move Route... command which works similarly to Control Self Switches.... If you select This Event as the event to use it will only work if the bottom event of the Call Stack is a map event. The map event is the one moved just like how the self switches of the map event were considered in the common event. If the Player or a specific event was chosen then it will work on the map, but not in the battle. Note that when choosing a specific event the id is considered. If you call the event on a different map it will try to use the event with the same id on the different map. Note also that you can only pick among the events on the map you look at (or lasted looked at). You may therefore need to choose a different map before you can pick the event you want. Code reuse After having made the event above you can just copy and paste the chests to get chests that you can only open once. What are the advantages of this approach? What are the disadvantages? If you change the common event you will change the functionality of all the chests. If you want it to open a little faster you just have to do it in the common event. No need to find all chests and change them all. A disadvantage which I am sure you have realized is that all the chests currently contain the same thing, 50 gold. You can of course easily change it, but you would change the contents of all the chests. What if you wanted the chests to have different contents? Well, you can remove the message and gold gain from the common event and place it in the chest. Then you can change it from chest to chest while still sharing the way of opening a chest in the common event. You can say that you reuse the code for opening a chest. You only define it one place and then reuse it in each chest. Of course you can make a common event which other common event calls. Code reuse is about preventing copy-pasting of event code where you make no alterations. Does this mean it is always a good idea to share functionality? NO! It is not always a good idea to share functionality. You have to evaluate the need on a case-by-case situation and sometimes a solution which is preferable in one situation or game is not preferable in another situation or game. Code reuse typically increases complexity initially although it may turn out later to increase the productivity. On the other hand it may turn out to decrease the productivity. Take a look at this event demo: http://www.rpgm.org/downloads/1421/Doors.zip (Mirror) It is a door system where the player can pick the preferred functionality of the doors, or at least the standard doors. Is it ridiculous? Has too many common events and effort been spent on the doors? Is it even worth it? Is it too little? It is case-dependent. It most cases probably a little too much, but then again, maybe not. Maybe the player will like being able to speed up transitions after a while. It may just add an extra touch. I do hope you see what I am getting at. There is of course much more to be discussed about code reuse but I will leave that to another tutorial. "Common event call has exceeded maximum limit." You get this error when there are too many events on the call stack. There is a fixed limit of at most 100 events on top of the bottom event. If you try an additional call common event you get the error. You can alter this limit with a simple edit to the Interpreter script. Note that the amount of calls is limited by the system stack as well. With a simple event which called itself I got to make 491 calls before getting a SystemStackError. Do not make the mistake of thinking you can use up to 491 calls since some event commands can easily need more calls and with the alias style in many scripts you can easily have more calls. I can't imagine a situation where the 100 call limit will be a problem except for badly designed events. You can for example consider the situation where you have one common event calling another common event which in turn calls the first common event. There, you have a cycle. This error should definitely be discovered, but you can have designs where it may not necessarily be discovered. Consider an evented menu where you have a common event for each menu item. The menu is shown as well. If you move up or down you call the common event corresponding to the new menu item and then just prepare for that event to exit afterwards. When you have gone up and down more than 100 times you get the error. It is definitely possible that you won't test for this. How should it have been designed instead? One solution could be to introduce a common event which launches the common events for each menu item corresponding to a variable. Each of the common events will exchange the explicit calls to other menu common events with an implicit call by changing the variable and then exiting. The launcher common event will then call the common event. We now have a structure which should not continuously increase the size of the stack. (The amount of papers in it) Exercises These exercises are totally optional. You can use them to get a feeling of what I am talking about and for getting some experience. Exercise 1 The first exercise is about answering the questions answered at the very top about the Mysterious person. Try to guess what messages will be shown when the common event trigger is on Autorun. Try to guess what messages will be shown when the common event trigger is on Parallel. Try to guess what messages will be shown if a battle event calls the common event. (Common event triggers won't work in battles) I suggest you write it down and then use RMXP to check it the answers. Be sure to enter the events exactly as shown here. Here are the answers although I recommend you using RMXP to check the answers if possible. Answers Try to guess what messages will be shown when the common event trigger is on Autorun.Message 1: ON Try to guess what messages will be shown when the common event trigger is on Parallel. Message 1: ON Message 2: OFF Try to guess what messages will be shown if a battle event calls the common event. Message 1: OFF Exercise 2 This exercise revolves around making a chest system you are satisfied with. Try to make it easy to copy while still being easy to modify. This is about making your game quicker. You can additionally consider storing how many chests have been opened for stats fanatics. (Believe me; if you get an idea like this far into the project you will be VERY pleased if all the chests use a common event) Exercise 3 Everybody loves puzzles.(Untrue statement) Therefore this exercise is about making a puzzle or at least some building stones for puzzles. The idea behind the puzzle is to get from point A to point B. There are some objects in the way with which you can interact. Here is a list of the building blocks: A boulder which you can push forward A boulder which keeps sliding forward until it hits something or you push it another way A boulder which you only can pull backwards A boulder which you can both push and pull A boulder which you also can drag sideways Anything else you can imagine Try to create nice scalable solutions. Hopefully boulders you can just copy and paste. I won't promise that all of these types of boulders are feasible to create nice and scalable. It is up to you to find out. Good luck. Final notes While this is very tutorial like I want discussions. Hopefully insightful discussion about beneficial common event use. I realize that I have only scratched the surface here. I haven't talked about scalability yet. I feel that it is a bit too much in an intermediate eventing tutorial. I will be happy to hear any suggestions on how to improve this tutorial. I want to thank everyone who takes time off for reading my tutorial and everyone who replies. I hope you will become wiser in your eventing decisions. Thanks Iceplosion for some very nice critique! *hugs* - Zeriab

That is because I uploaded the wrong demo -_- It is the same link.

I didn't know had any fans. It makes me happy and embarrassed at the same time. Thanks for coming to the rescue and uploading the downloads. I have replaced the links for the RMXP to the ones on my site. I don't have the rm2k version anymore so I am afraid it is lost. I am keeping the links just in case they begin to work again. This is my very first script I made over 3 years ago. It is very sucky. Here is an event system which is pretty much the same system except that it works with terrain tags: http://zeriab.plesk3.freepgs.com/root/even...g%20Example.rar *hugs* - Zeriab

Don't definitely use it. Only use it if you have an actual need. ;)

VX has functions build in for this purpose. XP has not. Hence my reason for asking ^^ Search for an AMS (Advanced Messaging Script). You need one of these to do what you want. On the top of my head I can mention Dubealex's AMS, Ccoa's UMS and Wachunga's Multiple Message Windows. *hugs* - Zeriab

Well... You can use this if you want to wait in seconds rather than frames: class Interpreter #-------------------------------------------------------------------------- # * Wait #-------------------------------------------------------------------------- def wait(seconds) # Set wait count @wait_count = (Graphics.frame_rate * seconds).to_i # Continue return true end end Just put wait(3) in a script call for waiting 3 seconds. Put wait(0.5) for waiting half a second. wait(3.5) waits for 3 and half a second. You get the idea I am sure. As a bonus this will still work if you change the frame rate ^^ *hugs* - Zeriab

If you are thinking about the amount of frames in context with the Wait... event command then its 20 frames per second regardless of smooth mode or not. (You can change the frame rate with Graphics.frame_rate but as long as you don't change it the above holds assuming no lag)

Are you using RPG Maker XP or RPG Maker VX?

I'm glad you like it ^^ There is indeed some learning curve, but once you know how to use it you can benefit greatly from it in some case.

Scheduler ~ Scripting Tool Version: 1.0 Introduction How many of you tried creating a parallel process where you put in an amount of frames and then a script call or something else afterwards? Basically a simply way of doing something after an amount of frames. This is the principle behind the script. To schedule pieces of code to be executed after an arbitrary amount of frames. No making decrementing counters. The scheduler takes care of all that or well most of it. It is still not as simple as using the wait event command. Script #============================================================================== # ** Scheduler #------------------------------------------------------------------------------ # This class allows to schedule a proc or method call a given amount of frames # into the future with any amount of arguments #============================================================================== class Scheduler #========================================================================== # ** Order #---------------------------------------------------------------------------- # An order is a proc, method or something else which has 'call' as a method, # and the arguments to pass along. #========================================================================== # Create an struct for containing the data Order = Struct.new(:callable, :arguments) # Extend the class with a call-method which calls the callable with the args class Order #------------------------------------------------------------------------ # * Call the callable with the present arguments #------------------------------------------------------------------------ def call callable.call(*arguments) end end #========================================================================== # ** RecurringOrder #---------------------------------------------------------------------------- # An order which is recurring every specified amount of time until # FalseClass is returned from the call. # Note that arguments remain the same for each call #========================================================================== # Create an struct for containing the data RecurringOrder = Struct.new(:callable, :arguments, :frames) # Extend the class with a call-method which calls the callable with the args class RecurringOrder #------------------------------------------------------------------------ # * Call the callable with the present arguments #------------------------------------------------------------------------ def call result = callable.call(*arguments) unless result == FalseClass Scheduler.schedule_recurring(frames, frames, callable, *arguments) end end end #========================================================================== # ** Mapping #---------------------------------------------------------------------------- # Maps an index to an array. Values can be added to these value. # Each array starts empty. #========================================================================== class Mapping #------------------------------------------------------------------------ # * Initialization #------------------------------------------------------------------------ def initialize @mapping = {} end #------------------------------------------------------------------------ # * Add an value to a given index #------------------------------------------------------------------------ def add(index, value) @mapping[index] = [] if @mapping[index].nil? @mapping[index] << value end #------------------------------------------------------------------------ # * Retrieve the list of values mapped to the index #------------------------------------------------------------------------ def get(index) return [] if @mapping[index].nil? @mapping[index] end #------------------------------------------------------------------------ # * Delete the array the index is mapped to. Conceptually it is now empty #------------------------------------------------------------------------ def empty(index) @mapping.delete(index) end end #-------------------------------------------------------------------------- # * Initialization #-------------------------------------------------------------------------- def initialize # This maps @mapping = Mapping.new @tick = 0 end #-------------------------------------------------------------------------- # * Scheduling #-------------------------------------------------------------------------- def schedule(frames, callable, *arguments) # Create an order order = Order.new(callable, arguments) @mapping.add(frames + @tick, order) end #-------------------------------------------------------------------------- # * Scheduling #-------------------------------------------------------------------------- def schedule_recurring(frames, frames_to_wait, callable, *arguments) # Create an order order = RecurringOrder.new(callable, arguments, frames_to_wait) @mapping.add(frames + @tick, order) end #-------------------------------------------------------------------------- # * Update the scheduler #-------------------------------------------------------------------------- def update # Get the orders for the current tick orders = @mapping.get(@tick) # Delete the mapping's reference to the list of orders @mapping.empty(@tick) # Call each order for order in orders order.call end # Advance the tick (next frame) @tick += 1 end #-------------------------------------------------------------------------- # * 'Singleton' principle used although you can easily make # an extra scheduler. (Class method only works for this) #-------------------------------------------------------------------------- @@instance = self.new def self.instance return @@instance end ## Class methods point to the equivalent instance methods def self.schedule_recurring(*args) instance.schedule_recurring(*args); end def self.schedule(*args) instance.schedule(*args); end def self.update(*args) instance.update(*args); end end The latest version will be present here: http://zeriab.plesk3.freepgs.com/root/scri...r/scheduler.txt You could check it if more than a month has passed since last edit. You know, just in case. More generally all material related to the Scheduler except the forum topic can be found here: http://zeriab.plesk3.freepgs.com/index.php...ipts/Scheduler/ Here is a binding if you want the scheduler to work for every frame. Basically for each Graphic.update the scheduler is updated. It doesn't matter whether you are in a menu, title screen, battle. As long as Graphic.update is called so is the scheduler. (The main scheduler) module Graphics class << self unless self.method_defined?(:scheduler_update) alias :scheduler_update :update end def update(*args) scheduler_update(*args) Scheduler.update end end end Instructions <span onClick="this.nextSibling.style.display=((this.nextSibling.style.display=='none')?'':'none');" onclick="this.nextSibling.style.display='';"><div class='spoilertop'>Semi-big and evil instructions</div></span><span style='display:none;'><div class='spoilermain' >You can schedule in two ways. You can do a one-time schedule which works like this: (Using the class method) Scheduler.schedule(frames, callable, *arguments) # Here's an example Scheduler.schedule(65, Proc.new {|x,y| p x,y}, "A string", 42) The 65 means that the proc will be called after 65 frames. (Or 65 ticks to be more precise. 1 update = 1 tick usually) After 65 ticks the proc {|x,y| p x,y} will be called with the arguments x = "A string" and y = 42. (The *arguments means any number of arguments. This can also be no arguments at all) The Scheduler uses duck typing and assumes that anything which has the .call method works properly in the context. I imagine procs and methods to be the most commonly used. The next is that you can schedule a recurring call which works like this: (Using the class method) Scheduler.schedule_recurring(frames, frames_to_wait, callable, *arguments) # Here's an example Scheduler.schedule_recurring(65, 30, Proc.new {|x,y| p x,y}, "A string", 42) The arguments is the same as for the one-time with the addition of the frames_to_wait argument. This specifies that after the first 65 ticks each recurring call will happen after 30 ticks. This will continue until the callable returns FalseClass. (Mind you it's false.class and not false) Now you have to update the schedule every frame or it won't schedule properly. Here is a binding where the scheduler updates every time the Graphics module updates. (Made for XP. I am unsure whether this part works in VX) module Graphics class << self unless self.method_defined?(:scheduler_update) alias :scheduler_update :update end def update(*args) scheduler_update(*args) Scheduler.update end end end Note that the class methods only work for one scheduler. I believe this should be the generally working Scheduler.</div></span> Compatibility The Scheduler alone use only Ruby and could easily be placed in a Ruby if one wanted that. It is highly unlikely that you will encounter any compatibility issues with the backbone alone since it is independent from RGSS/2 library. On the other side there could potentially be problems with the bindings which makes use of the scheduler so it actually does something in game. Currently there is only the Graphics.update binding which makes compatibility issues very unlikely. Future Work - Explicitly exit/stop a scheduler. The scheduled items can then be discard, executed or maybe something else. - Error handling. (This may be an external. I.e. not embedded in the core) - Documentation Credits and Thanks Credits goes to Zeriab for creating the system I would like to thank everyone using their time to try and use my system. I would like to thank everyone reading this topic. Thanks. Author's Notes I would be delighted if you report any bug, errors or issues you find. In fact I would be delighted if you took the time and replied even if you have nothing to report. Suggestions are more than welcome. Note that I will release a demo which shows a couple of ways of using this script. Note also that I will always make a post when I have an update. (Small stuff like typos excluded) And finally: ENJOY! - Zeriab

Thanks Kiriashi and np krazykat. This script is for RPG Maker XP which I know see wasn't immediately clear. I have changed the topic to reflect this although I wish I could put a [XP] in front of the title name. If you have tried it in RMVX then either it crashes or does not work properly. (Not sure which)

@RMXPirate: Sorry for not replying earlier. Please do report what your tests showed. Also feel free to put the script in your Scrive if you want. @krazykat: Yes, you are allowed to use it in a commercial game ^_^ I wish you luck with your game. *hugs* - Zeriab

Protexis manages the sales. They also provide the serial you get when you buy the game. I have heard about similar cases which was solved by contacting Protexis.

It seems that whether it's illegal or not to sell depends on whether you have completed the registration procedure rather than the legality of the editor.

You don't have to re-buy it. Instead contact Protexis.

It's looking nice RMXPirate ^^ There's a little spelling mistake in what the shark says when you select the engine. Nothing happens when selecting the Improved & Special Move Command. It just displays the last script. Could it be that the selection doesn't like the & sign? The search bar doesn't work too well although I am sure you already know that ^_^ *hugs* - Zeriab

Zeriab's Caterpillar Script Version: 1.0 Introduction This script creates a caterpillar of the party members by using events present on the map. (You need to actually make the events in the editor) When the caterpillar is deactivated they act just like any other event. Most event commands still works on the events when the caterpillar is activated, but the results be strange. Screenshot Demo Currently I can only present a demo which includes Wachunga's Multiple Message Windows which requires SDK 1.5: http://www.sendspace.com/file/s5hkl7 This is because Wumpi and Despain requested it to work with that message system. (Only the caterpillar script is my work. I had nothing to do with the rest) Script http://zeriab.plesk3.freepgs.com/root/scri...pillar-v1.0.txt Instructions There are instructions in the header, but they might be hard to understand. I have tried to break down the instructions so they hopefully are easier to understand. Big and evil instructions The script uses map events with special tags in their name. The map events are tied to specific actors. If you want an event to represent the actor with id 1 in the database then somewhere in the name of the event put this: \cat_actor[1] If you want an event to represent the actor with id 19 then use this instead: \cat_actor[19] Basically you put in \cat_actor[id of actor] in the name of the event in question. Note that you need to do this for every map. Yes, a lot of work. You copy the script and paste it just above main. (I.e. you open the script editor, scroll to the bottom of the left form, click on main, press insert and paste the script into the right form) In the script pay attention to the area just below the script header: #============================================================================== class Game_Caterpillar CATERPILLAR_ACTIVE_SWITCH = 23 REMOVE_VISIBLE_ACTORS = true MAX_ACTORS = 4 #-------------------------------------------------------------------------- This is the area of script where you can customize the script. I will go through each of the lines and explain what they do: CATERPILLAR_ACTIVE_SWITCH = 23 This line will allow you to control whether the caterpillar is active or not by specifying a switch. By default you can see that we have CATERPILLAR_ACTIVE_SWITCH = 23 which means you can turn the caterpillar ON and OFF by turning switch 23 ON and OFF. Notice that switch 23 by default start on OFF and you must turn the switch ON before the caterpillar 'works'. Feel free to change the number 23 to any number you want, i.e. which switch you want. If you for example want to use switch 0169 instead it should be CATERPILLAR_ACTIVE_SWITCH = 169. REMOVE_VISIBLE_ACTORS = true This determines whether events for actors not currently in the party should be erased or not. You can set this to a number like REMOVE_VISIBLE_ACTORS = 21 if you want to specify it with a switch. In this example you can turn it ON and OFF by turning switch 21 ON and OFF. MAX_ACTORS = 4 I believe this is self-explonatory. Only change this if you can have more than 4 actors. No harm is done if you have a lower max. A little word of caution: Do not put leading 0's in front of numbers in ruby. The reason is that Ruby considers numbers with leading 0's as octadecimal. I.e. 0, 1, 2, ... , 6, 7, 10, 11, ... No 8 nor 9. So for example 15 oct = 13 and 8 oct and 9 oct gives an error. Here are two call scripts you can use if you feel the caterpillar isn't updated properly like problems with the graphic. Also highly useful should you have custom scripts and need to tell the caterpillar script has changed: (The call script is the event command on the bottom-right of page 3) This will update the caterpillar to make sure the right events and right graphics are used. $game_system.caterpillar.update This will refresh the caterpillar which pretty much 'starts on a fresh'. All the events will be placed the same place as the player. As if you were teleported. Only use this if the update don't work. $game_system.caterpillar.refresh FAQ Why did you make a caterpillar script when so many are around? Despain requested a script that worked with a particular message script and Wumpi requested a script which used map events. It didn't seem like there was such a caterpillar script out there although I admittedly didn't search hard. So I made this believing it would work differently from other caterpillars scripts. How do you get the events to act differently when they walk in the caterpillar and when they don't? Create a page which has the caterpillar activation switch as precondition. If that is the top page (the one with the highest number) then that will be the event's functionality when in the caterpillar. If you have problems with the graphic of some events not being what they are supposed to be then add a 1 frame wait and a script call: $game_system.caterpillar.update This should solve the problem. The 1 frame wait is necessary or the page change will not have been registered before the update and the result is the same. The caterpillar made me stuck Set the events of the caterpillar to Through. (Options area to the lower right) Compatibility This script will most likely not work with any other caterpillar system. Saves made with this caterpillar script cannot be used should you remove it again. (Saves without it will work with it) It should work both without and with the SDK and I believe it should with both SDK 1.x and SDK 2.x although I have only tested SDK 1.5. Credits and Thanks Credits goes to Zeriab for creating the system I would like to thank Despain and Wumpi for requesting the script. I would like to thank everyone using their time to try and use my system. I would like to thank everyone reading this topic. Thanks. Author's Notes I would be delighted if you report any bug, errors or issues you find. In fact I would be delighted if you took the time and replied even if you have nothing to report. Suggestions are more than welcome And finally: ENJOY! - Zeriab

Happy Birthday Shadow :3 Be sure to enjoy it ^^

The main problem with creating such a system is that the default design does not support it and is not easily expanded to support it. If one were to make an attempt at such a system I would suggest that you start by following the style of having a Game_Weapon for runtime changes which uses the database (RPG::Weapon) as base. You can easily have several Game_Weapons for each weapon in the database. The Game_Weapon class could for example look like this: class Game_Weapon # The attributes present in a RPG::Weapon ATTRIBUTES = ["agi_plus", "animation1_id", "animation2_id", "atk", "description", "dex_plus", "element_set", "icon_name", "int_plus", "mdef", "minus_state_set", "name", "pdef", "plus_state_set", "price", "str_plus"] #-------------------------------------------------------------------------- # * Object Initialization #-------------------------------------------------------------------------- def initialize(data_weapon) @data = data_weapon end #-------------------------------------------------------------------------- # * Generate getters and setters for the attributes #-------------------------------------------------------------------------- for attribute in ATTRIBUTES # Computes the setter and getter code for the specific attribute PROG = <<FIN attr_writer :#{attribute} def #{attribute} if @#{attribute}.nil? return @data.#{attribute} else return @#{attribute} end end FIN # Evaluates the method definitions eval(PROG) end end The class contains each of the attributes present in the RPG::Weapons. It reads from the RPG::Weapon unless another value has been written to the specific attribute, which it will return instead. This way you can have for example two Iron Swords with the same ID and different stats. You may want more information stored in the Game_Weapon. This is but an example The code won't do anything on it's own. You have to change a large area of the default scripts to employ the Game_Weapon efficiently. I have written this more for Leon than you Jesse. Don't be discouraged if you don't understand what I am talking about *hugs* - Zeriab

I am glad you like it ^^ Do tell if you have problems with it *hugs*

Updated to version 1.2. Major improvements on the topic as well Version 1.05 ------------------------------------------------- (2007-11-18) - Fixed bug where sprites might not be disposed when changing scene. Version 1.1 -------------------------------------------------- (2008-04-10) - Added declaration to which common events to update Version 1.15 ------------------------------------------------- (2008-06-19) - Added automatic detection of which common events to update (optional) Version 1.2 -------------------------------------------------- (2008-07-04) - Fixed a case where an event could be registered twice causing transparent events to look less transparent.

Neither. I did not vote because the poll forces you to pick either scripting or eventing. What's best to use depends on the specific situations you are in. Sometimes a scripted solution is preferable, at other times an evented solution is preferable and at other times still a hybrid solution evolving both scripting and evented is preferable.