Zugg Software :: View topic

Adept Joined: 18 Jun 2019 Posts: 279

If anyone knows who the money-grabbing oik is tell him either let it go open or get off his fat arse and support the customers who paid full-price for an extremely old and broken product!

The potential exists for this software but it is half-arsed and released half-arsed by someone who appears to have all the arse. Documentation is a little beyond basic. There areas could definitely be improved and fixed.

...and, frankly, leaving ALL support in the hands of volunteers when you are too greedy to let someone else pick up the reins and too lazy to get off your fat arse to sort out the mess you made, is despicable. Sounds very 'Trumpian'.

here are some unhappy icons for those who enjoy such things.

Evil or Very Mad

Having to spend more time learning other scripting languages to use other clients - because those WORK and have been UPDATED - is laborious and disheartening.

Posted: Wed Mar 03, 2021 6:07 pm

The issue with it going open source is that he paid for a lot of coded plugins, so all of those would have to agree to go open source before he can.
It's a legal issue.

Adept Joined: 18 Jun 2019 Posts: 279

Or...those 'paid' plugins could be removed and alternatives coded back in.

I have been trying various alternatives.

AxMud: such a shame, it looks very comprehensive. However, I just CANNOT get the mapper working, despite there being (apparently) a pre-configured aardwolf setup (world). Development may or may not have stalled but the forums appear to completely devoid of life. New scripting technologies.

MudLet: The mapper is not as easy to automate as c/zMud. New scripting technologies.

MUSHClient: Works completely within aardwolf (probably others) and, if I connect to that MUD on Linux, I may opt to use it. ON windblows I am not a fan of the interface. That mapper works perfectly. Many plugins for being actively worked on for that client...and immense community support.

I decided to completely scrap everything and begin again. New maps, new scripts. I made new (empty) modules and added them one at a time to make sure nothing untoward happened.

All seemed to be fine. I had a aGMCP trigger looking for room.info*. Initially it was working. A simple thing. Then it stopped working. I tested it against an onRoomEnter event.

Event just sent "EVENT" to a window on entering a new room and GMCP sent GMCP to the same window. Event is appearing, GMCP not at all.

I ignored it and carried on as the EVENT was doing what I wanted.

I have a module for skills/abilities. It has a table of abilities populated via mud output. I then need extra values per ability for damage, primary stats, category, etc. These are picked up from the aardwold 'help'/ entries for each ability. My capture triggers/functions do ALL of this up to...

The triggers populate a record. The number of key/values varies.

HELP_RECORD data

<value>category=attack|syntax=cast|damage=water|primary="con|wis"|affects=luck</value>

At the end of the capture I tested output to a window. All fine BUT I cannot get the data out of this record under ANY circumstances. I can do command line #SH @helpREC and I get output but this data is NOT available from the script that asks for it. No matter how I tried to format the script I get no output.

$damage $category $syntax, etc are all blank. Yet the key names are being written because the logic is correct.

Apprentice Joined: 09 Apr 2008 Posts: 168

I get the frustration, and yes it does suck that it's not being developed or maintained short of it's dedicated user base...

Looking at your code sample, I think I understand the concept but one line has me boggled. I am a newb when it comes to a large portion of code and scripting... see well ALL of my posts for ref.

"$helpRec=@helpRec"

I fail to understand the need to write to a local var from a same named stored var. If it's the same data and not being over-written in the @helpRec before this code runs it's course then the singular call to write to $helpRec shouldn't be needed.
converting to calls for %db(@helpRec,whatever) instead.

again newd to code so this point escapes me. sorry if my lack of understanding frustrates you further.

Adept Joined: 18 Jun 2019 Posts: 279

I know, it is pointless . I tried that as a LAST resort test after every other regular combination. Usually, one would just do one of the following.

addkey newvar dbvar.key value
addkey newvar %dbvar(key,value) value

and it is also extra typing to internally assign things to local vars that only have one use. I wanted to expand as many points as possible to show if/when access was happening. However, in some cases it can help when someone wants to use the code with something already existing. If everything is localised as much as possible, making external changes has a minimal affect if one has to change (or trace) a bunch of var names.

It makes NO sense to me at all. What else makes no sense is that, although scripts work fine, I am having intermittent success with simple #SH/#SAY commands in these scrips writing to the main session window.

Sending data dumps to (non-existent) developers is a waste of effort.

Posted: Tue Mar 09, 2021 5:52 pm

Does the window trying to access the data have scope on the package that houses it?

Adept Joined: 18 Jun 2019 Posts: 279

I never played with the window settings, especially after the debacle of everything going tits up when I created a window in the package editor of a created package and tried to use that.

Are you suggesting that the package will require the main session to be checked in each package that wants have a #SH or #SAY that I want to output on the main session window?

Each package (package editor settings) has only itself checked and greyed out. Each window only has main session checked and greyed out. This is how it was when I created new packages. I have never played with those settings and every cmud command that displays text (say, echo, win, sh) had always worked without a problem. The main session has everything checked.