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.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Possible new client written using wxWidgets?
Possible new client written using wxWidgets?

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

Pages: 1  2  3  4 5  6  7  8  9  10  11  

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #45 on Sun 26 Aug 2007 11:53 PM (UTC)
Message
Quote:
However it seems to me that as soon as you say "in order to run this program you must go to www.some_script_site.com and then download a 15 Mb file (possibly giving your email address to start the download), and then install it", you are making it harder for people to use your program.

Currently MUSHclient supports all the languages you mentioned above, and yet is only a two meg download. There is a big difference between requiring the scripting language for the program, and requiring it for the plugins and such. Granted, people using Python will need to have it installed on their system, and they will have to go through whatever scripting engine is being used (causing some issues like the current memory leak with ActiveScripting), but this is obviously acceptable to the people who prefer said language.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #46 on Mon 27 Aug 2007 12:27 AM (UTC)
Message
Vista tries to *fix* the security issue also by not allowing any but system level applications access memory of any other system level application, which even XP still allows. Only problem is, they had to leave a *hole* in it, so that installers could set drivers as "system level", and let those do stuff that others are not allowed. This means that a driver can be crafter to not only **see**, but depriviledge any process on the system, dropping what ever secure application was previously inaccessable back to the level of the user logged in, as though you where still using 98 and had effectively full access to them. All I can say is, "Sigh!!". I means, its pretty damn hard to *secure* something which has relied for years on insecure systems to function correctly. Its **going** to break, and any fixes for the breaks are invariably going to breach the security. lol
Top
Posted by Isthiriel   (113 posts)  Bio
Date Reply #47 on Mon 27 Aug 2007 03:57 AM (UTC)

Amended on Mon 27 Aug 2007 04:33 AM (UTC) by Isthiriel

Message
Quote:
Nick Gammon wrote:
Python installer (ActivePython-2.4.3.12-win32-x86.msi) 18.7 Mb

This is ActiveState's Python-for-Windows installer and I have no idea why it is so big :(

However your point works even with the reference implementation (Python-2.4.3.msi = 9,462 KB and the latest, Python-2.5.1.msi = 10,714 KB) to which you need to add pywin32 (4,250 KB) to get the "same" install.

OTOH that includes more than 6MB of documentation and several libraries that you can probably skip for an embedded scripting language (IDLE and Pythonwin to start with)

The last number I remember hearing as to how much a Python scripting implementation bloated the executable was 2-4 MB? Which seems to be about the right order of magnitude ... and is still larger than my entire MUSHclient install :D

OTGH wxPython2.8-win32-unicode-2.8.1.1-py25.exe is 7,183 KB. I'm sure wxLua isn't much smaller.

Quote:
Shaun Biggs wrote:
Currently MUSHclient supports all the languages you mentioned above, and yet is only a two meg download. There is a big difference between requiring the scripting language for the program, and requiring it for the plugins and such.

I think the problem is that MUSHclient supports the languages by (dynamically) linking against Active Scripting which is guaranteed to be present on a Windows machine (>W95/IE4). Linking against the actual scripting language is a different problem... unless you dynamically link against the dll with a LoadLibrary(?) call and cope with its absence?

In any case, if Nick releases a(n open source) wxWidgets client with Lua-only support I'm sure one of us can hack support for the other languages back into it and release a patch against the source. :D

(Got to say, downloading the 100+ MB gcc toolchain/Visual C++ Express makes interpreter downloads look wimpy. :D)
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #48 on Mon 27 Aug 2007 03:41 PM (UTC)
Message
Quote:
If the interface is the same, you can just link against some headerfiles and be done with it, right?

Unfortunately, no. You still need to have provided bindings for all of the various whatevers you want to extend the scripting language with.

A few quick points to Isthiriel:

Sets:
Yes, Lua doesn't have a set library (that is intentional). But, and I know this won't satisfy you, the operations you described can be implemented in a number of minutes.

