Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Development ➜ Scripting engine refactoring?
Scripting engine refactoring?

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  3  4  

Posted by Twisol   USA  (2,257 posts)  Bio
Date Mon 06 Sep 2010 11:31 AM (UTC)

Amended on Mon 06 Sep 2010 11:39 AM (UTC) by Twisol

Message
I'm mucking with the CScriptEngine code right now, aiming to refactor it so new scripting interfaces can be defined easily. If anyone has experience with the scripting engine code (or WSH in general) and is willing to share anything they might know, I'd appreciate it. And in case anyone is willing to lend a hand, here's my current battle plan. It's probably going to change a lot, too; this is just something I've built out while hacking on a pseudo-solution in Notepad++.

Initial thoughts: non-WSH Lua support seems to have been hacked into the CScriptEngine class to short-curcuit normal CScriptEngine behavior with regard to WSH, including lots of special-cases like IsLua(), ExecuteLua(), etc. It's basically DIY polymorphism. At first glance it doesn't seem too hard to create a base interface (IScriptEngine), which any scripting engine will have to implement.

In the process, I'm removing CreateScriptEngine() and DisableScripting(), moving their functionality into the constructor/destructor, and using exceptions in the constructor. Changing calling code here was trivial, and I think it looks better too.

Here's the current IScriptEngine interface. Please don't assume this is the final version. This is just what's pseudo-working right now. (I haven't created a LuaScriptEngine yet.)

class IScriptEngine
{
public:
  virtual ~IScriptEngine() {}

  virtual DISPID GetDispid (const CString& strName) = 0;
  virtual bool Parse (const CString& strCode, const CString& strWhat) = 0;

  virtual bool Execute (DISPID& dispid,
                        LPCTSTR szProcedure,
                        const unsigned short iReason,
                        LPCTSTR szType,
                        LPCTSTR szReason,
                        DISPPARAMS& params,
                        long& nInvocationCount,
                        COleVariant* result) = 0;


  // Use to create a script engine by name.
  static IScriptEngine* Create (CString& strLanguage, CMUSHclientDoc* pDoc);
};



The biggest design roadblock I've hit - luckily during the Notepad++ phase - is that MUSHclient intentionally treats Lua and WSH differently. This is going to make it really, really, really hard to abstract behind a common interface. For example, Lua functions registered with a trigger will receive the line styles as an extra parameter. This is passed as a table, which I'm not sure WSH can gracefully handle. (VBscript is an obvious example of a language without built-in maps.) Obviously, I can't lock down Lua from doing this. It would be simpler for me XD but it's a non-option.

I have two solutions I've been mulling over. The first is to come up with some common parameter/returns interface that remains backward-compatible and can handle the breadth of options Lua has. Ummm... Just writing that down was disheartening. The only way I've considered to do this is to use a DISPPARAMS structure of VT_ARRAY|VT_VARIANT, which I think can be nested. Backward compatibility is still up in the air at this point.

The second solution I've considered is to have "contextual" methods in IScriptEngine, so the engine knows what your intention is and can adapt the parameters accordingly. This seems most workable, especially as it seems to be how ExecuteLua works currently. (Among its parameters are a PaneLine and a t_regexp...) The idea is that you'd pass everything a given call might want, and the script engine implementation would pass on only the parameters it can handle. This is my preferred solution.

I'd really like to hear feedback on this in particular. It's the biggest issue I have right now.



tl;dr: I'm making lots of changes to scripting support, and I'd like feedback. I also have a pretty good-sized problem. Can you help me?

Thanks for reading! :S
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #1 on Mon 06 Sep 2010 11:40 AM (UTC)

Amended on Mon 06 Sep 2010 11:41 AM (UTC) by Twisol

