Zugg Software :: View topic

Adept Joined: 18 Jun 2019 Posts: 279

Again with database problems...

I have a database of portals. Portals being level dependent, I have a record with

plev - portal level. The level at which the portal key can be used.
pname - portal name. The short name identifier for the portal.
pid - portal ID. The (mapper) room number.

So, I want to locate records with every level up.

Trigger goes like "You raise a level. You are now level x"

I have tried all sorts of things but I seem to be database dense.

I tried #LOOPVIEW with no success, #LOOPDB with similar results and #FIND but cannot seem to see anything that is working.

I tried a test with an alias that I was hoping would #UNPORTAL the existing portals.

The LOOPVIEW reference material goes:

#LOOPVIEW view {Commands}

with an example of:

#LOOPVIEW Weapons {#SHOW &Name,&Hit,&Dam}

So I tried:

#DBLOAD portals
#LOOPVIEW {#UNPORTAL &pname}
#DBCLOSE portals

Utter failure. What am I not seeing?

Adept Joined: 18 Jun 2019 Posts: 279

By the way, altering the script code (NOT YET SAVED) from #LOOPDB crashes the application. Even just deleting the 'B' from LOOPDB causes a crash.

Posted: Mon May 04, 2020 11:55 am

I would suggest using a database variable instead of the full database system, it has always given people issues.

Adept Joined: 18 Jun 2019 Posts: 279

But doesn't the variable access the records? Otherwise, not sure what you mean.

Posted: Thu May 07, 2020 11:48 am

Database variables are stored entirely inside the variable, which is inside your default CMUD .pkg file.
As opposed to being in a separate database file.

Let's pretend we have a portal called Swan Lake in room 8779 you can use at level 15.
To store this into the database we first need to create a record:

$this=Swan Lake
#ADDKEY $this ID 8779
#ADDKEY $this Level 15

Then you need to add that to your portal database Variable:

#ADDKEY portals {Swan Lake} $this

To access the data, I prefer to use the %db function, but you can also do dot notation:

$this=%db(@portals, "Swan Lake")
$ID=$this.ID
#SAY @portals."Swan Lake".Level

Adept Joined: 18 Jun 2019 Posts: 279

Re. further database use...

I finally managed to get scripts working to grab equip data into a database. Aardwolf mud doesn't make things easy with regard to pattern matching as item names may have non %a chars and also special character chars. It poses a real problem trying to come up with a pattern-matching expression to fit the bill. I tried using regex but it seems complicated to get working with cmud so I gave up.

As far as the database is concerned it works...for the most part. There are severe glitches in window handling that are unlikely to get fixed or even acknowledged which force me to crash out of the software. The number fields are ALL scrollable. Ie., they are not just plain fields with a number but have those windows up/down buttons OR - and this is the shit part - you can scroll the value up or down. Now, I have no idea WHY, as I am not actually in those fields, but one number field gets populated with an insane number from somewhere...and if you browse the database with the graphic tool it usually scrolls one of the number fields up or down and this f**ks up the original data.

If there was a developer who actually gave a shit about their software, this could have been fixed years ago. I'd post bug reports but no one cares and no one listens.

Can you not petition zugg to hand over the code to you and you guys can split the monies? It is pitiful that the price has not dropped but development has. This software costs more than Witcher 3 which has far more complexity in it and added content. Even No Man's Sky has dropped in price to less than cmud costs.

Adept Joined: 18 Jun 2019 Posts: 279

I am trying this but cannot see why it is not working. Am following documentation yet I see nothing in the %db var.

I have a VAR scorebashsk

CMUD reference states:

You can also use the syntax: #ADDKEY recordvar {field=key|field=key...} to assign more than one key at a time.

So I use:

#ADDKEY scorebashsk {name = "black root"|score = @blroot_tot}

and I have also tried it without the '=' with no success.

Yet scorebashsk is empty.

Posted: Fri May 22, 2020 10:54 am

This command is also working fine on my end.
As I said in the other thread, this is sounding more and more like a corruption issue.
If you are unwilling to take the steps needed to address that, I don't know what else to tell you.

Adept Joined: 18 Jun 2019 Posts: 279

In another thread I have already mentioned that I HAVE cleared my .pkg then imported all from XML.

Posted: Fri May 22, 2020 2:45 pm

Did this issue develop before or after that event?

Adept Joined: 18 Jun 2019 Posts: 279

Probably after.

There is more going on here (or not as the case may be). The #ADDKEY statement is in an 'onTick' event. I may be dumb as I am expecting this to be written every tick. To see if this is true...you guessed it...an #ECHO statement in the ontick event. However, nothing is being echo'd...anywhere. Thus the ontick is also not doing what it says on the tin.

Posted: Sun May 24, 2020 5:00 pm

Did you actually enable the timer on with #TIMER?

Adept Joined: 18 Jun 2019 Posts: 279

I did not. My (it seems) incorrect assumption was that the onTick event would collect a tick from the mud via a gmcp comm.tick { } method and fire at every tick (30 secs in this case).

If not, it seems I may have to manually charge every raise event for an onTick event. How is that efficient if I have to have timer commands to #raise ontick events a,b,c,d... x,y,z ?

Adept Joined: 18 Jun 2019 Posts: 279

Enabling the tick timer does fire the ECHO - annoying to have the "TICK IN 5 SECONDS" message with no documented way of removing that - but subsequent commands to write keys to a db record do not work. This does seem like a fundamental error in the cmud engine, if almost everything else works but this does not.

I saved an old equip database and to use that and saved it as a template. then deleted the old database and created a new one. The 'template' list remains empty despite the fact I made a new equip database file in the same directory as the template! Shoddy? I think so.

This entire database debacle, whether just using memory-stored record VARS or writing to a file is a f*cked-up pain in the arse which NEVER occurred with zmud but hey! it's progress, right?

I'd collect a bug report but we all know the only messages the original developer and his consort respond to are the ones where licences and payments are involved.

Even huge chunks of Solaris are now open source.

Can you tell I am unhappy about the taking of money, running and not giving a shit? Leaving the entire thing up to dedicated individuals such as yourself while still charging full tit is despicable.

FOR X = 1 to SHYSTER
printf("Zugg")

Furthermore, although the aforementioned zugg declares that this version of the software uses sqllite, any database created from within the game appears to be incompatible with any sqllite applications to render the structure or data. That facility is limited to the automatically created database files for a session. As far as I can see they follow no previously used or referenced format.