Generators:
That is a coroutine, and Lua can do that quite easily. I'm not entirely sure what you mean by saying that there is a proposal to turn what you showed into a coroutine.

Registry:
As I said, Lua deliberately does not include the registry because it is Windows only; in fact, Lua does not include anything by default that will not compile on a standard ANSI C platform. That being said, I strongly dispute the claim that it would take months to provide registry access. It's just a few simple API calls.

Debugging:
This is one area where Lua is lacking, yes.

Syntax:
I'm not sure what objective measures you are talking about, so I'd be interested in seeing them. I'd also be interested in knowing who ran the study. :-)

Lua for simple things:
Well, ok, but it's extremely different to say that Lua as a language is only good for those simple things, and to say that you as a programmer can only use it for simple things. I would dispute the former with empirical evidence, but I am happy to accept the latter. :) I am "read-only" Python, so I also would not use Python for much of anything but that has nothing to do with Python as a language.



And now for something completely different and back on topic:

Quote:
Linking against the actual scripting language is a different problem... unless you dynamically link against the dll with a LoadLibrary(?) call and cope with its absence?


It's not so simple as just linking against the scripting language's implementation. Every language has different ideas of how you're supposed to talk to it. Embedding Perl "manually" by directly talking to the language implementation is something of a nightmare, at least compared to Lua which is almost a 1-2-3 process. I haven't played with Python yet, nor PHP, so I don't know how things work for those.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Isthiriel   (113 posts)  Bio
Date Reply #49 on Mon 27 Aug 2007 04:26 PM (UTC)
Message
Sets: I know. I've done it in C++. The point was that sets are a primitive type in Python so you don't have to.

Generators:Python gathers features by community request. Anyone can write a "Python Enhancement Proposal" and submit it to the development mailing list where it gets debated, etc... and the final form is added to the Python documentation (because they usually have useful examples as to why they should be added).

PEP 342 "Coroutines via Enhanced Generators" http://www.python.org/dev/peps/pep-0342/ is what I was talking about specifically.

Python also comes in a reference (CPython) and Stackless implementation and I think they can be treated interchangably for binding :-/

Registry: A hack that gets the job done and a library of similar quality to _winreg are two different things. Yes, it is a handful of fairly straightforward C++ API calls, and you only need to repackage them with lua bindings so the lua interpreter can find them and then test them. Given that this isn't my day job, a "month" of programmer effort is something like 30-40 actual programmer hours -- during which time I'd have to learn what it takes to write the lua bindings :P

Syntax: I'll see if I can find the site again, but the example I was thinking of was a time/loc comparison between various project groups for a university software engineering course. The groups got to choose their language and they had to write to a specification.

Quote:
David Haley wrote:
Well, ok, but it's extremely different to say that Lua as a language is only good for those simple things, and to say that you as a programmer can only use it for simple things.

Yes and no. Lua is Turing-complete and is technically as powerful as any other Turing-complete language. That doesn't speak to how "good" the language is for programming large/complex projects.

I don't think Lua is designed for large projects. Python isn't either, but Python has a lot of glue features (and libraries) for interoperation with other modules and languages which help.

Quote:
David Haley wrote:
It's not so simple as just linking against the scripting language's implementation.

I don't think I said that it was. I was pondering whether it was possible at all to write linking code that could detect the presence of the script interpreter and activate itself as necessary.

Embedding Python is supposed to be fairly simple. It's something I've been meaning to try and haven't actually gotten to do.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #50 on Mon 27 Aug 2007 04:39 PM (UTC)
Message
Registry:
I'm not sure what features _winreg provides, but, it would be quite simple to bind a Lua table to the registry table by wrapping around API calls. But of course, if this isn't something you'd know how to do, it would take a lot longer than if you were already comfortable with the whole process. But then again, the same can be said of anything of this sort.

Syntax:
I'm not sure it's appropriate to proceed like those studies. When I program in a language, I want the syntax to be obvious to me both when I read and write it. I don't really care (as a user) how complex it is to specify a grammar for the syntax. And yes, C++ has nasty, nasty syntax as far as the parser is concerned. But I'm a human, not a parser, so I don't need to reason in context-free grammars. :-)