Message
I have a really bad habit of editing my posts long after they're posted, so unless you're just now reading this, you might want to look up again and see the IScriptEngine interface I inserted. =/
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #2 on Mon 06 Sep 2010 01:53 PM (UTC)
Message
Scripting languages that support WSH can already be added easily. Is the goal here to add languages that don't support WSH? Or is the goal to provide native-like embedding such as what Lua has? Is there a language in particular you want to support right now that does not work with WSH?

Designing a system that provides tight coupling with many different languages while remaining loose and agnostic to details will be hard, and essentially a reimplementation of WSH.

That said, if all cases are that calls take either X parameters, or some subset of those X, then it would be easy enough to have a map from language/"WSHness" to the subset of parameters -- especially if it's a prefix rather than a general subset.

BTW, I wouldn't say that eight minutes is "long after" the first post. ;-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #3 on Mon 06 Sep 2010 04:00 PM (UTC)
Message
Quote:

(VBscript is an obvious example of a language without built-in maps.) 



Set map = CreateObject("Scripting.Dictionary")


You're right though that it's not a native type in non-.Net.

Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #4 on Mon 06 Sep 2010 05:49 PM (UTC)

Amended on Mon 06 Sep 2010 05:53 PM (UTC) by Twisol

Message
David Haley said:
Scripting languages that support WSH can already be added easily. Is the goal here to add languages that don't support WSH? Or is the goal to provide native-like embedding such as what Lua has? Is there a language in particular you want to support right now that does not work with WSH?

Both, really. And to clean up the interfaces in general. I'm a big fan of low coupling, as you know. :)

Some of the WSH-based languages have odd differences from their non-WSH counterparts. Ruby is particularly weird in my opinion, because you're supposed to be able to call "def foo; end" if it's defined in the top-level. ActiveRuby requires "def self.foo; end".

And I think it would be cool to support the V8 Javascript engine, which is what powers Google Chrome. It's a very fast implementation of the language, plus it would be usable under Wine.

David Haley said:
Designing a system that provides tight coupling with many different languages while remaining loose and agnostic to details will be hard, and essentially a reimplementation of WSH.

Yes, and that's what the first solution I described would effectively do. I slept on it, and I don't feel like it would be the best route to take. The context-specific calls would be easier, and it's not like we're out to reuse this outside MUSHclient. I simply need to define a context-specific execute for each time where MUSHclient calls the engine, which is what ExecuteLua already does. The problem with ExecuteLua is that it's specific to Lua and it has special-cased parameters too, but I believe I can probably split those into separate method signatures.

David Haley said:
BTW, I wouldn't say that eight minutes is "long after" the first post. ;-)

There've been a few situations where someone posted while I was still editing and I didn't think they had seen my edits, so hey, better safe than sorry. :)


[EDIT]: I forgot to mention something I've been reading a lot of lately. I found Bjarne Stroustrup's Style and Technique FAQ [1], and also a style guide [2] that he recommends for C++. I agree with a whole lot of the rules in the latter, except for some like enforcing lowercase constant/enum identifiers on stylistic grounds. But I think they're good to read.

[1] http://www2.research.att.com/~bs/bs_faq2.html
[2] http://www2.research.att.com/~bs/JSF-AV-rules.pdf
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #5 on Mon 06 Sep 2010 06:33 PM (UTC)
Message
Twisol said:
And to clean up the interfaces in general. I'm a big fan of low coupling, as you know. :)

The scripting engine is a core component of the client and likely to be rather delicate. As such personally I would be very wary of changing something so major about it unless it was for a very clear goal. Does all of this need to be done to include Javascript V8? How important is it to have that? People seem to get by just fine with Lua and the other languages. Very few people seem to use JScript for the moment, and I doubt it's because of performance issues.

