 |
| kjaerhus |
Posted: Sat Nov 06, 2010 12:30 pm
Organizing packages |
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4692
Location: Pensacola, FL, USA
|
 Posted: Mon Nov 15, 2010 8:14 pm
|
If all the other extra windows are in the same package as the button, does the button still appear on them all?
Especially if its attached to just that window instead of sitting loose in the package? |
|
_________________
Discord: Shalimarwildcat |
 |
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Nov 15, 2010 8:29 pm
|
There is another option, Kjaerhus. In your package, create a new window, with the button defined in it. That button will not be visible to any other windows. The downside is that the button also will not be able to access any variables defined in other windows.
I personally don't see a problem with simply putting the button into a module. Every Cmud user should learn that buttons defined in modules can show up in any windows which have that package enabled. This is an important feature which allows users to define their own layout. You are trying to supercede the user's ability to define their own layout. I suppose some users would like that, but an awful lot would not. |
|
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Mon Nov 15, 2010 8:36 pm
|
| shalimar wrote: |
If all the other extra windows are in the same package as the button, does the button still appear on them all?
Especially if its attached to just that window instead of sitting loose in the package? |
I really can't get windows in packages to work in any way. It's hard to explain what goes wrong but it doesn't interact well with the windows of the session package. |
|
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Mon Nov 15, 2010 8:42 pm
|
| Rahab wrote: |
There is another option, Kjaerhus. In your package, create a new window, with the button defined in it. That button will not be visible to any other windows. The downside is that the button also will not be able to access any variables defined in other windows.
I personally don't see a problem with simply putting the button into a module. Every Cmud user should learn that buttons defined in modules can show up in any windows which have that package enabled. This is an important feature which allows users to define their own layout. You are trying to supercede the user's ability to define their own layout. I suppose some users would like that, but an awful lot would not. |
The thing is that I am not trying to make something for CMUD users but rather for people who would discard CMUD because it's too complicated. Actually I didn't think of locking the layout but just to define a default but now you say it it would probably be nice for many people if you protected them from themselves.  Perhaps your jaw just dropped to the floor and that was my intention too, but frankly what I mean is that I see good reasons to protect casual gamers from some of the complexity of CMUD. What you see as freedom of choice could be a nighmare for the player who accidentally got rid of an important window during battle or something. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Nov 15, 2010 10:43 pm
|
Windows within shared packages just isn't supported. This is planned in the future with the addition of zApp-like XML layout design for modular windows like you are talking about. So yes, this makes it difficult to create a truely standalone package that adds an additional window. It just means that you need to have some sort of "initialize package" command that creates the new window in the main session package and instructs the player to dock the new window as desired.
Edited: The main problem with what you are trying to do is that CMUD supports *all* MUDs and it's impossible to write a generic package to do the kinds of things you are talking about for all MUDs. CMUD isn't complicated...it's quite simple. It's creating a multi-windowed interface like your screenshot that would work on any MUD that would be complicated. That's why it only occurs in MUD-specific clients like StormFront.
In the past, there hasn't been any mechanism to send data between the client and server to support windows like you showed (inventory windows, etc). Now that we have GMCP and as more MUDs implement it, I could see trying to write some generic GMCP packages to do stuff like that. Once we start playing with that kind of functionality then it might make more sense for me to develop features for doing drag/drop and custom window manipulation. But until it is something that can be used on multiple MUDs, you won't see me add it to the core CMUD features.
But making "sub windows" for packages is definitely on the list for the future. |
|
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Mon Nov 15, 2010 11:14 pm
|
| Zugg wrote: |
Windows within shared packages just isn't supported. This is planned in the future with the addition of zApp-like XML layout design for modular windows like you are talking about. So yes, this makes it difficult to create a truely standalone package that adds an additional window. It just means that you need to have some sort of "initialize package" command that creates the new window in the main session package and instructs the player to dock the new window as desired.
Edited: The main problem with what you are trying to do is that CMUD supports *all* MUDs and it's impossible to write a generic package to do the kinds of things you are talking about for all MUDs. CMUD isn't complicated...it's quite simple. It's creating a multi-windowed interface like your screenshot that would work on any MUD that would be complicated. That's why it only occurs in MUD-specific clients like StormFront.
In the past, there hasn't been any mechanism to send data between the client and server to support windows like you showed (inventory windows, etc). Now that we have GMCP and as more MUDs implement it, I could see trying to write some generic GMCP packages to do stuff like that. Once we start playing with that kind of functionality then it might make more sense for me to develop features for doing drag/drop and custom window manipulation. But until it is something that can be used on multiple MUDs, you won't see me add it to the core CMUD features.
But making "sub windows" for packages is definitely on the list for the future. |
I can do without the fancy stuff like dragging around really. I mentioned StormFront as an example of a MUD-specific client but my intention was never to tailor CMUD to do exactly the same but more to give an idea about where I want to go.
And CMUD is not simple to non-technical users by the way and I know a lot of those. They just want to play their mud without too much distraction and thus prefers the more protected environments of those MUD-specific clients running scripts that are published on sites. |
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4692
Location: Pensacola, FL, USA
|
Posted: Mon Nov 15, 2010 11:55 pm
|
The main problem as you describe it, hitting all muds, is outside the scope of this one issue, which seems to be specifically for one MUD (or rather one company's MUDs).
No one is trying to make this package for ALL MUDs.
CMUD is simple, if you understand basic programming principles. That's a big #IF.
Other clients I have used in the past were not as easy to script in, so it is comparatively simple in its market as well.
GMCP is all well and good, but Simultronics uses the %gsl format and a rather hack'n'slash use of MXP/XML, and I don't see them changing things just to make third party client users happy. I could be wrong.
KJ is trying to make a single package with a locked layout that will be an opt in option to start with, as you have to DL from the package library to use it. |
|
_________________
Discord: Shalimarwildcat |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Nov 16, 2010 5:46 pm
|
| Quote: |
| And CMUD is not simple to non-technical users by the way |
Sure it is! You run it, you double-click your session icon, and you play. You don't need to know *anything* about programming to play a MUD using CMUD. I'm always really annoyed when people claim that CMUD is complicated. It's only complicated when you start trying to run scripts.
Now, if you are going to run scripts and you are a "non-technical" user, then you are going to get those scripts from somebody else, right? So in CMUD you click "Edit Session" and go to the Packages tab (because you want to add a "package" written by somebody else). Click the "Edit" button to edit the list of packages (which opens the Library). Select the name of your MUD from the list, select the package you want, then click Install.
Again, no programming knowledge needed. A nice Shared Library GUI.
If your friend sends you the *.PKG file instead, then you just save it to your MUD directory (path is shown in the Edit Session/Packages tab). Then in Edit Session/Packages you click the + button to add a new package and select the *.PKG file you saved from your friend.
Again, easy, no programming needed.
Only if your friend emails you the XML text of the script would you need to go into the Settings Editor and select Edit/Paste to paste it into your session.
People complain about CMUD being complicated, but *any* MUD client that allows scripting is complicated. Try doing Lua in MUSHclient...complicated for non-programmers. There isn't a single client that makes scripting "easy for non-technical users". At least CMUD has a Script Wizard now that helps non-technical people do simple stuff like color text sent from the MUD, or create simple aliases and macros to send commands to the MUD. Most clients do not have any wizard at all for that stuff.
Sorry to digress fro the main topic, but it just annoys me when people call CMUD complicated for non-technical users. It's the easiest-to-use client for non-technical users that is available. Except for maybe MUD-specific clients that can hard-code features for users for their MUD without scripting (which is what I know we are talking about here).
So yes, I understand that KJ is looking for creating a package to make CMUD easier for Simutronics games. And I've already said that such features are planned for the future. Till then you can't do complex window layouts in a shared package. And no, Simutronics is never going to get away from GSL and use MXP or GMCP. They don't want to play with the rest of the MUD community. I've tried to get them on board in the past and been burned by them. They want to live in their own world of paid and proprietary MUDs. |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Wed Nov 17, 2010 2:51 am
|
KJaerhus, to help with some ideas here's my code for creating windows in my package. I use an onLoad event for my package. It creates tab windows above the main session window using MXP.
Hopefully this will give you and others some ideas on how to do this. It's also why I had such a hard time understanding what you couldn't get done, since I was certain most things can be.
Without further ado, the code:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<module name="wintest" global="true" copy="yes">
<uid>{5B102A15-E54D-4CCE-ABCD-9D7A80AFB07C}</uid>
<event event="onLoad" priority="10" copy="yes">
<value>#IF (@firstRun == 1) {
$WindowList = "OOC|QA|IC|RL|Says|Direct"
$System="Core-System"
$pkgName="Company Issue - Chat"
#mxp
#IF (%window( $System)) {#CALL %packages( $System, $pkgName)}
#FORALL $WindowList {
#echo called %i
$window=%concat(%char(34),%i,%char(34))
#echo called $window
#MXP
//#CALL %packages( %i, $pkgName)
}
firstRun=false
}
</event>
</module>
</cmud> |
I create the first window aligned to the top of the main session window. I align all the other windows to the right of the first window to the top. I use one-time variable (to check see if it should be run), and note that it only runs if the variable is true. This handles the case of if the user deletes the variable. Hope this helps everyone.
Zugg, many moons ago, maybe even way back to the 2.x line, there was a bug I opened about the window layouts not saving after the windows were created with MXP. (It's actually why I tabled this project at the time.) The bug seems to have been fixed, as tested in CMUDPro 3.32.
[Edit] If I get enough requests I may put this and other code snippets into an Advanced Scripter's Cook Module for the documentation. |
|
_________________
Asati di tempari! |
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun Nov 21, 2010 2:51 pm
|
| Zugg wrote: |
| I'm always really annoyed when people claim that CMUD is complicated. It's only complicated when you start trying to run scripts. |
Don't be annoyed Zugg. I am not complaining about CMUD being complicated as I consider it a fact that will never change. If anything I complain about it not being easy to customize for non-technical users. Everyone wants to use scripts - without that you might as well use a standard telnet client really. Ok, that might be a little harsh but playing CMUD out-of-the-box is no fun at all.
But let's not talk about whether CMUD is complicated or not as it's not the point here. If you plan on opening CMUD for customization so that you could make full mud-specific mods then I can only encourage you to follow that plan as it would open CMUD for many new users. |
|
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun Nov 21, 2010 3:11 pm
|
Thanks for all the input, guys. I think for now I'll just stick to one package and then look to the future...
|
|
|
|
|
|
|
|