Besides, a language being 'clean' as far as a grammar concerned isn't necessarily helpful. I can write pristine context-free grammars that would yield a language very difficult for humans to deal with. So again, I'm quite unsure that measuring how easy it is for students to write a specification is an appropriate way to measure how good a language's syntax is. I guess it depends on what 'good' means. (I thought we were talking about how easy it is for users to write in it.)

Quote:
Yes and no. Lua is Turing-complete and is technically as powerful as any other Turing-complete language. That doesn't speak to how "good" the language is for programming large/complex projects.

Actually, I was referring to you personally, since you were talking about what you personally would do with both languages. I was not talking about what Lua is technically capable of doing, but what you are capable of doing with Lua. (And on the flip side what I am capable of doing with Python.)

Quote:
I don't think I said that it was. I was pondering whether it was possible at all to write linking code that could detect the presence of the script interpreter and activate itself as necessary.

Wasn't sure that you were; just wanted to throw that out there. And yes, I think it is be possible to do what you describe.

Quote:
Embedding Python is supposed to be fairly simple.

I've heard the same, yes.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #51 on Mon 27 Aug 2007 10:05 PM (UTC)
Message
Quote:

What prevents you from writing support for Python? If the interface is the same, you can just link against some headerfiles and be done with it, right?
...
Merely leave the option there to use Python, Perl, Ruby and so forth if the user has those installed.


I don't see how you can easily support lots of script engines, short of using the Microsoft scripting interface, which itself is working directly against the idea of making a client available on multiple platforms.

For one thing, each language has different facilities (sets in Python were mentioned), so some sort of "common" interface would have to use the lowest-common-denominator that is provided by all languages (eg. you can forget sets).

Already in MUSHclient there are two completely different ways of calling a callback function - the MS scripting interface way (where variables are turned into variants), and the Lua way (where variables are pushed onto the Lua "stack").

Quote:

Worstje said:

But for anything other than elementary scripting, I am very glad I'm not stuck with Lua.


As I said before, I don't want to get into a "script language war", because choice of languages is rather a subjective thing.

However I would like to point out one fact, as opposed to an opinion ...

The MMORPG game "World Of Warcraft", which (claims to) have over 8 million subscribers, each paying around $US 15 per month (work that out!) chose Lua as its scripting language. Now, Blizzard is big enough to write their own language, or spend weeks evaluating the various languages available. One supposes that they compared Lua to Python, Perl, TCL, Java, and all the other possible languages, plus the option of developing an in-house one. Surely the fact that they chose Lua says something about the language?

They use Lua not only for end-user scripting, but the client they supply (the GUI client that displays you running around and fighting) has a considerable amount of scripting support supplied as default by Blizzard. For example, incoming chat messages are routed to various panes on the main screen by its supplied scripts.

They have documented their scripting interface (there are hundreds of them), which allows scripters to create additional panes, write to them, move them around, catch events, and so on.

There are thousands of end-user addons (plugins as we call them here), which do all sorts of things. There are plugins to manage raids groups (groups of 10 to 40 people on a large quest), plugins to manage your inventory, and your auctions.

Despite being implemented in Lua, there are very rarely pauses or slow-downs in the interface, excepting perhaps when you go to an "auction house" initially, when there might be a 1-second delay while the tens of thousands of auction items are loaded into memory from the disk database (a Lua table).

They also have the advantage that, since Lua is cross-platform, it also works on their Mac version.

Again, the more popular plugins supply multiple (human) language support, by having files of messages in English, French, and so on.

Blizzard does not support other script languages for WoW, just Lua. By doing so they simplify their work load. They don't need to develop methods for converting variables from one language format to another.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Guest1   USA  (256 posts)
Date Reply #52 on Mon 27 Aug 2007 10:41 PM (UTC)

Amended on Mon 27 Aug 2007 10:44 PM (UTC) by Guest1