Yes, it would be "cool" to support Javascript V8, but how "cool" will all the time that needs to be spent on this be? I'm saying this not w.r.t. your time because you can do whatever you want with it and if this is fun to you then it's worth it, but w.r.t. Nick's time (and potentially other people) involved in the reviewing, testing, etc.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #6 on Mon 06 Sep 2010 06:41 PM (UTC)
Message
It's starting to feel like the source code is untouchable. I do some t_regexp refactorings and I'm told new features would be better, so I tackle CScriptEngine and I'm told nobody wants to spend the time to check my changes. So why am I here?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #7 on Mon 06 Sep 2010 09:38 PM (UTC)
Message
You suggested recently a requirement for rotating images (which you did not provide suggested source for). I agreed that could be useful (although haven't seen it "in the wild" however) but I did it within a couple of days of being asked.

I could see the benefit in this case of spending time on it.

For me, using my time involves a cost/benefit analysis. I'm not talking cash here, but a reward for time spent.

For example, adding miniwindows was a major time expenditure (even yesterday I spent the entire day improving documentation until my eyes went blurry). But the benefits are fairly obvious. MUDs I know of (like Aardwolf, God Wars, Achaea, et. al.) are using it to good effect to provide maps, gauges, chat logs, XP bars etc.

But rewriting the regular expression handler internally? This wouldn't have any tangible benefit to players. Or redoing the script engine? Now I am the first to admit that when I added scripting I hadn't heard of Lua, and didn't know much about the WSH. So it is really crappy, I admit that. But despite that, it seems to work. I get few complaints, if any, that simple scripting has major flaws or crashes.

I don't quite get why you want to add Javascript V8 (whatever that is). I thought you, Twisol, personally loved Lua. Are you bored with it?

It's a bit like Jumbo Jet designers wanting to provide 240v power, 110v power, 50 Hz and 60 Hz, NTSC and PAL on their jets for their customer's use "just in case" someone has a shaver or laptop charger that doesn't work with the supplied standard. But, people accept the limitations and work around them.

I have said time and time again that I know the source can be improved. It could be rewritten to get rid of MFC and then you could compile with g++. You could change all the MFC lists and maps to STL ones. You could improve the graphics. Scripting could be reworked. The GUI interface could be modernized and improved. The scripting functions could be tidied up to remove duplicates and inefficiency. The help file could be dragged into this decade. The installer could work better under Windows 7. The places files are put could be improved (eg. Documents folder).

Let's say I did that (or you did that). And let's say it took 100 hours. Probably twice that if the changes required documenting. That's a guess mind you. It might be 500 hours.

Now the question is, is that 100 to 500 hours better spent doing something else? Like maybe writing a new client from scratch using wxWidgets? Or making a fantastic mapper that works on every known MUD? Or writing a new client/server from scratch, maybe one that uses 3D graphics?

There are benefits to redoing the source, I can see. I probably won't be supporting it for the next 20 years, or even the next 10. So if it was rewritten to be easier to modify, that would be a help. But will people really be using MUSHclient in 10 years time? I am getting the feeling that with new consoles coming out (and even things like the iPhone/iPad with games on it) the market for MUD games will gradually dwindle.

Now it probably won't ever die, but could not MUSHclient in its current form, maybe with minor tweaks, not be used to service that "market" indefinitely?

Meanwhile, back to the scripting engine. Even making minor changes is likely to make existing scripts fail. I was worried that my change to the way the metatables are set up might even do that. Last month alone mushclient443.exe got 3424 hits on the web server, plus 685 hits for MUSHclient_4.43.zip. And those figures are generally consistent from month to month.

So, something like 4000 downloads a month, that's a lot of angry people if things change so that existing plugins don't work, or existing examples on this forum become invalid.

Here, let me show you something. I just logged into Aardwolf and typed their "clients" command, which shows how much each client is used based on its telnet identifications string.


clients
+------------------------------------------+
|       Clients in use on Aardwolf         |
+---------------------------------+--------+
| Alclient                        |      1 |
| Ansi                            |      4 |
| Atlantis                        |      3 |
| Cmud                            |     35 |
| Dumb                            |      2 |
| Kildclient                      |      1 |
| Kmuddy                          |      1 |
| Mudlet                          |      3 |
| Mushclient                      |    123 |
| Mxit                            |     16 |
| Tf                              |      4 |
| Tintin                          |      8 |
| Tmc                             |      1 |
| Vt100                           |     12 |
| Xterm                           |      1 |
| Zmud                            |    108 |
+---------------------------------+--------+
| Unidentified Clients            |     29 |
| Unknown Clients                 |      2 |
+---------------------------------+--------+


I just want to point out that MUSHclient in its current form is the most popular one, easily. The second-most popular one is no longer being actively supported, particularly on Vista and Windows 7. Other clients, some of which have had more modern interfaces and a lot of work going into their design and implementation, have very low usage counts.

Once again, I am happy to make changes, or incorporate changes, that have some tangible end-player benefit. For example, rotating images, playing multiple sounds, playing background music, mappers, health bars, stuff like that. But I draw the line at changes for the sake of improvements to the code, where such changes may only benefit one or two people, those who actually read the source. And in fact, if major changes were made there it would simply make it harder for me to maintain the code, so that would actually be a negative change.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #8 on Mon 06 Sep 2010 09:43 PM (UTC)

Amended on Mon 06 Sep 2010 09:44 PM (UTC) by Twisol

Message
Alright then. I guess I'll get to work on Aspect.

Thank you for your patience with my clearly misguided notion of cleaning up the MUSHclient source. If you don't expect MUSHclient to be used for playing MUDs in the near future, then there's really no point, I have to admit. Meanwhile, I'm going to try to make MUDs more viable in the long-term.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #9 on Tue 07 Sep 2010 03:44 AM (UTC)
Message
By the way, I don't want to be picking at this scab or anything, but isn't that client-usage graph a little biased? Aardwolf offers MUSHclient as its "official" client.

While I'm at it... Yes, I like Lua a lot. No, I'm not cheating on it with Javascript. I've observed previously that we seem to have very conflicting views on source management, so there's no real surprise anywhere in this topic. But honestly, of the changes I've proposed, I think this one is the closest to the end-user and not a deep-in refactoring like t_regexp was.

For example, I've said before that it would be nice to pass functions instead of names to certain API functions, for example. If it were easier to bulk up the Lua glue interface, this would be possible without breaking backwards compatibility. Also, you can even "version" scripting interfaces, by giving the new one a new language identifier. If I were to, say, make extensive changes to the Lua interface, I'd probably make it a new interface and call it something else.

I know I make a lot of suggestions, but of late it's more to gauge interest in the idea, as I've mentioned before. I don't expect you to write anything just for me. If you were to ask me to get my hands dirty and implement it myself, I couldn't be any more willing! I just try to avoid it at first because, like you (for once), I don't want to expend effort when nobody's going to use it.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #10 on Tue 07 Sep 2010 04:18 AM (UTC)

Amended on Tue 07 Apr 2015 01:38 AM (UTC) by Nick Gammon

Message
Twisol said:

... isn't that client-usage graph a little biased? Aardwolf offers MUSHclient as its "official" client.


I chose Aardwolf because they make figures available. I said it was Aardwolf, and people who visit this forum know that I have been working with them to an extent.

However to compare more generally, there was a thread on the Mudstandards.org forum where various client authors disclosed their download figures.

[EDIT] (April 2015) Warning: Domain name mudstandards.org has been abandoned. That site is now an adult products shop.

According to that (rounded to nearest 100):


  • MUSHclient: 4100
  • zMUD: 3900
  • cMUD: 2100
  • TinTin+: 1600
  • Mudlet: 1400


These figures are per month, and are historical (things may be different now) for around 2009-2010. They are self-disclosed, and hopefully cover every genre of MUDs, not just one that happens to recommend one client over another one.

Also, these are download figures. No-one knows really whether a program gets used once or is used daily for five years. Well, Zugg can tell you because of the clients hitting the web site to check for updates, so he is able to give you an execution count. There isn't much point in publishing that because I don't have comparative figures for other clients.

According to Zugg's figures, zMUD is trending down on execution counts, and cMUD is trending up, which you would expect because cMUD is newer.


Also see this page:

http://www.godwars2.org/mwi/clients

On that he lists client usage and MUSHclient is around 52% of usage, with no other client having more than 12% (again, that MUD probably favours MUSHclient because of the miniwindow stuff).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #11 on Tue 07 Sep 2010 04:40 AM (UTC)
Message
Twisol said:

Meanwhile, I'm going to try to make MUDs more viable in the long-term.


Good idea. I tried that once.

http://www.gammon.com.au/forum/?id=10043

http://www.gammon.com.au/forum/?id=10106
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #12 on Tue 07 Sep 2010 05:23 AM (UTC)
Message
Twisol said:
I know I make a lot of suggestions, but of late it's more to gauge interest in the idea

Respectfully, then, when you make a suggestion and other people don't show a lot of interest, is it necessary to get upset and effectively take your toys and leave? Enthusiasm is most certainly welcomed, however that doesn't mean that all ideas will be accepted as being a good priority at the moment. Don't forget that any change you make will take work on the part of other people; Nick at the least will have to review everything and become familiar with it, and in some instances it might even affect plug-in developers, and finally it might change user experience (hopefully for the better, of course). The point here is just that even if you were to do "all the work" in implementing something, there is always more work to be done in getting that something integrated into the main release.

Now, regarding this particular change. First you said it was about Javascript V8, now you say it's about (for example) functions rather than names for Lua. Well, if the goal is to make Lua support better, perhaps that could be addressed without a full rewrite of the entire scripting architecture?

One of the hardest things to avoid when getting into big projects like this is the temptation to rewrite lots of things just because you think it'll be "cleaner" in the end of the day. Sometimes it will, sometimes it won't but will seem so because you wrote it. Regardless in the end of the day there are usually more pressing things to take care of. Naturally this is a hard balance to strike because sometimes old code is crufty and causes more trouble than it's worth. But so far I don't think we've run into that point, at least not with demonstrable failures that have created clear costs.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #13 on Tue 07 Sep 2010 05:52 AM (UTC)

Amended on Tue 07 Sep 2010 06:05 AM (UTC) by Twisol

Message
David Haley said:
Respectfully, then, when you make a suggestion and other people don't show a lot of interest, is it necessary to get upset and effectively take your toys and leave?

I became discouraged. It seems like I'm thwarted at every turn with my attempts to work on the source. I've asked Nick before if there's anything specific I can do to help out. I can't find that discussion right now, but by and large there's no "official" feature/bug list for me to work on. Sans a Nick-blessed task, I figured I would clean up the code to make things easier to do.

(Besides, nobody wants my toys. I'm happy to share.)

David Haley said:
Enthusiasm is most certainly welcomed, however that doesn't mean that all ideas will be accepted as being a good priority at the moment. Don't forget that any change you make will take work on the part of other people; Nick at the least will have to review everything and become familiar with it

I understand that Nick would have to become familiar with my changes, the point's been made previously. I don't understand what you mean by "a good priority" though. Like I explained, there's nothing else for me to do. But I don't really want to do nothing with MUSHclient, either. Aspect is a fine goal, but it's a big one, and I'm only one person.

David Haley said:
The point here is just that even if you were to do "all the work" in implementing something, there is always more work to be done in getting that something integrated into the main release.

I'm not sure whether you're trying to dissuade me from making changes, or explaining again that changes need to be carefully considered. Either way, Nick appears to be the only one allowed to change things.

David Haley said:
Now, regarding this particular change. First you said it was about Javascript V8, now you say it's about (for example) functions rather than names for Lua. Well, if the goal is to make Lua support better, perhaps that could be addressed without a full rewrite of the entire scripting architecture?

I'm sorry, I never said it was about V8. That was an example of what could be done. Furthermore, my changes would allow both such things to be done more easily. I'm building a framework for features rather than piling more features right on top of old ones.

Personally, I can't consciously write code that's ugly or confusing. To implement either V8 or improved Lua support on top of the current state of affairs would be both.

But honestly... I'm just breaking CScriptEngine into two classes with a common interface. I'm still working on it, and it's not that hard to do. Nothing like what I expected to have to deal with.

David Haley said:
One of the hardest things to avoid when getting into big projects like this is the temptation to rewrite lots of things just because you think it'll be "cleaner" in the end of the day.

Yes, I learned that lesson well from my 'old' branch in my GitHub repository.

David Haley said:
Naturally this is a hard balance to strike because sometimes old code is crufty and causes more trouble than it's worth. But so far I don't think we've run into that point, at least not with demonstrable failures that have created clear costs.

I want to ask a honest question of you. Please don't take this the wrong way. How familiar are you with the MUSHclient source?

In my honest opinion, and meaning no slight to Nick himself, the whole thing is "crufty". I love MUSHclient to death, and it's a testament to his perseverance that it's so stable and functional, but it seems like such a tangled maze of knots and interdependencies that I can't begin to tell where to add something. The most I can do is understand what the code is doing and figure out how it could be made better, then figure out how to do something with it.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #14 on Tue 07 Sep 2010 06:06 AM (UTC)
Message
Quote:
Like I explained, there's nothing else for me to do. But I don't really want to do nothing with MUSHclient, either.

What about your miniwindow system?

Quote:
I'm building a framework for features

I think the main point I have been trying to make is that features are more important than frameworks for features, and there are features that are needed -- like rich inventory list widgets, maps, and so forth.

Nick has very often talked about how nice it would be to have richer GUI environments, so even without having a whole framework for miniwindows, there is a lot of stuff that can be done.

Quote:
But honestly... I'm just breaking CScriptEngine into two classes with a common interface. I'm still working on it, and it's not that hard to do. Nothing like what I expected to have to deal with.

Maybe it'll be easy and Nick won't mind integrating it. Your initial post made it sound not-so-easy. You said yourself you were trying to gauge interest; well, I'm just telling you that I don't think it's worth spending time on.

Quote:
How familiar are you with the MUSHclient source?

Probably not as much as you, because I haven't been spending so much time on it.

Quote:
In my honest opinion, and meaning no slight to Nick himself, the whole thing is "crufty". I love MUSHclient to death, and it's a testament to his perseverance that it's so stable and functional, but it seems like such a tangled maze of knots and interdependencies that I can't begin to tell where to add something.

Well, in my experience, people sometimes get that feeling because they're confusing complexity for cruftiness. Something of this size will always be complex. You said yourself that Aspect is a big task; perhaps if you were to bring it to the level of stability and feature-richness that MUSHclient has, you would appreciate better how necessarily complex some stuff gets.

Even if it is "crufty", that is not in and of itself an argument for rewriting stuff. We've been over this before: there is a tradeoff to be made between time spent dealing with the consequences of "cruftiness" and time spent rewriting, fixing, documenting, testing, fixing some more, documenting more, etc., the changes to the code.

Heck, part of the reason that you get weird tangled mazes of knots and interdependencies is precisely that there can be subtle links between apparently different components. Obviously not all such cases are necessary, but how do you quickly tell which are which?

And in the end of the day, maybe Nick does prefer to spend his time writing rich graphical interfaces and methods for communication semantic information between server and client. Maybe he doesn't; I dunno. The point is just that it's his time to spend and I'm just trying to help you understand what you need to do to convince him that some task is worth undertaking. You sometimes act as if he never listens to you but that is demonstrably false if one looks at the suggestions forum; most recently he implemented the image rotation suggestion. Granted, he didn't implement everything you asked for, but he did take the suggestion and act upon it (and wrote the code, in this instance).
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

127,831 views.

This is page 1, subject is 4 pages long: 1 2  3  4  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home