[18:11] <@Twylight> I did have a question tho...
[18:11] <@Aanon> were we waiting for anyone else to join the chat?
[18:11] <@Twylight> Not really
[18:11] <@Twylight> Climax may show up
[18:11] <@Aanon> ok
[18:11] <@Twylight> But the other people voicing on this subject really is just us
[18:12] <@Twylight> anyways, my question
[18:12] <@Twylight> On the boards it seemed pretty accepted that C++ would be the language to do this in
[18:12] <@Twylight> on SourceForge tho you listed VB as the language and Other..
[18:12] <@Twylight> just wondering which one we should go with
[18:12] <@Aanon> well, I remember VB better than C++
[18:13] <@Aanon> it's been ~8 years since I've done C++ :)
[18:13] <@Twylight> Its been a while for me as well.
[18:13] <@Tanakar> My only real experience is with VB in this context
[18:13] <@Twylight> however...
[18:13] <@Aanon> since we'll be doing COM and/or DLL's we shouldn't have an issue one way or another.
[18:13] <@Aanon> (right?)
[18:13] <@Twylight> PlainText.dll already interfaces the scripting host and decal
[18:13] <@Twylight> and its written in C++
[18:14] <@Aanon> but it is .dll.
[18:14] <@Twylight> As will be what we make
[18:14] <@Twylight> All decal plugins are Dll files to my knowledge
[18:14] <@Aanon> we shouldn't have a problem accessing it from VB or C++.
[18:14] <@Aanon> Correct, Tanakar?
[18:14] <@Tanakar> I believe that is correct
[18:14] <@Twylight> Ah that, Yes I do not see that as an issue
[18:15] <@Twylight> Just that its already been done in C++ is all 8)
[18:15] <@Aanon> oh ok.
[18:15] <@Aanon> I can read C++...
[18:15] <@Aanon> but Java has clouded my thoughts on coding C++...
[18:15] <@Twylight> Ive also had a friend of mine say that C++ would be the better way to go for asyncronous and threaded execution
[18:15] <@Aanon> that is probably true.
[18:16] <@Twylight> Either way I do not care really
[18:16] <@Aanon> I guess we need to ask that question first.
[18:16] <@Twylight> I just thought we should atleast settle on a language we were making this in first is all 8)
[18:16] <@Tanakar> Yes, VB can be a pain for multithreading...but will we need that?
[18:16] <@Twylight> Thats the question
[18:16] <@Aanon> if we run in a separate thread... maybe we can get someone to code a dll in C++...
[18:16] <@Twylight> I dont see why we would.
[18:16] <@Aanon> and call out to ours.
[18:16] <@Twylight> But Climax did say it could be used in some ways
[18:18] <@Aanon> well, let's think about how/if we need to worry about threading issues... and if we do...
[18:18] <@Aanon> see if we can find someone to help wrap what we do in a thread.
[18:18] <@Twylight> I can still not really see why we would not want a synchronous setup....
[18:18] <@Twylight> Is there ever a time when you want to do B before A ?
[18:19] <@Aanon> i guess climax was referring to the flexibility of the asynch.
[18:19] <@Aanon> or running outside of the AC process.
[18:19] <@Tanakar> another plugin i am working on uses a separate thread to query info from an internet server...it pauses if it is in the game thread while making the connection
[18:19] <@Twylight> How so tho... i mean Ive not seen an example of what would use it.
[18:19] <@Tanakar> I don't know why you would need asynchronous for typical scripting though
[18:19] <@Aanon> no... me either.
[18:19] <@Aanon> just in a different thread really.
[18:20] <@Aanon> do you have VB 6?
[18:20] <@Twylight> Im still wodnering if we do not want to go to a totaly event driven system
[18:20] <@Twylight> VB6 SP5
[18:21] <@Twylight> And just include an event of a ticker to allow time keeping routines
[18:21] <@Tanakar> i have VB6...not sure what SP though
[18:21] <@Twylight> I have Visual Studio 6.0 with SP5 really, hehe
[18:21] <@Twylight> Ive only installed the C++ and VB parts of it however
[18:21] <@Aanon> how long have you been doing VB?
[18:21] <@Tanakar> same here
[18:22] <@Aanon> have you been reading up on the Decal stuff?
[18:22] <@Twylight> Ive been reading everything I can on decal
[18:22] <@Twylight> But truth be said Decal documentation isnt common place
[18:22] <@Aanon> :)
[18:22] <@Twylight> Those who know it just do for the most part
[18:22] <@Twylight> And they are all more concerend with continuing what they are working on then on writting how-tos
[18:23] <@Aanon> hence my request for other plugin developers to make their source open-source! :)
[18:23] <@Twylight> And Im not citing that as a fault, just that there isnt a palce to really go to learn, hehe
[18:23] <@Tanakar> yes...a lot of the docs out there are sketchy and you really just have to try it to figure it out.
[18:23] <@Twylight> Zycra's VB site is the best one Ive seen
[18:23] <@Aanon> y
[18:23] <@Tanakar> yep
[18:23] <@Twylight> And even that is lacking in suffecient explination for me at points
[18:23] <@Aanon> Tanakar is going to put some links, etc on sourceforge.
[18:23] <@Twylight> k
[18:23] <@Aanon> maybe you can add yours as well.
[18:24] <@Twylight> I got very few, hehe
[18:24] <@Aanon> Tanakar found the API for the AC Object! (Whew!)
[18:24] <@Tanakar> I'll try to get those up tonight
[18:24] <@Twylight> Woot!
[18:24] <@Twylight> Kewl
[18:24] <@Tanakar> I'll post that too
[18:24] <@Twylight> I will say I side with Climax that I just dont like Source Forge
[18:25] <@Twylight> But until/unless we get something else Im not against using it
[18:25] <@Twylight> Mebbe it will grow on me or something, hehe
[18:25] <@Tanakar> I haven't had much experience with it, but so far so good
[18:25] <@Aanon> =) 7+ months and loving it.
[18:25] <@Twylight> I think the layout of it in general wasnt well thought out
[18:25] <@Aanon> it has changed and grown... and needs improvements... but for what it costs, it is great!
[18:25] <@Twylight> Ah, hehe 8)
[18:26] <@Twylight> I pay $80 a year for my own web server
[18:26] <@Twylight> And so far i do nothing with it, hehe
[18:26] <@Aanon> =)
[18:26] <@Twylight> Back to the problem or debate at hand
[18:26] <@Twylight> VB vs C++
[18:26] <@Apoz> c++
[18:26] <@Apoz> !
[18:26] <@Twylight> For me I will say C/C++ has -always- been my prefered language
[18:26] <@Aanon> well, one thing about "event driven" vs. "process and then handle an event"... is that you won't interrupt a flow unless you explicitly watch for one.
[18:27] <@Twylight> But truth be said, if its not a web language Ive not used it in around 4 or 5 years except for helping people debug code parts
[18:27] <@Aanon> (2 issues under discussion)
[18:27] <@Tanakar> I prefer VB since I have no experience in C++ :o)
[18:28] <@Aanon> that is the same here. I think we can code something faster in VB... (I liked C/C++, but it's been so long)
[18:28] <@Twylight> Any experience in C or PERL or PHP ?
[18:28] <@Apoz> cibo told me one big difference between decal and acscript was that acascript can stop or pause while decal plugins cant
[18:28] <@Tanakar> yes, C, Perl, and Java
[18:28] <@Aanon> same.
[18:28] <@Aanon> no PHP.
[18:28] <@Twylight> Then C++ is not a big deal
[18:28] <@Aanon> pause vs not pause.
[18:29] <@Twylight> The languages are so similiar its stupid at points
[18:29] <@Aanon> what did he mean by not being able to pause?
[18:29] <@Twylight> Explain the pause vs not pause for me if you could
[18:29] <@Aanon> :)
[18:29] <@Apoz> I dont totally understand myself
[18:29] <@Apoz> he
[18:29] <@Twylight> Did he -just- tell you this?
[18:29] <@Apoz> you'd have to ask cibo
[18:29] <@Apoz> yesterday
[18:29] <@Twylight> as in, could he come in here and tell us 8)
[18:29] <@Apoz> he told me
[18:29] <@Twylight> Ah
[18:30] <@Apoz> ill try to get him
[18:30] <@Twylight> Well C++ runs faster then VB, that I do know
[18:30] <@Twylight> VB is also cenereted around application design, not really dll design... (from what Ive seen atleast)
[18:30] <@Aanon> it would seem that you could just code it to 'not execute'.
[18:30] *** Cibo|work (jhayes@354604a5.b36c26e4.ca.hmsk) has joined #dscript
[18:30] <@Twylight> Hello Cibo
[18:31] <@Aanon> Hello!
[18:31] <@Tanakar> hi
[18:31] <@Twylight> Apoz said you told him the big difference between AcScript and Decal (besides the obvious) was that AcScript could pause and decal could not
[18:31] <@Twylight> We were wodnering what you meant by that
[18:32] *** Climax (asdfsdgdfh@cx745509-c.alsv1.occa.home.com) has joined #DScript
[18:33] <Climax> hola
[18:33] <@Aanon> hello!
[18:33] <@Tanakar> Hi Climax
[18:33] <@Twylight> Welcome Climax
[18:33] <Climax> I can only stay for a bit, I have a meeting in 30 mins
[18:33] *** Twylight sets mode: +oo Cibo|work Climax
[18:34] *** Cibo|work (jhayes@354604a5.b36c26e4.ca.hmsk) Quit (nebula.sorcery.net nexus.sorcery.net)
[18:34] <@Twylight> Main thing weve beent alking about is C++ vs VB for development
[18:34] <@Climax> c++!!!
[18:34] <@Aanon> Cibo... didn't respond. :(
[18:34] <@Twylight> And Synchronous vs Asynchronous
[18:34] <@Twylight> Cibo got netsplit
[18:34] <@Tanakar> Sorry guys...I have to go. My parting vote is VB, but I'll work with either. Let me know how it comes out.
[18:34] *** Cibo|work (jhayes@354604a5.b36c26e4.ca.hmsk) has joined #dscript
[18:34] <@Aanon> ok...
[18:34] <@Twylight> wb
[18:34] <@Twylight> Ok Tanakar
[18:34] <@Climax> C++ is just so much for powerful.. :)
[18:34] <@Aanon> see you Tanakar.
[18:34] <@Apoz> Cibo
[18:35] <@Climax> later tanakar
[18:35] *** Tanakar (tanakar@6ca5f0d9.6ca5ecfb.206.98.imsk) has left #DScript
[18:35] <@Aanon> Unfortunately, Tanakar hasn't done C++ ...
[18:35] <@Aanon> and it's been atleast 7-8 years since I have.
[18:35] <@Climax> my opinion is that we should support both syncronous events and asyncronous events
[18:36] <@Twylight> Can you give me one time when you would want B to execute before A Climax?
[18:36] <@Climax> I've never done any VB :(
[18:36] <@Twylight> Cause truth be said Ive no idea.
[18:36] <@Aanon> =)
[18:36] <@Climax> sure, I'll give you a couple examples :)
[18:36] <@Climax> in a complex script you will want a main loop wherein you process events in turn
[18:37] <@Climax> but in "addon" scripts.. you might want to handle events out of process
[18:37] <@Twylight> ...
[18:37] <@Climax> example an answering maching script would register to recieve events, but would not have a main loop
[18:38] <@Twylight> True
[18:38] <@Twylight> But every other script I can think of creating would be the same
[18:38] <@Climax> so that script could be installed as an addon script on top of more complex scripts
[18:38] <@Twylight> Just reacting to events as they happen
[18:38] <@Climax> you're correct in thinking that anything complex would require that :)
[18:39] <@Aanon> but... that could cause problems if you are trying to react to events that change the handling on the screen.
[18:39] <@Aanon> mouse pointer clicking and moving incorrectly.
[18:39] <@Twylight> Like two events that fire and mouse movement in both?
[18:39] <@Twylight> Yeah...
[18:39] <@Aanon> yes.
[18:39] <@Climax> asyncronous (maybe I'm using that word improperly?) dispatching would purely be for non-intrusive addons
[18:40] <@Aanon> how could you limit it to non-intrusive addons?
[18:40] <@Climax> that's true aanon
[18:40] <@Climax> .. but i think that should be left to the scripter ..?
[18:40] <@Climax> or perhaps there should be an ac.CaptureInterface() method
[18:40] <@Twylight> I think an event driven setup like used with Tribes scripting might work very effectively here.
[18:40] <@Aanon> I like your thinking about allowing layering of mods/scripts.
[18:41] <@Climax> which would capture and lock the interface until a method ac.ReleaseInterface() is called
[18:41] <@Twylight> When i mentioned multiple running scripts at one time I got shot down 8)
[18:41] <Cibo|work> if you're running in the main decal thread you can only support async events
[18:41] <@Twylight> All the events come in a continous stream from decal right?
[18:41] <@Climax> cibo, decalscript could easily build a message queue
[18:41] <@Aanon> that is why ACScript held on to the events for you.
[18:41] <Cibo|work> the reason is because a plugin runs in the same thread that AC uses for everything - drawing, windows messages and network
[18:41] <@Climax> and dispatch them as requested to the script
[18:42] <Cibo|work> so when a plugin stops, AC stops
[18:42] <@Twylight> Ah, I see what you mean by stop and start now
[18:42] <@Climax> hehe, i didnt know that ;)
[18:42] <@Aanon> can you run the plugin in it's own thread?
[18:42] <@Climax> but the events could still be stored in an internal queue
[18:42] <Cibo|work> doing synchronous event measn creating another thread - ACScript was in another process enitrely, so it's implictely in another thread
[18:43] <@Aanon> you mean... asynch.
[18:43] <@Climax> cibo.. does the active script engine run in a seperate process?
[18:43] <Cibo|work> the tricky part is getting network messages to this other thread
[18:43] <@Twylight> I think we may all be considering asynch and sycn differently
[18:43] <@Climax> (in plain text ddl for example)
[18:44] <@Aanon> asynch (is not synch... which means not multi-threaded)
[18:44] <Cibo|work> decal does message cracking inplace - using the esame buffer AC uses, ACCom made a copy to send it out of process
[18:44] <@Climax> couldnt that be done internally within the plugin?
[18:45] <@Aanon> So, really ACCom is the real work horse here.
[18:45] <@Climax> like just a big linked list of event data that is unique to decal script
[18:45] <Cibo|work> the plaintext dll is what's now know as a plugin surrogate ... a surrogate is like an adpater that can make something that ins't a COM binary plugin (like a text scritp) look like a plugin
[18:46] <Cibo|work> I'm *really* lagged here
[18:46] -> [Cibo|work] PING
[18:46] [Cibo|work PING reply]: 0sec
[18:46] <@Climax> hehe, np
[18:46] <@Twylight> 0sec response to me Cibo
[18:46] <@Apoz> cibo, i think its the server
[18:46] <@Apoz> =/
[18:46] <@Twylight> Same
[18:47] <@Twylight> Ok, we have more to consider now... hehe
[18:47] <Cibo|work> you may be able to do it all in a single thread, but I'm not sure if you can 'pause' the script engine so it returns later
[18:47] <Cibo|work> the rule is, any event handler in Decal has to return, AC dosen't continue until it returns
[18:48] <Cibo|work> if you can make teh script engine run a few lines, then return - you're set
[18:48] <@Aanon> and we can't spin a thread to set off another message (on a timer) later?
[18:48] <@Aanon> that is the way Unreal Mods worked.
[18:48] <@Aanon> (mutators)
[18:49] <@Climax> btw Aanon, I just register as "Climax" on source forg
[18:49] <@Climax> btw Aanon, I just register as "Climax" on source forge
[18:49] <@Aanon> ok... i'll add you now.
[18:49] <@Twylight> I have a question for you Cibo
[18:49] <Cibo|work> something you *really* want to avoid is marshalling message data - that'll be really slow
[18:49] <@Climax> ahhh
[18:49] <Cibo|work> ok
[18:49] <@Climax> i see what you mean now
[18:50] <@Twylight> Could we take an event given to us from decal, store it, return a value to decal so it knows we got the message and continues on and then handle that event ?
[18:50] <Cibo|work> yep ... you could do that, but decal has a ton of events it can send and it's growing, makinga storage for each possible event isn't going to be easy
[18:51] <@Twylight> With my event idea I do not think that would be a problem
[18:51] <@Climax> I'm pretty sure there's a way to have the active script controll execute in a seperate process, and still maintain control of it
[18:51] <@Twylight> Would only stroe events that have functions or actions registered to it
[18:51] <Cibo|work> the way decal is changing in teh near future is everything is communicated with events
[18:51] <@Twylight> erm, Store
[18:52] <Cibo|work> there's more than just network events - there's other kinds like timers, hotkeys, web trasnfers, irc ...
[18:52] <Cibo|work> and then there's goign to be a host of higher level events - much like you described with ACScript
[18:52] <@Aanon> ok... so, if we store, we could run out of space -- same problem ACScript had... and that is why it purged if you didn't handle the events.
[18:52] <Cibo|work> Decal has had an unexploited function called Network filters that decode messages globally
[18:52] *** Losthope (ether_addi@945572b8.lndn1.on.wave.283197b4.com.hmsk) has joined #DScript
[18:53] <@Aanon> when are those higher level events planned?
[18:53] <@Twylight> Glad you made it Losthope
[18:53] <@Aanon> we really do need that higher level API.
[18:53] <@Twylight> I like having the low level API avaliable tho..
[18:53] <@Climax> well..
[18:53] <Cibo|work> they should get a lot of attention after the first few are released ... so you would do well to exploit/extend those instead of reinventing
[18:53] <@Climax> before we go too in-depth into these issues
[18:53] <@Twylight> Too many times in AcScript did i have to sit and twiddle my thumbs or go Way out of my way to do something that could have been handled by an event that they hadnt supported yet
[18:54] <Cibo|work> ya ... the echo filter won't go away, that exposes pretty much everything
[18:54] <@Climax> before we go too in-depth into these issues...
[18:54] <@Climax> =P
[18:55] <@Climax> ... we need to research whether the active script controller can be spawned in a seperate process
[18:55] <@Aanon> y.
[18:55] <@Twylight> I do not think we need to nessicarily
[18:55] <@Climax> if it can be, that would alleviate many of the issues you guys are debating
[18:55] <Cibo|work> you probably don't want a separate process ... that'll slow it down a lot and introduce synchronization problems
[18:55] <@Twylight> You got to remember that Decal sends Tons of events cause they all happen
[18:55] <@Twylight> But you also got to remember that there is no script that will ever use Every event, hehe
[18:56] <@Climax> I've all for scripts having to request events
[18:56] <@Twylight> Most of the events are things our plugin would handle and just update values in the object the script accesses to do things
[18:56] <@Climax> err
[18:56] <@Climax> I'm all for scripts having to request events
[18:56] <Cibo|work> that's something network filters are supposed to address ... they significantly reduce the number of events a user has to understand
[18:56] <@Twylight> Exactually
[18:56] <@Twylight> Our plugin handles all the complex issues, not the people and their scripts
[18:57] <@Twylight> Scripting should be easy, not as complicated as making a decal plugin
[18:57] <@Climax> but at the same time..
[18:57] <@Twylight> Otherwise what is the point
[18:57] <Cibo|work> and hopefully eliminate the code like: pMsg.Members("skills").Member(i).Member("Value") - that's ridiculously slow
[18:58] <@Climax> having scripts call a function like ac.Advise(eventID) wouldn't make scripting over complicated
[18:58] <@Climax> ooooooOOOooo
[18:58] <@Climax> I just had a great idea :)
[18:58] <@Apoz> I hope this is being logged
[18:58] <@Apoz> or written down
[18:58] <@Apoz> =)
[18:58] <@Twylight> I log everything on IRC
[18:58] <@Twylight> hehe
[18:58] <@Climax> hehe good
[18:59] <@Climax> supposing we get all the detailes worked out
[18:59] <@Climax> it would be REALLY cool to use that method I mentioned above - ac.Advise(eventID)
[18:59] <@Climax> and the advise notices would be in a stack..
[18:59] <@Twylight> I take it Advise is a trigger happening?
[18:59] <@Climax> so a script in its main loop could ac.Advise(someEvent)
[18:59] <Cibo|work> I never considered scripting to be a purely programmatic challenge
[19:00] <@Climax> and then some internal functions
[19:00] <@Climax> and at the end of the script call - ac.UnAdvise(someEvent) -- note: no parameters
[19:00] <@Climax> err
[19:00] <@Climax> and at the end of the script call - ac.UnAdvise(someEvent)
[19:01] <@Twylight> What is Advise doing Climax
[19:01] <@Twylight> is it like WaitEvent() ?
[19:01] <@Climax> but the events would be stackable, so that if an internal function UnAdvise()'ed an event, it would not effect the main loop
[19:01] <@Twylight> Cause that format sucked nutz
[19:01] <@Climax> i agree
[19:01] <@Climax> but whatever mechanism we use to dispatch events to the script
[19:02] <@Climax> would need to be "advised" of which events the script currently wants to know about
[19:02] <@Aanon> :)
[19:02] <@Twylight> Ah
[19:02] <@Twylight> Ok, we are thinking on the same lines
[19:02] <@Climax> that way we keep traffic to a minimum and reduce CPU usage
[19:02] <@Twylight> I would just use different terminology, hehe
[19:02] <Cibo|work> here's a design I wrote up about 6 months ago:
[19:02] <Cibo|work> http://www.decal.ac/AC/Decal/design_for_a_bot_script_language.htm
[19:02] <@Twylight> We only care about events that the scripts are registered for
[19:03] <@Twylight> Got any other links hiding out there? 8)
[19:04] <@Twylight> I think one thing I can say about all of us in here is we are starving for decal information, hehe
< LOST CONNECTION AND REGAINED A MIN AFTER >
[19:05] <}Syn{> mutter
[19:05] * }Syn{ pokes Twylight
[19:05] <@Aanon> i've got to go in about 10 minutes.
[19:05] <@Aanon> but could be only later tonight if needed.
[19:05] <@Climax> what I would like to do is write up an example JScript that would demonstrate the various core functionality that the script host would need to exhibit
[19:06] <}Syn{> Did I miss anything? Last I saw was Cibo's link
[19:06] <Losthope> climax you mean like what acscript had with t.js right?
[19:06] <}Syn{> Just do a pseudo code thing
[19:06] <@Climax> I don't know enough about COM and Win32 programming to be of much use in this current discussion ;)
[19:06] *** }Syn{ is now known as Twilight
[19:06] <@Climax> hehe JScript is psuedo code ;)
[19:06] <Twilight> lol
[19:06] <@Apoz> i like pseudo code
[19:06] <Losthope> i am trying to learn com now
[19:06] <Losthope> it's scary
[19:07] <@Apoz> hhe
[19:07] <Twilight> Only scary until ya know it then its just like everything else.
[19:07] <@Apoz> ill be back around 9
[19:07] <@Apoz> cya later guys
[19:07] <@Climax> losthope, nothing as complex as asc's t.js because I envision our system to be much simplerer
[19:07] <Twilight> Later Apoz
[19:07] <@Aanon> later.
[19:07] <@Climax> later apoz
[19:07] * @Climax has to go too!
[19:07] <Losthope> not sure if i would be able to help with the low level code until i get some more knowledge on com
[19:07] <@Aanon> what is t.js?
[19:07] <Twilight> I truly Know that the event type of system that every tribs scripter used for tribes would work Very well with this setup
[19:08] <Twilight> t.js was an example and reaction to every event AcScript supported
[19:08] <@Climax> twilight, code up an example of how it works :)
[19:08] <@Aanon> oh.
[19:08] <Twilight> I could tell you it in about 5min
[19:08] <Twilight> hehe
[19:08] <@Climax> I'm gonna leave IRC open.. but I'm leaving now
[19:08] <@Aanon> =)
[19:08] <@Climax> if anyone's still around later we can chat then
[19:08] <Twilight> Multi dimensional array held all event names
[19:09] *** Climax is now known as Climax|meeting
[19:09] <Twilight> When the event was triggered, get the name of it
[19:09] <@Aanon> Twilight... when the chat is done... post the logs to the sourceforge page.
[19:09] <Twilight> Find it in the array
[19:09] <Twilight> call any functions registered for it
[19:09] <@Aanon> later Climax!
[19:09] <Twilight> Ill have a gap in it Aanon
[19:09] <Twilight> I got disconnected (points at Twylight sitting over there with a smirk on his face)
[19:09] <@Aanon> =)
[19:10] <Twilight> But yes I will 8)
[19:10] <@Aanon> oh. I can if someone let's me know how to get the logs. :)
[19:10] <Twilight> Ill write up in better description an event handling process.
[19:11] <@Aanon> wait ... i'll have to go before everyone else :) so, I can't.
[19:11] *** cj (cjcollier@585f3c52.sttln1.wa.283197b4.com.hmsk) has joined #dscript
[19:11] <cj> wow, already quite a few people here
[19:11] <Twilight> Hehe, we've been discussing ideas for a few now
[19:11] *** Twylight (user@8ad22644.aburny.d75a346f.net.hmsk) Quit (Connection timed out)
[19:11] <Twilight> YEs
[19:12] *** Twilight is now known as Twylight
[19:12] <@Aanon> =)
[19:12] * Twylight registeres his nick this time so he can enforce it.
[19:12] <@Aanon> ok... back to the topic.
[19:13] <Twylight> Which one 8)
[19:13] <Twylight> Im very glad you came in to enlighten us Cibo
[19:13] <Losthope> cibo is my hero!
[19:13] <@Aanon> well, we have some open questions.
[19:13] <Twylight> Your input has given us alot to think about and consider 8)
[19:13] <Twylight> All we have ARE open questions at this point Aanon 8)
[19:13] <@Aanon> and to research.
[19:13] <@Aanon> heh yes... you are right.
[19:13] <Cibo|work> it's your project, I'll just tell you about decal :-)
[19:14] <Twylight> Hehe, Ill listen to anything you say about it 8)
[19:14] <@Aanon> ok...
[19:14] <Twylight> Ok Main Topics we have right now is C++ vs VB
[19:14] <cj> is Climax about? Didn't he start the project?
[19:14] <@Aanon> he is in a meeting.
[19:14] <Twylight> Climax is at a meeting
[19:15] <Twylight> Id like to say I started it but I dont think that matters really
[19:15] <@Aanon> run in separate thread (or in same AC thread)
[19:15] <Twylight> Going to be same thread
[19:15] <Twylight> I do not really think we want to tackle seperate thread
[19:16] <Twylight> We just have to queue event handling so it doesnt pause AC
[19:16] <@Aanon> then we must handle events as they come or it will pause what ever is going on in AC.
[19:16] <Twylight> Yup
[19:16] <Twylight> get an event and all its data, tell AC to carry on, process the data
[19:16] <@Aanon> when do you process the data?
[19:17] <@Aanon> =) when they call AC.WaitEvent() ? =)
[19:17] <Twylight> Ick Ick Ick 8)
[19:17] <@Aanon> heh
[19:17] <Twylight> As long as there is an event to handle, handle it
[19:17] <Twylight> The adding of events to the queue of them should not affect that, thus the reason for the queue.
[19:17] <@Aanon> but you said we would hold on to the event.
[19:18] <cj> are you going to build the event handler from scratch?
[19:18] <Twylight> Also please again note that there are many of the events decal will give us are not ones that we nessicarily want to pass on as a triggerable event to a script
[19:18] <Twylight> Decal gives our plugin the event
[19:19] <Twylight> We take it, and all the data associated with it and store it
[19:19] <cj> sure, just bind to the events you want to handle and ignore the rest
[19:19] <Twylight> We know that Cj
[19:19] <cj> sorry, just restating for my own good. I'll be quiet ;)
[19:19] <Twylight> We tell decal to let AC carry on
[19:19] <@Aanon> =)
[19:20] <Twylight> Damnit
[19:20] <Twylight> I will brb 8(
[19:20] <Twylight> Studio computer system is acting up and the engineer needs me to look at it
[19:20] <Twylight> give me 5min
[19:20] <@Aanon> ok... we are in 1 thread examining_pack() routine in the script, here comes an event --
[19:21] <@Aanon> we can allow the listeners to determine which events will interrupt the currently running process...
[19:22] <@Aanon> only if there are really 2 threads running, right?
[19:22] <Twylight> Im back
[19:22] <Twylight> Sorry about that
[19:22] <Twylight> Cibo said Decal was Async in function
[19:22] <@Aanon> AC's main thread and the script that we have running to effect the client machine.
[19:22] <Twylight> So we should be able to queue events as well as execute them
[19:22] <@Aanon> oh... so, it is Asynch, but you can't block an event.
[19:23] <Twylight> Unless I am misunderstanding what he said
[19:23] <@Aanon> Cibo still on?
[19:23] <@Aanon> (watching?)
[19:23] <Twylight> peoples Scripts are Sync
[19:23] <@Aanon> right.
[19:23] <Twylight> But us queuing the events and executing them could happen at one time
[19:23] <@Aanon> unless we fire events into them (ouch)
[19:24] <Twylight> If Cibo is avaliable again we should ask him if that is possible but I do think that is what he said.
[19:24] <@Aanon> we can't queue it, tell the method we are done (so return), and then call the underlying script.
[19:24] <@Aanon> that is multi-threaded.
[19:24] <Twylight> We got to make a distcintion here
[19:25] <Twylight> Our plugin can do multiple things at once
[19:25] <Twylight> Peoples scripts do Not.
[19:25] <@Aanon> can our plugin be multi-threaded?
[19:25] <Twylight> The plugin should be able to queue events and send event triggers to scripts at once
[19:26] <Twylight> Maybe I am not explaining this right..
[19:26] <Losthope> i think it would be cool to be able to have timers in your script that would send events to the queue
[19:26] <Twylight> My event design allows for both Ac triggerable events and user defined events
[19:27] <Twylight> And ofcourse there would be a Tick event for time tracking
[19:27] <Twylight> Have you seen the Empty Plugin from Zycra Aanon?
[19:28] <@Aanon> not in detail but i've seen it.
[19:28] <Losthope> alot of good info on her site
[19:28] <@Aanon> y.
[19:28] <Twylight> Let me load that web site real quick, but its from there and what cibo said that I am getting a sense that this works this way, hehe
[19:28] <Twylight> I could be wrong tho
[19:29] <Twylight> Private Sub NetEcho_EchoMessage(ByVal pMsg As DecalPlugins.IMessage
[19:29] <Twylight> When Decal sends an event to a plugin that function gets called
[19:29] <Twylight> That is not within the normal loop of the plugin
[19:29] <@Aanon> it would also be cool... if by default if the event does not get sent unless waitevent was called (same as AC) or the script developer explicitly says to allow the script to be interrupted on certain events.
[19:30] <Twylight> Thats more up to the scripter
[19:30] <Twylight> When the persons script is doing one thing they should know it should not be doing anything else until its task is done
[19:30] <Losthope> i am thinking i get what twylight is saying
[19:30] <Twylight> we have to draw the line between what our plugin does and what the scripter has to do
[19:31] <Twylight> If we just want to make a robot then we should forget this scripting nonsense and do so.
[19:31] <Twylight> But if people just want an answering machine script then fine..
[19:31] <Twylight> We have to make sure they can do everything, which means we dont want to enforce certian things.
[19:31] <Twylight> Anyhow..
[19:31] <@Aanon> right.
[19:32] <Twylight> Private Sub NetEcho_EchoMessage(ByVal pMsg As DecalPlugins.IMessage) is a function that is called whenever a event happens
[19:32] <@Aanon> our plugin will have to handle the events, que them, and allow the script to be called and processed based on what they are interested in.
[19:32] <Twylight> Its outside of the active loop of the plugin, or I should hope it is atleast.
[19:32] <Losthope> and use messages.xml to get what the event is right?
[19:32] <Twylight> No
[19:32] <Twylight> Please, just let me explain these basics first ok?
[19:32] <Twylight> So everyone sees where I am standing
[19:33] <Twylight> In a seperate loop that constantly runs we take an event from the event queue and either process it ourselves in the plugin, updating some value like health or spell buff running out or starting and the like.
[19:34] <Twylight> The seperate loop handles just one event at a time one after the other as per the queue
[19:34] <Twylight> The NetEcho_EchoMessage() that Decal calls in our plugin handles adding the events Into that queue
[19:35] <Twylight> My problem in answering your question about the plugin being multi threaded is I am not sure if that itself constitues being multi threaded
[19:36] <@Aanon> what do you mean by ... if that itself..?
[19:36] <Twylight> Does having a loop processing a queue and an outside call adding to the stack make it multi threaded
[19:37] <@Aanon> yes.
[19:37] <Twylight> We dont have our plugin say "Hey decal, what ya got next"
[19:37] <Twylight> Decal is saying "here, take this" hehe
[19:37] <@Aanon> right.
[19:37] <Twylight> My point is is that isnt something We do...
[19:37] <@Aanon> but only gives it when the event has been 'handled' (method completes)
[19:37] <Twylight> We only take the info and queue it when its given
[19:38] <@Aanon> and you need another thread to run the loop of actually processing.
[19:39] <@Aanon> right?
[19:40] <@Aanon> (still thinking about it?)
[19:40] <Twylight> Looking at the example
[19:40] <Twylight> i see no multi threads
[19:40] <Twylight> Its also not doing anything however so its not the best example 8)
[19:40] <@Aanon> =)
[19:41] <@Aanon> we can ask Cibo exactly on this point.
[19:42] <@Aanon> I think we should be able to write a thread if needed (haven't done one in C or VB).
[19:42] <@Aanon> Then we can do what you are saying.
[19:42] <Twylight> I think this is already done by default really..
[19:42] <@Aanon> that would be great!
[19:42] <Twylight> but yes, Cibo would be able to say yes or no on this point
[19:43] <Twylight> Well I do not see how many other plugins would be working unless this is how it was...
[19:43] <Twylight> take 6th sense for example
[19:43] <@Aanon> it is purely event based.
[19:43] <@Aanon> it gets a message and handles it.
[19:43] <@Aanon> arcane lore would be one to question.
[19:43] <@Aanon> i mean..
[19:44] <Twylight> Arcane Knowledge
[19:44] <@Aanon> Arcane Knowledge.
[19:44] <@Aanon> y =)
[19:44] <Twylight> And no it wouldnt, it handles no events 8)
[19:44] <Twylight> Hmm
[19:44] <@Aanon> but, you click on a button and it puts your spell together.
[19:44] <Twylight> I cant think of any plugin that isnt either no-event or event-driven
[19:44] <Twylight> yeah but that has nothing to do with events from decal
[19:44] <@Aanon> true...
[19:45] <Twylight> Just mouse movement
[19:45] <@Aanon> it might be blocking all events.
[19:45] <Twylight> Doesnt need to block em
[19:45] <@Aanon> oh...
[19:45] <@Aanon> so...
[19:45] <Twylight> Just doesnt initialise the echo filter
[19:45] <@Aanon> you are saying...
[19:45] <@Aanon> oh.
[19:46] <@Aanon> well...what I was going to say...
[19:46] <@Aanon> i clicked on the button and it started running.
[19:46] <@Aanon> if we did listen for the event,
[19:46] <Twylight> Yes it does do that
[19:46] <@Aanon> not sure how or what it would do.
[19:46] <Twylight> But that isnt an AC event, tahts an event the plugin generates when you click the button
[19:47] <@Aanon> so we need to find out if the plugin can run and if events can still be sent to the plugin at the same time.
[19:48] <@Aanon> Ok... you find out from Cibo... and let us know.
[19:48] <Twylight> K
[19:48] <@Aanon> I've got to run.
[19:48] <@Aanon> You might need to add Climax to the sourceforge project.
[19:48] <Twylight> Do you want me to cut and paste this log in a forum or to upload it
[19:48] <Twylight> If its upload you have to tell me how to 8)
[19:48] <@Aanon> when i tried to add Climax, it gave an error.
[19:49] <Twylight> His userid is just 'climax' ?
[19:49] <@Aanon> yes.
[19:49] <@Aanon> but, something isn't right.
[19:49] <Twylight> Did he activate his account yet?
[19:49] <@Aanon> said he did.
[19:49] <@Aanon> but it gave me an error... you might have to work with him on it.
[19:49] <Twylight> k
[19:50] <@Aanon> 2 easy ways to add the chat log... through the docs link or just paste it into a message in the forum.
[19:50] <@Aanon> you decide.
[19:50] <@Aanon> if in forum...
[19:50] <@Aanon> we can make more comments below.
[19:50] <Twylight> Ill do forum then
[19:50] <@Aanon> but we can always refer to the doc from the forum. =)
[19:51] <Twylight> You get an ERROR - No Error message from adding him?
[19:51] <Twylight> Ill do both
[19:51] <Twylight> hehe
[19:51] <Losthope> could you add my account to that sourceforge site?
[19:51] <@Aanon> sure...
[19:51] <@Aanon> what is it?
[19:51] <Losthope> losthope
[19:51] <Twylight> Ddint see that comming 8)
[19:51] <@Aanon> ok... you are in.
[19:52] <@Aanon> i think climax registered incorrectly or didn't finish.
[19:52] <Twylight> Same
[19:52] <Twylight> Ill catch him later
[19:52] <@Aanon> losthope...
[19:52] <@Aanon> what role do you want?
[19:52] <@Aanon> is there anyone else (cj)?
[19:52] -> *Cibo|work* If you could drop me a message when your back I have a question to ask you. thanks.
[19:53] <cj> me? oh, I'm a linux guy. I don't have a windows dev system, sorry
[19:53] <@Aanon> oh
[19:53] <Twylight> Truth be said Losthope was the first one to offer to help with making this whole thing
[19:53] <cj> I'm interested if I can help from my position in linux
[19:53] <Twylight> Then climax showed up wanting to do so and then you and tanarak
[19:53] <Twylight> And I hope I didnt just murder his name, hehe 8)
[19:53] <Twylight> Can ya op me Aanon?
[19:54] <@Aanon> op?
[19:54] <Losthope> not sure what role would be best for me
[19:54] <Twylight> Type //mode # +o Twylight
[19:54] <@Aanon> well, I added you as a 'all-hands on person' like the rest of us.
[19:54] <Losthope> cool
[19:55] <@Aanon> and as a full proj admin.
[19:55] <Losthope> works for me thanks
[19:55] <Twylight> We can figure out exact duties once we get them 8
[19:55] <Twylight> 8)
[19:55] <Losthope> sorry about not talking reading in other windows
[19:55] <Twylight> Right now all we got is a desire to make this and alot of questions on its design so for now thats what were all doing
[19:55] *** Aanon sets mode: +o Twylight
[19:55] <@Aanon> there you go.
[19:55] <@Twylight> Thanks man
[19:56] <@Twylight> Ill register this channel for us
[19:56] <@Aanon> ok.
[19:56] <@Aanon> we can write the outstanding questions on sourceforge also... and answer them as we can.
[19:56] <@Aanon> (possibly getting some questions answered from the Decal guys)
[19:57] <@Twylight> What Id like is every document out there for decal, hehe
[19:57] <@Twylight> No matter how inane it may seem
[19:57] <@Aanon> yep.
[19:57] <Losthope> hard to find good documents
[19:57] <@Aanon> well... Tanakar has started the process...
[19:57] <@Aanon> we'll get them all.
[19:58] <Losthope> best i have found is zyrcas and the messages.xml protocal doc
[19:58] <@Aanon> later!
[19:58] <@Twylight> LAter Aanon 8)
[19:58] <@Aanon> hey...
[19:58] <@Aanon> before I run...
[19:58] <@Twylight> The best info Ive ever had was from the xml protocol file
[19:58] <Losthope> zyrca does have some good info
[19:58] <Losthope> explains alot of the coding
[19:58] <@Aanon> we can set up a email list on sourceforge so that we can broadcast future meeting times on IRC, etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Addon
[20:12] <@Twylight> Can we run a continous loop to process a queue and still have NetEcho update that queue or would this require us making the plugin multi threaded?
[20:13] <Cibo_Matto> a plugin can't run in a loop since it has to return to AC, if you made a loop it would have to be on another thread
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
[18:11] <@Twylight> I did have a question tho...
[18:11] <@Aanon> were we waiting for anyone else to join the chat?
[18:11] <@Twylight> Not really
[18:11] <@Twylight> Climax may show up
[18:11] <@Aanon> ok
[18:11] <@Twylight> But the other people voicing on this subject really is just us
[18:12] <@Twylight> anyways, my question
[18:12] <@Twylight> On the boards it seemed pretty accepted that C++ would be the language to do this in
[18:12] <@Twylight> on SourceForge tho you listed VB as the language and Other..
[18:12] <@Twylight> just wondering which one we should go with
[18:12] <@Aanon> well, I remember VB better than C++
[18:13] <@Aanon> it's been ~8 years since I've done C++ :)
[18:13] <@Twylight> Its been a while for me as well.
[18:13] <@Tanakar> My only real experience is with VB in this context
[18:13] <@Twylight> however...
[18:13] <@Aanon> since we'll be doing COM and/or DLL's we shouldn't have an issue one way or another.
[18:13] <@Aanon> (right?)
[18:13] <@Twylight> PlainText.dll already interfaces the scripting host and decal
[18:13] <@Twylight> and its written in C++
[18:14] <@Aanon> but it is .dll.
[18:14] <@Twylight> As will be what we make
[18:14] <@Twylight> All decal plugins are Dll files to my knowledge
[18:14] <@Aanon> we shouldn't have a problem accessing it from VB or C++.
[18:14] <@Aanon> Correct, Tanakar?
[18:14] <@Tanakar> I believe that is correct
[18:14] <@Twylight> Ah that, Yes I do not see that as an issue
[18:15] <@Twylight> Just that its already been done in C++ is all 8)
[18:15] <@Aanon> oh ok.
[18:15] <@Aanon> I can read C++...
[18:15] <@Aanon> but Java has clouded my thoughts on coding C++...
[18:15] <@Twylight> Ive also had a friend of mine say that C++ would be the better way to go for asyncronous and threaded execution
[18:15] <@Aanon> that is probably true.
[18:16] <@Twylight> Either way I do not care really
[18:16] <@Aanon> I guess we need to ask that question first.
[18:16] <@Twylight> I just thought we should atleast settle on a language we were making this in first is all 8)
[18:16] <@Tanakar> Yes, VB can be a pain for multithreading...but will we need that?
[18:16] <@Twylight> Thats the question
[18:16] <@Aanon> if we run in a separate thread... maybe we can get someone to code a dll in C++...
[18:16] <@Twylight> I dont see why we would.
[18:16] <@Aanon> and call out to ours.
[18:16] <@Twylight> But Climax did say it could be used in some ways
[18:18] <@Aanon> well, let's think about how/if we need to worry about threading issues... and if we do...
[18:18] <@Aanon> see if we can find someone to help wrap what we do in a thread.
[18:18] <@Twylight> I can still not really see why we would not want a synchronous setup....
[18:18] <@Twylight> Is there ever a time when you want to do B before A ?
[18:19] <@Aanon> i guess climax was referring to the flexibility of the asynch.
[18:19] <@Aanon> or running outside of the AC process.
[18:19] <@Tanakar> another plugin i am working on uses a separate thread to query info from an internet server...it pauses if it is in the game thread while making the connection
[18:19] <@Twylight> How so tho... i mean Ive not seen an example of what would use it.
[18:19] <@Tanakar> I don't know why you would need asynchronous for typical scripting though
[18:19] <@Aanon> no... me either.
[18:19] <@Aanon> just in a different thread really.
[18:20] <@Aanon> do you have VB 6?
[18:20] <@Twylight> Im still wodnering if we do not want to go to a totaly event driven system
[18:20] <@Twylight> VB6 SP5
[18:21] <@Twylight> And just include an event of a ticker to allow time keeping routines
[18:21] <@Tanakar> i have VB6...not sure what SP though
[18:21] <@Twylight> I have Visual Studio 6.0 with SP5 really, hehe
[18:21] <@Twylight> Ive only installed the C++ and VB parts of it however
[18:21] <@Aanon> how long have you been doing VB?
[18:21] <@Tanakar> same here
[18:22] <@Aanon> have you been reading up on the Decal stuff?
[18:22] <@Twylight> Ive been reading everything I can on decal
[18:22] <@Twylight> But truth be said Decal documentation isnt common place
[18:22] <@Aanon> :)
[18:22] <@Twylight> Those who know it just do for the most part
[18:22] <@Twylight> And they are all more concerend with continuing what they are working on then on writting how-tos
[18:23] <@Aanon> hence my request for other plugin developers to make their source open-source! :)
[18:23] <@Twylight> And Im not citing that as a fault, just that there isnt a palce to really go to learn, hehe
[18:23] <@Tanakar> yes...a lot of the docs out there are sketchy and you really just have to try it to figure it out.
[18:23] <@Twylight> Zycra's VB site is the best one Ive seen
[18:23] <@Aanon> y
[18:23] <@Tanakar> yep
[18:23] <@Twylight> And even that is lacking in suffecient explination for me at points
[18:23] <@Aanon> Tanakar is going to put some links, etc on sourceforge.
[18:23] <@Twylight> k
[18:23] <@Aanon> maybe you can add yours as well.
[18:24] <@Twylight> I got very few, hehe
[18:24] <@Aanon> Tanakar found the API for the AC Object! (Whew!)
[18:24] <@Tanakar> I'll try to get those up tonight
[18:24] <@Twylight> Woot!
[18:24] <@Twylight> Kewl
[18:24] <@Tanakar> I'll post that too
[18:24] <@Twylight> I will say I side with Climax that I just dont like Source Forge
[18:25] <@Twylight> But until/unless we get something else Im not against using it
[18:25] <@Twylight> Mebbe it will grow on me or something, hehe
[18:25] <@Tanakar> I haven't had much experience with it, but so far so good
[18:25] <@Aanon> =) 7+ months and loving it.
[18:25] <@Twylight> I think the layout of it in general wasnt well thought out
[18:25] <@Aanon> it has changed and grown... and needs improvements... but for what it costs, it is great!
[18:25] <@Twylight> Ah, hehe 8)
[18:26] <@Twylight> I pay $80 a year for my own web server
[18:26] <@Twylight> And so far i do nothing with it, hehe
[18:26] <@Aanon> =)
[18:26] <@Twylight> Back to the problem or debate at hand
[18:26] <@Twylight> VB vs C++
[18:26] <@Apoz> c++
[18:26] <@Apoz> !
[18:26] <@Twylight> For me I will say C/C++ has -always- been my prefered language
[18:26] <@Aanon> well, one thing about "event driven" vs. "process and then handle an event"... is that you won't interrupt a flow unless you explicitly watch for one.
[18:27] <@Twylight> But truth be said, if its not a web language Ive not used it in around 4 or 5 years except for helping people debug code parts
[18:27] <@Aanon> (2 issues under discussion)
[18:27] <@Tanakar> I prefer VB since I have no experience in C++ :o)
[18:28] <@Aanon> that is the same here. I think we can code something faster in VB... (I liked C/C++, but it's been so long)
[18:28] <@Twylight> Any experience in C or PERL or PHP ?
[18:28] <@Apoz> cibo told me one big difference between decal and acscript was that acascript can stop or pause while decal plugins cant
[18:28] <@Tanakar> yes, C, Perl, and Java
[18:28] <@Aanon> same.
[18:28] <@Aanon> no PHP.
[18:28] <@Twylight> Then C++ is not a big deal
[18:28] <@Aanon> pause vs not pause.
[18:29] <@Twylight> The languages are so similiar its stupid at points
[18:29] <@Aanon> what did he mean by not being able to pause?
[18:29] <@Twylight> Explain the pause vs not pause for me if you could
[18:29] <@Aanon> :)
[18:29] <@Apoz> I dont totally understand myself
[18:29] <@Apoz> he
[18:29] <@Twylight> Did he -just- tell you this?
[18:29] <@Apoz> you'd have to ask cibo
[18:29] <@Apoz> yesterday
[18:29] <@Twylight> as in, could he come in here and tell us 8)
[18:29] <@Apoz> he told me
[18:29] <@Twylight> Ah
[18:30] <@Apoz> ill try to get him
[18:30] <@Twylight> Well C++ runs faster then VB, that I do know
[18:30] <@Twylight> VB is also cenereted around application design, not really dll design... (from what Ive seen atleast)
[18:30] <@Aanon> it would seem that you could just code it to 'not execute'.
[18:30] *** Cibo|work (jhayes@354604a5.b36c26e4.ca.hmsk) has joined #dscript
[18:30] <@Twylight> Hello Cibo
[18:31] <@Aanon> Hello!
[18:31] <@Tanakar> hi
[18:31] <@Twylight> Apoz said you told him the big difference between AcScript and Decal (besides the obvious) was that AcScript could pause and decal could not
[18:31] <@Twylight> We were wodnering what you meant by that
[18:32] *** Climax (asdfsdgdfh@cx745509-c.alsv1.occa.home.com) has joined #DScript
[18:33] <Climax> hola
[18:33] <@Aanon> hello!
[18:33] <@Tanakar> Hi Climax
[18:33] <@Twylight> Welcome Climax
[18:33] <Climax> I can only stay for a bit, I have a meeting in 30 mins
[18:33] *** Twylight sets mode: +oo Cibo|work Climax
[18:34] *** Cibo|work (jhayes@354604a5.b36c26e4.ca.hmsk) Quit (nebula.sorcery.net nexus.sorcery.net)
[18:34] <@Twylight> Main thing weve beent alking about is C++ vs VB for development
[18:34] <@Climax> c++!!!
[18:34] <@Aanon> Cibo... didn't respond. :(
[18:34] <@Twylight> And Synchronous vs Asynchronous
[18:34] <@Twylight> Cibo got netsplit
[18:34] <@Tanakar> Sorry guys...I have to go. My parting vote is VB, but I'll work with either. Let me know how it comes out.
[18:34] *** Cibo|work (jhayes@354604a5.b36c26e4.ca.hmsk) has joined #dscript
[18:34] <@Aanon> ok...
[18:34] <@Twylight> wb
[18:34] <@Twylight> Ok Tanakar
[18:34] <@Climax> C++ is just so much for powerful.. :)
[18:34] <@Aanon> see you Tanakar.
[18:34] <@Apoz> Cibo
[18:35] <@Climax> later tanakar
[18:35] *** Tanakar (tanakar@6ca5f0d9.6ca5ecfb.206.98.imsk) has left #DScript
[18:35] <@Aanon> Unfortunately, Tanakar hasn't done C++ ...
[18:35] <@Aanon> and it's been atleast 7-8 years since I have.
[18:35] <@Climax> my opinion is that we should support both syncronous events and asyncronous events
[18:36] <@Twylight> Can you give me one time when you would want B to execute before A Climax?
[18:36] <@Climax> I've never done any VB :(
[18:36] <@Twylight> Cause truth be said Ive no idea.
[18:36] <@Aanon> =)
[18:36] <@Climax> sure, I'll give you a couple examples :)
[18:36] <@Climax> in a complex script you will want a main loop wherein you process events in turn
[18:37] <@Climax> but in "addon" scripts.. you might want to handle events out of process
[18:37] <@Twylight> ...
[18:37] <@Climax> example an answering maching script would register to recieve events, but would not have a main loop
[18:38] <@Twylight> True
[18:38] <@Twylight> But every other script I can think of creating would be the same
[18:38] <@Climax> so that script could be installed as an addon script on top of more complex scripts
[18:38] <@Twylight> Just reacting to events as they happen
[18:38] <@Climax> you're correct in thinking that anything complex would require that :)
[18:39] <@Aanon> but... that could cause problems if you are trying to react to events that change the handling on the screen.
[18:39] <@Aanon> mouse pointer clicking and moving incorrectly.
[18:39] <@Twylight> Like two events that fire and mouse movement in both?
[18:39] <@Twylight> Yeah...
[18:39] <@Aanon> yes.
[18:39] <@Climax> asyncronous (maybe I'm using that word improperly?) dispatching would purely be for non-intrusive addons
[18:40] <@Aanon> how could you limit it to non-intrusive addons?
[18:40] <@Climax> that's true aanon
[18:40] <@Climax> .. but i think that should be left to the scripter ..?
[18:40] <@Climax> or perhaps there should be an ac.CaptureInterface() method
[18:40] <@Twylight> I think an event driven setup like used with Tribes scripting might work very effectively here.
[18:40] <@Aanon> I like your thinking about allowing layering of mods/scripts.
[18:41] <@Climax> which would capture and lock the interface until a method ac.ReleaseInterface() is called
[18:41] <@Twylight> When i mentioned multiple running scripts at one time I got shot down 8)
[18:41] <Cibo|work> if you're running in the main decal thread you can only support async events
[18:41] <@Twylight> All the events come in a continous stream from decal right?
[18:41] <@Climax> cibo, decalscript could easily build a message queue
[18:41] <@Aanon> that is why ACScript held on to the events for you.
[18:41] <Cibo|work> the reason is because a plugin runs in the same thread that AC uses for everything - drawing, windows messages and network
[18:41] <@Climax> and dispatch them as requested to the script
[18:42] <Cibo|work> so when a plugin stops, AC stops
[18:42] <@Twylight> Ah, I see what you mean by stop and start now
[18:42] <@Climax> hehe, i didnt know that ;)
[18:42] <@Aanon> can you run the plugin in it's own thread?
[18:42] <@Climax> but the events could still be stored in an internal queue
[18:42] <Cibo|work> doing synchronous event measn creating another thread - ACScript was in another process enitrely, so it's implictely in another thread
[18:43] <@Aanon> you mean... asynch.
[18:43] <@Climax> cibo.. does the active script engine run in a seperate process?
[18:43] <Cibo|work> the tricky part is getting network messages to this other thread
[18:43] <@Twylight> I think we may all be considering asynch and sycn differently
[18:43] <@Climax> (in plain text ddl for example)
[18:44] <@Aanon> asynch (is not synch... which means not multi-threaded)
[18:44] <Cibo|work> decal does message cracking inplace - using the esame buffer AC uses, ACCom made a copy to send it out of process
[18:44] <@Climax> couldnt that be done internally within the plugin?
[18:45] <@Aanon> So, really ACCom is the real work horse here.
[18:45] <@Climax> like just a big linked list of event data that is unique to decal script
[18:45] <Cibo|work> the plaintext dll is what's now know as a plugin surrogate ... a surrogate is like an adpater that can make something that ins't a COM binary plugin (like a text scritp) look like a plugin
[18:46] <Cibo|work> I'm *really* lagged here
[18:46] -> [Cibo|work] PING
[18:46] [Cibo|work PING reply]: 0sec
[18:46] <@Climax> hehe, np
[18:46] <@Twylight> 0sec response to me Cibo
[18:46] <@Apoz> cibo, i think its the server
[18:46] <@Apoz> =/
[18:46] <@Twylight> Same
[18:47] <@Twylight> Ok, we have more to consider now... hehe
[18:47] <Cibo|work> you may be able to do it all in a single thread, but I'm not sure if you can 'pause' the script engine so it returns later
[18:47] <Cibo|work> the rule is, any event handler in Decal has to return, AC dosen't continue until it returns
[18:48] <Cibo|work> if you can make teh script engine run a few lines, then return - you're set
[18:48] <@Aanon> and we can't spin a thread to set off another message (on a timer) later?
[18:48] <@Aanon> that is the way Unreal Mods worked.
[18:48] <@Aanon> (mutators)
[18:49] <@Climax> btw Aanon, I just register as "Climax" on source forg
[18:49] <@Climax> btw Aanon, I just register as "Climax" on source forge
[18:49] <@Aanon> ok... i'll add you now.
[18:49] <@Twylight> I have a question for you Cibo
[18:49] <Cibo|work> something you *really* want to avoid is marshalling message data - that'll be really slow
[18:49] <@Climax> ahhh
[18:49] <Cibo|work> ok
[18:49] <@Climax> i see what you mean now
[18:50] <@Twylight> Could we take an event given to us from decal, store it, return a value to decal so it knows we got the message and continues on and then handle that event ?
[18:50] <Cibo|work> yep ... you could do that, but decal has a ton of events it can send and it's growing, makinga storage for each possible event isn't going to be easy
[18:51] <@Twylight> With my event idea I do not think that would be a problem
[18:51] <@Climax> I'm pretty sure there's a way to have the active script controll execute in a seperate process, and still maintain control of it
[18:51] <@Twylight> Would only stroe events that have functions or actions registered to it
[18:51] <Cibo|work> the way decal is changing in teh near future is everything is communicated with events
[18:51] <@Twylight> erm, Store
[18:52] <Cibo|work> there's more than just network events - there's other kinds like timers, hotkeys, web trasnfers, irc ...
[18:52] <Cibo|work> and then there's goign to be a host of higher level events - much like you described with ACScript
[18:52] <@Aanon> ok... so, if we store, we could run out of space -- same problem ACScript had... and that is why it purged if you didn't handle the events.
[18:52] <Cibo|work> Decal has had an unexploited function called Network filters that decode messages globally
[18:52] *** Losthope (ether_addi@945572b8.lndn1.on.wave.283197b4.com.hmsk) has joined #DScript
[18:53] <@Aanon> when are those higher level events planned?
[18:53] <@Twylight> Glad you made it Losthope
[18:53] <@Aanon> we really do need that higher level API.
[18:53] <@Twylight> I like having the low level API avaliable tho..
[18:53] <@Climax> well..
[18:53] <Cibo|work> they should get a lot of attention after the first few are released ... so you would do well to exploit/extend those instead of reinventing
[18:53] <@Climax> before we go too in-depth into these issues
[18:53] <@Twylight> Too many times in AcScript did i have to sit and twiddle my thumbs or go Way out of my way to do something that could have been handled by an event that they hadnt supported yet
[18:54] <Cibo|work> ya ... the echo filter won't go away, that exposes pretty much everything
[18:54] <@Climax> before we go too in-depth into these issues...
[18:54] <@Climax> =P
[18:55] <@Climax> ... we need to research whether the active script controller can be spawned in a seperate process
[18:55] <@Aanon> y.
[18:55] <@Twylight> I do not think we need to nessicarily
[18:55] <@Climax> if it can be, that would alleviate many of the issues you guys are debating
[18:55] <Cibo|work> you probably don't want a separate process ... that'll slow it down a lot and introduce synchronization problems
[18:55] <@Twylight> You got to remember that Decal sends Tons of events cause they all happen
[18:55] <@Twylight> But you also got to remember that there is no script that will ever use Every event, hehe
[18:56] <@Climax> I've all for scripts having to request events
[18:56] <@Twylight> Most of the events are things our plugin would handle and just update values in the object the script accesses to do things
[18:56] <@Climax> err
[18:56] <@Climax> I'm all for scripts having to request events
[18:56] <Cibo|work> that's something network filters are supposed to address ... they significantly reduce the number of events a user has to understand
[18:56] <@Twylight> Exactually
[18:56] <@Twylight> Our plugin handles all the complex issues, not the people and their scripts
[18:57] <@Twylight> Scripting should be easy, not as complicated as making a decal plugin
[18:57] <@Climax> but at the same time..
[18:57] <@Twylight> Otherwise what is the point
[18:57] <Cibo|work> and hopefully eliminate the code like: pMsg.Members("skills").Member(i).Member("Value") - that's ridiculously slow
[18:58] <@Climax> having scripts call a function like ac.Advise(eventID) wouldn't make scripting over complicated
[18:58] <@Climax> ooooooOOOooo
[18:58] <@Climax> I just had a great idea :)
[18:58] <@Apoz> I hope this is being logged
[18:58] <@Apoz> or written down
[18:58] <@Apoz> =)
[18:58] <@Twylight> I log everything on IRC
[18:58] <@Twylight> hehe
[18:58] <@Climax> hehe good
[18:59] <@Climax> supposing we get all the detailes worked out
[18:59] <@Climax> it would be REALLY cool to use that method I mentioned above - ac.Advise(eventID)
[18:59] <@Climax> and the advise notices would be in a stack..
[18:59] <@Twylight> I take it Advise is a trigger happening?
[18:59] <@Climax> so a script in its main loop could ac.Advise(someEvent)
[18:59] <Cibo|work> I never considered scripting to be a purely programmatic challenge
[19:00] <@Climax> and then some internal functions
[19:00] <@Climax> and at the end of the script call - ac.UnAdvise(someEvent) -- note: no parameters
[19:00] <@Climax> err
[19:00] <@Climax> and at the end of the script call - ac.UnAdvise(someEvent)
[19:01] <@Twylight> What is Advise doing Climax
[19:01] <@Twylight> is it like WaitEvent() ?
[19:01] <@Climax> but the events would be stackable, so that if an internal function UnAdvise()'ed an event, it would not effect the main loop
[19:01] <@Twylight> Cause that format sucked nutz
[19:01] <@Climax> i agree
[19:01] <@Climax> but whatever mechanism we use to dispatch events to the script
[19:02] <@Climax> would need to be "advised" of which events the script currently wants to know about
[19:02] <@Aanon> :)
[19:02] <@Twylight> Ah
[19:02] <@Twylight> Ok, we are thinking on the same lines
[19:02] <@Climax> that way we keep traffic to a minimum and reduce CPU usage
[19:02] <@Twylight> I would just use different terminology, hehe
[19:02] <Cibo|work> here's a design I wrote up about 6 months ago:
[19:02] <Cibo|work> http://www.decal.ac/AC/Decal/design_for_a_bot_script_language.htm
[19:02] <@Twylight> We only care about events that the scripts are registered for
[19:03] <@Twylight> Got any other links hiding out there? 8)
[19:04] <@Twylight> I think one thing I can say about all of us in here is we are starving for decal information, hehe
< LOST CONNECTION AND REGAINED A MIN AFTER >
[19:05] <}Syn{> mutter
[19:05] * }Syn{ pokes Twylight
[19:05] <@Aanon> i've got to go in about 10 minutes.
[19:05] <@Aanon> but could be only later tonight if needed.
[19:05] <@Climax> what I would like to do is write up an example JScript that would demonstrate the various core functionality that the script host would need to exhibit
[19:06] <}Syn{> Did I miss anything? Last I saw was Cibo's link
[19:06] <Losthope> climax you mean like what acscript had with t.js right?
[19:06] <}Syn{> Just do a pseudo code thing
[19:06] <@Climax> I don't know enough about COM and Win32 programming to be of much use in this current discussion ;)
[19:06] *** }Syn{ is now known as Twilight
[19:06] <@Climax> hehe JScript is psuedo code ;)
[19:06] <Twilight> lol
[19:06] <@Apoz> i like pseudo code
[19:06] <Losthope> i am trying to learn com now
[19:06] <Losthope> it's scary
[19:07] <@Apoz> hhe
[19:07] <Twilight> Only scary until ya know it then its just like everything else.
[19:07] <@Apoz> ill be back around 9
[19:07] <@Apoz> cya later guys
[19:07] <@Climax> losthope, nothing as complex as asc's t.js because I envision our system to be much simplerer
[19:07] <Twilight> Later Apoz
[19:07] <@Aanon> later.
[19:07] <@Climax> later apoz
[19:07] * @Climax has to go too!
[19:07] <Losthope> not sure if i would be able to help with the low level code until i get some more knowledge on com
[19:07] <@Aanon> what is t.js?
[19:07] <Twilight> I truly Know that the event type of system that every tribs scripter used for tribes would work Very well with this setup
[19:08] <Twilight> t.js was an example and reaction to every event AcScript supported
[19:08] <@Climax> twilight, code up an example of how it works :)
[19:08] <@Aanon> oh.
[19:08] <Twilight> I could tell you it in about 5min
[19:08] <Twilight> hehe
[19:08] <@Climax> I'm gonna leave IRC open.. but I'm leaving now
[19:08] <@Aanon> =)
[19:08] <@Climax> if anyone's still around later we can chat then
[19:08] <Twilight> Multi dimensional array held all event names
[19:09] *** Climax is now known as Climax|meeting
[19:09] <Twilight> When the event was triggered, get the name of it
[19:09] <@Aanon> Twilight... when the chat is done... post the logs to the sourceforge page.
[19:09] <Twilight> Find it in the array
[19:09] <Twilight> call any functions registered for it
[19:09] <@Aanon> later Climax!
[19:09] <Twilight> Ill have a gap in it Aanon
[19:09] <Twilight> I got disconnected (points at Twylight sitting over there with a smirk on his face)
[19:09] <@Aanon> =)
[19:10] <Twilight> But yes I will 8)
[19:10] <@Aanon> oh. I can if someone let's me know how to get the logs. :)
[19:10] <Twilight> Ill write up in better description an event handling process.
[19:11] <@Aanon> wait ... i'll have to go before everyone else :) so, I can't.
[19:11] *** cj (cjcollier@585f3c52.sttln1.wa.283197b4.com.hmsk) has joined #dscript
[19:11] <cj> wow, already quite a few people here
[19:11] <Twilight> Hehe, we've been discussing ideas for a few now
[19:11] *** Twylight (user@8ad22644.aburny.d75a346f.net.hmsk) Quit (Connection timed out)
[19:11] <Twilight> YEs
[19:12] *** Twilight is now known as Twylight
[19:12] <@Aanon> =)
[19:12] * Twylight registeres his nick this time so he can enforce it.
[19:12] <@Aanon> ok... back to the topic.
[19:13] <Twylight> Which one 8)
[19:13] <Twylight> Im very glad you came in to enlighten us Cibo
[19:13] <Losthope> cibo is my hero!
[19:13] <@Aanon> well, we have some open questions.
[19:13] <Twylight> Your input has given us alot to think about and consider 8)
[19:13] <Twylight> All we have ARE open questions at this point Aanon 8)
[19:13] <@Aanon> and to research.
[19:13] <@Aanon> heh yes... you are right.
[19:13] <Cibo|work> it's your project, I'll just tell you about decal :-)
[19:14] <Twylight> Hehe, Ill listen to anything you say about it 8)
[19:14] <@Aanon> ok...
[19:14] <Twylight> Ok Main Topics we have right now is C++ vs VB
[19:14] <cj> is Climax about? Didn't he start the project?
[19:14] <@Aanon> he is in a meeting.
[19:14] <Twylight> Climax is at a meeting
[19:15] <Twylight> Id like to say I started it but I dont think that matters really
[19:15] <@Aanon> run in separate thread (or in same AC thread)
[19:15] <Twylight> Going to be same thread
[19:15] <Twylight> I do not really think we want to tackle seperate thread
[19:16] <Twylight> We just have to queue event handling so it doesnt pause AC
[19:16] <@Aanon> then we must handle events as they come or it will pause what ever is going on in AC.
[19:16] <Twylight> Yup
[19:16] <Twylight> get an event and all its data, tell AC to carry on, process the data
[19:16] <@Aanon> when do you process the data?
[19:17] <@Aanon> =) when they call AC.WaitEvent() ? =)
[19:17] <Twylight> Ick Ick Ick 8)
[19:17] <@Aanon> heh
[19:17] <Twylight> As long as there is an event to handle, handle it
[19:17] <Twylight> The adding of events to the queue of them should not affect that, thus the reason for the queue.
[19:17] <@Aanon> but you said we would hold on to the event.
[19:18] <cj> are you going to build the event handler from scratch?
[19:18] <Twylight> Also please again note that there are many of the events decal will give us are not ones that we nessicarily want to pass on as a triggerable event to a script
[19:18] <Twylight> Decal gives our plugin the event
[19:19] <Twylight> We take it, and all the data associated with it and store it
[19:19] <cj> sure, just bind to the events you want to handle and ignore the rest
[19:19] <Twylight> We know that Cj
[19:19] <cj> sorry, just restating for my own good. I'll be quiet ;)
[19:19] <Twylight> We tell decal to let AC carry on
[19:19] <@Aanon> =)
[19:20] <Twylight> Damnit
[19:20] <Twylight> I will brb 8(
[19:20] <Twylight> Studio computer system is acting up and the engineer needs me to look at it
[19:20] <Twylight> give me 5min
[19:20] <@Aanon> ok... we are in 1 thread examining_pack() routine in the script, here comes an event --
[19:21] <@Aanon> we can allow the listeners to determine which events will interrupt the currently running process...
[19:22] <@Aanon> only if there are really 2 threads running, right?
[19:22] <Twylight> Im back
[19:22] <Twylight> Sorry about that
[19:22] <Twylight> Cibo said Decal was Async in function
[19:22] <@Aanon> AC's main thread and the script that we have running to effect the client machine.
[19:22] <Twylight> So we should be able to queue events as well as execute them
[19:22] <@Aanon> oh... so, it is Asynch, but you can't block an event.
[19:23] <Twylight> Unless I am misunderstanding what he said
[19:23] <@Aanon> Cibo still on?
[19:23] <@Aanon> (watching?)
[19:23] <Twylight> peoples Scripts are Sync
[19:23] <@Aanon> right.
[19:23] <Twylight> But us queuing the events and executing them could happen at one time
[19:23] <@Aanon> unless we fire events into them (ouch)
[19:24] <Twylight> If Cibo is avaliable again we should ask him if that is possible but I do think that is what he said.
[19:24] <@Aanon> we can't queue it, tell the method we are done (so return), and then call the underlying script.
[19:24] <@Aanon> that is multi-threaded.
[19:24] <Twylight> We got to make a distcintion here
[19:25] <Twylight> Our plugin can do multiple things at once
[19:25] <Twylight> Peoples scripts do Not.
[19:25] <@Aanon> can our plugin be multi-threaded?
[19:25] <Twylight> The plugin should be able to queue events and send event triggers to scripts at once
[19:26] <Twylight> Maybe I am not explaining this right..
[19:26] <Losthope> i think it would be cool to be able to have timers in your script that would send events to the queue
[19:26] <Twylight> My event design allows for both Ac triggerable events and user defined events
[19:27] <Twylight> And ofcourse there would be a Tick event for time tracking
[19:27] <Twylight> Have you seen the Empty Plugin from Zycra Aanon?
[19:28] <@Aanon> not in detail but i've seen it.
[19:28] <Losthope> alot of good info on her site
[19:28] <@Aanon> y.
[19:28] <Twylight> Let me load that web site real quick, but its from there and what cibo said that I am getting a sense that this works this way, hehe
[19:28] <Twylight> I could be wrong tho
[19:29] <Twylight> Private Sub NetEcho_EchoMessage(ByVal pMsg As DecalPlugins.IMessage
[19:29] <Twylight> When Decal sends an event to a plugin that function gets called
[19:29] <Twylight> That is not within the normal loop of the plugin
[19:29] <@Aanon> it would also be cool... if by default if the event does not get sent unless waitevent was called (same as AC) or the script developer explicitly says to allow the script to be interrupted on certain events.
[19:30] <Twylight> Thats more up to the scripter
[19:30] <Twylight> When the persons script is doing one thing they should know it should not be doing anything else until its task is done
[19:30] <Losthope> i am thinking i get what twylight is saying
[19:30] <Twylight> we have to draw the line between what our plugin does and what the scripter has to do
[19:31] <Twylight> If we just want to make a robot then we should forget this scripting nonsense and do so.
[19:31] <Twylight> But if people just want an answering machine script then fine..
[19:31] <Twylight> We have to make sure they can do everything, which means we dont want to enforce certian things.
[19:31] <Twylight> Anyhow..
[19:31] <@Aanon> right.
[19:32] <Twylight> Private Sub NetEcho_EchoMessage(ByVal pMsg As DecalPlugins.IMessage) is a function that is called whenever a event happens
[19:32] <@Aanon> our plugin will have to handle the events, que them, and allow the script to be called and processed based on what they are interested in.
[19:32] <Twylight> Its outside of the active loop of the plugin, or I should hope it is atleast.
[19:32] <Losthope> and use messages.xml to get what the event is right?
[19:32] <Twylight> No
[19:32] <Twylight> Please, just let me explain these basics first ok?
[19:32] <Twylight> So everyone sees where I am standing
[19:33] <Twylight> In a seperate loop that constantly runs we take an event from the event queue and either process it ourselves in the plugin, updating some value like health or spell buff running out or starting and the like.
[19:34] <Twylight> The seperate loop handles just one event at a time one after the other as per the queue
[19:34] <Twylight> The NetEcho_EchoMessage() that Decal calls in our plugin handles adding the events Into that queue
[19:35] <Twylight> My problem in answering your question about the plugin being multi threaded is I am not sure if that itself constitues being multi threaded
[19:36] <@Aanon> what do you mean by ... if that itself..?
[19:36] <Twylight> Does having a loop processing a queue and an outside call adding to the stack make it multi threaded
[19:37] <@Aanon> yes.
[19:37] <Twylight> We dont have our plugin say "Hey decal, what ya got next"
[19:37] <Twylight> Decal is saying "here, take this" hehe
[19:37] <@Aanon> right.
[19:37] <Twylight> My point is is that isnt something We do...
[19:37] <@Aanon> but only gives it when the event has been 'handled' (method completes)
[19:37] <Twylight> We only take the info and queue it when its given
[19:38] <@Aanon> and you need another thread to run the loop of actually processing.
[19:39] <@Aanon> right?
[19:40] <@Aanon> (still thinking about it?)
[19:40] <Twylight> Looking at the example
[19:40] <Twylight> i see no multi threads
[19:40] <Twylight> Its also not doing anything however so its not the best example 8)
[19:40] <@Aanon> =)
[19:41] <@Aanon> we can ask Cibo exactly on this point.
[19:42] <@Aanon> I think we should be able to write a thread if needed (haven't done one in C or VB).
[19:42] <@Aanon> Then we can do what you are saying.
[19:42] <Twylight> I think this is already done by default really..
[19:42] <@Aanon> that would be great!
[19:42] <Twylight> but yes, Cibo would be able to say yes or no on this point
[19:43] <Twylight> Well I do not see how many other plugins would be working unless this is how it was...
[19:43] <Twylight> take 6th sense for example
[19:43] <@Aanon> it is purely event based.
[19:43] <@Aanon> it gets a message and handles it.
[19:43] <@Aanon> arcane lore would be one to question.
[19:43] <@Aanon> i mean..
[19:44] <Twylight> Arcane Knowledge
[19:44] <@Aanon> Arcane Knowledge.
[19:44] <@Aanon> y =)
[19:44] <Twylight> And no it wouldnt, it handles no events 8)
[19:44] <Twylight> Hmm
[19:44] <@Aanon> but, you click on a button and it puts your spell together.
[19:44] <Twylight> I cant think of any plugin that isnt either no-event or event-driven
[19:44] <Twylight> yeah but that has nothing to do with events from decal
[19:44] <@Aanon> true...
[19:45] <Twylight> Just mouse movement
[19:45] <@Aanon> it might be blocking all events.
[19:45] <Twylight> Doesnt need to block em
[19:45] <@Aanon> oh...
[19:45] <@Aanon> so...
[19:45] <Twylight> Just doesnt initialise the echo filter
[19:45] <@Aanon> you are saying...
[19:45] <@Aanon> oh.
[19:46] <@Aanon> well...what I was going to say...
[19:46] <@Aanon> i clicked on the button and it started running.
[19:46] <@Aanon> if we did listen for the event,
[19:46] <Twylight> Yes it does do that
[19:46] <@Aanon> not sure how or what it would do.
[19:46] <Twylight> But that isnt an AC event, tahts an event the plugin generates when you click the button
[19:47] <@Aanon> so we need to find out if the plugin can run and if events can still be sent to the plugin at the same time.
[19:48] <@Aanon> Ok... you find out from Cibo... and let us know.
[19:48] <Twylight> K
[19:48] <@Aanon> I've got to run.
[19:48] <@Aanon> You might need to add Climax to the sourceforge project.
[19:48] <Twylight> Do you want me to cut and paste this log in a forum or to upload it
[19:48] <Twylight> If its upload you have to tell me how to 8)
[19:48] <@Aanon> when i tried to add Climax, it gave an error.
[19:49] <Twylight> His userid is just 'climax' ?
[19:49] <@Aanon> yes.
[19:49] <@Aanon> but, something isn't right.
[19:49] <Twylight> Did he activate his account yet?
[19:49] <@Aanon> said he did.
[19:49] <@Aanon> but it gave me an error... you might have to work with him on it.
[19:49] <Twylight> k
[19:50] <@Aanon> 2 easy ways to add the chat log... through the docs link or just paste it into a message in the forum.
[19:50] <@Aanon> you decide.
[19:50] <@Aanon> if in forum...
[19:50] <@Aanon> we can make more comments below.
[19:50] <Twylight> Ill do forum then
[19:50] <@Aanon> but we can always refer to the doc from the forum. =)
[19:51] <Twylight> You get an ERROR - No Error message from adding him?
[19:51] <Twylight> Ill do both
[19:51] <Twylight> hehe
[19:51] <Losthope> could you add my account to that sourceforge site?
[19:51] <@Aanon> sure...
[19:51] <@Aanon> what is it?
[19:51] <Losthope> losthope
[19:51] <Twylight> Ddint see that comming 8)
[19:51] <@Aanon> ok... you are in.
[19:52] <@Aanon> i think climax registered incorrectly or didn't finish.
[19:52] <Twylight> Same
[19:52] <Twylight> Ill catch him later
[19:52] <@Aanon> losthope...
[19:52] <@Aanon> what role do you want?
[19:52] <@Aanon> is there anyone else (cj)?
[19:52] -> *Cibo|work* If you could drop me a message when your back I have a question to ask you. thanks.
[19:53] <cj> me? oh, I'm a linux guy. I don't have a windows dev system, sorry
[19:53] <@Aanon> oh
[19:53] <Twylight> Truth be said Losthope was the first one to offer to help with making this whole thing
[19:53] <cj> I'm interested if I can help from my position in linux
[19:53] <Twylight> Then climax showed up wanting to do so and then you and tanarak
[19:53] <Twylight> And I hope I didnt just murder his name, hehe 8)
[19:53] <Twylight> Can ya op me Aanon?
[19:54] <@Aanon> op?
[19:54] <Losthope> not sure what role would be best for me
[19:54] <Twylight> Type //mode # +o Twylight
[19:54] <@Aanon> well, I added you as a 'all-hands on person' like the rest of us.
[19:54] <Losthope> cool
[19:55] <@Aanon> and as a full proj admin.
[19:55] <Losthope> works for me thanks
[19:55] <Twylight> We can figure out exact duties once we get them 8
[19:55] <Twylight> 8)
[19:55] <Losthope> sorry about not talking reading in other windows
[19:55] <Twylight> Right now all we got is a desire to make this and alot of questions on its design so for now thats what were all doing
[19:55] *** Aanon sets mode: +o Twylight
[19:55] <@Aanon> there you go.
[19:55] <@Twylight> Thanks man
[19:56] <@Twylight> Ill register this channel for us
[19:56] <@Aanon> ok.
[19:56] <@Aanon> we can write the outstanding questions on sourceforge also... and answer them as we can.
[19:56] <@Aanon> (possibly getting some questions answered from the Decal guys)
[19:57] <@Twylight> What Id like is every document out there for decal, hehe
[19:57] <@Twylight> No matter how inane it may seem
[19:57] <@Aanon> yep.
[19:57] <Losthope> hard to find good documents
[19:57] <@Aanon> well... Tanakar has started the process...
[19:57] <@Aanon> we'll get them all.
[19:58] <Losthope> best i have found is zyrcas and the messages.xml protocal doc
[19:58] <@Aanon> later!
[19:58] <@Twylight> LAter Aanon 8)
[19:58] <@Aanon> hey...
[19:58] <@Aanon> before I run...
[19:58] <@Twylight> The best info Ive ever had was from the xml protocol file
[19:58] <Losthope> zyrca does have some good info
[19:58] <Losthope> explains alot of the coding
[19:58] <@Aanon> we can set up a email list on sourceforge so that we can broadcast future meeting times on IRC, etc.
Addon
[20:12] <@Twylight> Can we run a continous loop to process a queue and still have NetEcho update that queue or would this require us making the plugin multi threaded?
[20:13] <Cibo_Matto> a plugin can't run in a loop since it has to return to AC, if you made a loop it would have to be on another thread