Message
@ Nick : without having to read reams of technical info that I wont understand easily if at all, will Lua enable you to achieve what most of the MC users would like to see - that is, configurable panes with multicolored text, and with dimensions that users can configure?

Additionally, will it be detrimental in any way to the existing MC feature set, meaning that will some features not be able to be mirrored using Lua, or performance levels (speed) be adversely affected?

Also, will you still able to configure new aliases/triggers/timers etc via the client itself in the same way the existing MC does (Shift+Ctrl+8, Shift+Ctrl+9 etc)?

If Lua, as some have said, is relatively easy to learn if you already have some understanding of VB or JS, then perhaps it's not that big an issue.. some sort of import feature to convert existing trigger/alias etc files to the new client would be nice, then all that would be required would be for users to convert their own called scripts to Lua.. there's a good community here, so perhaps we could help each other out in that area.. there's already plenty of example snippets in the list of script functions on this site, which is great.

Appreciate you even considering all this. Cheers.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #53 on Mon 27 Aug 2007 11:00 PM (UTC)
Message
Quote:

... will Lua enable you to achieve what most of the MC users would like to see - that is, configurable panes with multicolored text, and with dimensions that users can configure?


If I were to write a new client, that would be one of my objectives, yes - regardless of the scripting language.

Quote:

Additionally, will it be detrimental in any way to the existing MC feature set ...?


The new client would not attempt to be a clone of the existing one, however I would expect features that most people find useful to be present.

Quote:

... will you still able to configure new aliases/triggers/timers etc via the client itself in the same way the existing MC does ...?


Ease-of-use would be one of the important design principles.

Quote:

... some sort of import feature to convert existing trigger/alias etc files to the new client would be nice ...


Like I said before, it is hard to import existing things (except simple ones) without providing equivalent script routines to what is currently available. And do to that, the overall design has to be similar, so we are getting back to a clone then.



Just to clarify, I am toying with the idea of a cross-platform, cleaner, simpler client. One that is possibly written using wxWidgets, and has Lua (at least) for a scripting language. Possibly written using wxLua, so that the client itself is in Lua, so other people could modify it without having to download hundreds of megabytes of C++ compilers, and learn C++.

For existing huge scripts, I would stay with the existing client, which works perfectly well.

My objective is always to have code that runs fast - I grew up with PCs - if I can call them that - that ran at 1 Mhz and had 256 bytes of memory, so writing code that is compact and fast is pretty-well second nature to me.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #54 on Mon 27 Aug 2007 11:34 PM (UTC)
Message
All this reminds me of another thing I would LOVE to see, but figured it would be a large rewrite of what MUSHclient currently has. Currently, when you pop open the configuration windows, Your ability to send commands is killed, since the focus is set to the config menu. I would like to see the ability to cut/paste back and forth between config menus and the world window. This would also help when I need to make a somewhat involved trigger or alias while in a situation where I have to react to the mud fairly quickly. Granted, right now I can use the notepad to make an xml version, then cut/paste into the trigger menu, but I would like to just have the config menu set to alway floating on top.

Current benefit to non-Windows users... I can mark the configuration menu to exist on all window consoles of my X session, and flip through them to grab stuff off of the forums. For this reason, I wouldn't want the configuration menu to be forced to stay inside the client's main window panel.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #55 on Tue 28 Aug 2007 02:21 AM (UTC)

Amended on Tue 28 Aug 2007 02:23 AM (UTC) by Shadowfyr

Message
Quote:
Like I said before, it is hard to import existing things (except simple ones) without providing equivalent script routines to what is currently available. And do to that, the overall design has to be similar, so we are getting back to a clone then.


Well, yes and no. If the new one supported omit, but differently, then there is no reason it can't be converted. Custom colors, instead of pure HTML colors? Just have the conversion look up the custom color and "translate" to the HTML color for that. And so on. Short of completely removing a feature, to the extent that no analog at all exists, and the behavior once exhibited is now impossible, there is no reason, in principle, why nearly anything could be replicated, by conversion to the "new" method of doing it, and that includes functions in scripting. Fact is, while we have a lot of redundancy, some concepts that where poor to start with, since it took some arguing to point out why it was an incomplete or maybe less than usable solution, etc., there isn't anything in Mushclient I can imagine wanting to "lose", just stuff that needs to be reworked, so it is done more logically, and with less half-functional redundancy.

Mind you, in retyping this a few times, one things does occur to me. We where previously badly limited to how we could treat things like triggers. You where/are suggesting moving to something that does a lot of setting/reading info about worlds, etc., using "GetInfo". Imho, this is a bit silly, given we are trying to change to something that is "easier" to use. Why not a different approach:

a = world.settings.worldname
if exists world.triggers("mytrigger") then {
  this = gettrigger("mytrigger")
  this.forecolor = "blue"
  this = null
}


And stuff like that? Why use the clunky system that we where forced to deal with active scripts methods of dealing with things. It makes more sense, in an object driven system, to use methods that let you deal with the data in a way that makes sense from the viewpoint of the language(s). Mind you, it would require that all triggers are "named" so you can treat them as objects, which you can then reference, but.. Imho, it would make more sense than the currently screwball system we have, which has three methods for "making" a trigger, and at least three, maybe four, ways to change things in one, one of which is "manditory" if you don't want to just reimport the xml for one, but do want to change/set something that isn't supported in the other two methods of creating the thing in the first place. It wouldn't make much sense to do this in the existing client, but rewriting a new one, it wouldn't make much sense to "not" do it.
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #56 on Tue 28 Aug 2007 02:34 AM (UTC)
Message
Quote:
It makes more sense, in an object driven system, to use methods that let you deal with the data in a way that makes sense from the viewpoint of the language(s). Mind you, it would require that all triggers are "named" so you can treat them as objects, which you can then reference

I don't think that it would exactly require all triggers to be named, just the ones that you would want to access in the fashion you suggested. Very much like how it is now, where you can have unnamed triggers, but they are not as conveniently accessible to functions like SetTriggerOption as named functions are. Also, if the triggers and aliases and such were saved as Lua tables, it would still require each scripting language to have a function to access the data (even just translating the data types back and forth) similar to GetTriggerInfo and such. On a brighter note, if everything is stored as a string of some sort, a Lua metatable can convert everything as needed, and toss back error messages as appropriate.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #57 on Tue 28 Aug 2007 06:43 AM (UTC)
Message
If we can stop worrying about which script language is the "best", for a minute, it might be more interesting to think about: "What features in a new client would make it much easier to use?".

Here are some ideas:


  • Smart auto-completion

    Say, for example, you type:


    eat


    And maybe hit a key like <tab> or something. Now the client could know (somehow) what you can validly eat at this point (eg. something which is in your inventory, and can be eaten). Thus, a small menu could pop up from which you select the item to eat. A similar thing could be done for "cast" or "walk".

  • Smart "mouse-over"

    Say you have a database of mobs you have killed - you might mouse over a mob name in the output window and a small window pops up giving its known stats (eg. how hard to kill, what it usually has as loot).

  • Mini-map generated from exits list

    A small map could be generated (similar to SMAUG FUSS 1.8) which shows the current room and its exits, and maybe nearby rooms, based on recent "Exits" lines.

  • Plugins with dependencies

    Some plugins authors have written plugins which depend on other plugins being present. It would be nice if they could be auto-loaded.

  • Auto-load plugins in a directory

    Rather than having to load plugins manually, by simply placing them in a certain directory they could be loaded for any new worlds.


What I am trying to look at is a good reason for developing a new client, and "it must support everything the existing client does" is not really that reason. After all, the existing client does that.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #58 on Tue 28 Aug 2007 08:07 AM (UTC)
Message
Quote:
Smart auto-completion

Say, for example, you type:

eat

And maybe hit a key like <tab> or something. Now the client could know (somehow) what you can validly eat at this point (eg. something which is in your inventory, and can be eaten). Thus, a small menu could pop up from which you select the item to eat. A similar thing could be done for "cast" or "walk".


Seems to me that this would require some degree of cooperation with the MUD server. And I think that would be incredibly cool.

It would be a good opportunity to cook up a new extension protocol that focuses on text features, not "graphical" features (even frames fall into that category for me). It seems to me that the server should not be saying that it wants something in a frame -- you want the server to say what something is, and then you decide what you want to do with it.


Quote:
Smart "mouse-over"

Say you have a database of mobs you have killed - you might mouse over a mob name in the output window and a small window pops up giving its known stats (eg. how hard to kill, what it usually has as loot).

# Mini-map generated from exits list

A small map could be generated (similar to SMAUG FUSS 1.8) which shows the current room and its exits, and maybe nearby rooms, based on recent "Exits" lines.


Seems again that both of these would be easier with server cooperation.

Quote:
# Plugins with dependencies

Some plugins authors have written plugins which depend on other plugins being present. It would be nice if they could be auto-loaded.


While I don't use plugins too much myself, I think this sounds like a fine idea. You might want to look at LuaRocks, esp. if you plan on implementing this in Lua. There are some interesting issues with versioning and so forth that they're trying to deal with. (Unfortunately I believe the keyword is "trying", to a large extent.)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #59 on Tue 28 Aug 2007 08:52 AM (UTC)

Amended on Tue 28 Aug 2007 08:53 AM (UTC) by Shaun Biggs

Message
Quote:
Seems to me that this would require some degree of cooperation with the MUD server.

This can be done with minimal server input. I have a script I've made to track how many of various potions I have. I could easily modify this so that it would send a command to drink the most appropriate potion

Smart "mouse-over"
This would be a great thing to have as a user-controlled thing. I would love to have a mouse-over do various minor tasks if panels were put in. Possibly having 3 or 4 panels open, with the typing going to panel 1, unless the mouse is over panel 2, in which case all typing goes to panel 3. Odd example, I know, but it could have uses.

Mini-map generated from exits list
Having even a decent graphical mapper would be a huge boost for client use. Frequently I see people on the mud I play on ask about clients other than zMUD, and whenever another client is suggested, the first question is "Does it have a mapper?" Aside from Zugg's mapper, I can't really think of any that does a great job with it, especially one that's integrated within a client itself.

Plugins with dependencies
Could be useful. I just test to see if one plugin is active whenever another plugin is supposed to access it.

Auto-load plugins in a directory
This, to me, amounts to the same as having a list of plugins to load on startup. I can't really see the harm in including it.


Now for my own:
Password hiding
A friend of mine as over one day, and I logged in without using the popup password bit. My password was displayed on screen, and he commented on it being insecure. Although I changed my password (I trust the guy, but I always rotate my passwords anyway) and set MUSHclient to connect with a name and no password, I would like a way to prevent as many windows popping up as possible. Or even potentially use the same world for multiple characters. Might be a good idea to have an option to star out the second command entered.

Tree style alias/trigger display
An option to set up the trigger menu as a tree with the various groups as branches. It would help sort out things much better if I could collapse/expand them.

Multiple sort conditions for alias/trigger display
An ability to pick a primary, secondary, tertiary sorting field. That way you could do things like sort by sequence/group/label in that order.

Mouse over field gives info bubble
Toss in an option to make putting the mouse over a trigger's "match" field pop up a 'hint' with the full field in it. With limited screen space, it can get annoying to have a few really long triggers that all start identically. It's also aggravating to check the file path of a plugin.

Remeber last trigger/alias/timer
Have an accellerator able to pop up directly into the last trigger you were editing. Or keep track of the last trigger and leave it selected for the next time you open up the trigger window.
It is much easier to fight for one's ideals than to live up to them.
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.

370,941 views.

This is page 4, subject is 11 pages long:  [Previous page]  1  2  3  4 5  6  7  8  9  10  11  [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