TrailMyx's Next Generation File System (TM_NGFS)

[TrailMyx]

I didn't think about that.  Lol.  No cruel joke, but the truth.  I'm almost done with a version for you to play with.  Not many people use this, but it's a great tool.

[TrailMyx]

Oh man, I totally forgot to post this.  Actually looking at the code I remember now why I didn't.  It's *almost* done.  Not quite, but almost.  Perhaps I can get it finished; I hate leaving this useful bit of code unreleased.

[Nylar]

Heh let me Necro this and ask the obvious question...

Did you ever 'Finish' it?

[TrailMyx]

Well the NGFS is finished.  The manager/viewer isn't quite yet.  I have the viewer a bit more functional,  but didn't quite get all the functions complete that I had envisioned.   I might post what I have so far as soon as I can go back and verify what works.

[Crisis]

That would be cool!

[Trigs]

Hey TM,

I've been playing with a handful of your file system based scripts lately, and think I noticed an issue across a few of them.

With the stuff you added for allowing "call" or "gosub" I think there is a mismatch in same variable names:

Code: [Select]

if !TM_FunctionCalled = #TRUE ; successfully called function.
  exit
if %0 = N/A
  display ok You may not run this script directly.
else
  display ok Function " , %1 , " not found.
stop

However, at the end of all the subs:

Code: [Select]

sub TM_NGFS_GetFSIndexVal
  namespace push
  namespace local TM_NGFS , _ , %1
  set #RESULT *TM_FS . %1
  namespace pop
  set !TM_Function_found #TRUE
return #RESULT

TM_Function_found  =/= TM_FunctionCalled

It's a simple enough fix I think, unless I'm missing some reason for them being different.


EDIT: As a second note - though I'm not sure if will accomplish anything, it seems that subsequent calls to this and the AFS both cause client crashes. It could be the way I'm using them but them seem to work fine 90% of the time. Often times when "loading" in either case it will just crash the UO client to desktop... it seems weird

I love the concept, the viewer is really nice and I have some ideas I'd love to implement using these features but having a hard time debugging the crashes

[TrailMyx]

I think you're right.  Gotta love when cut/paste goes wacky!  Looks like I just bolted on the call handler, so the easiest fix for that is to just change this:

Code: easyuo

1. if !TM_FunctionCalled = #TRUE ; successfully called function.
2.   exit
3. if %0 = N/A
4.   display ok You may not run this script directly.
5. else
6.   display ok Function " , %1 , " not found.
7. stop
8.  

to this:

Code: easyuo

1. if !TM_Function_found = #TRUE ; successfully called function.
2.   exit
3. if %0 = N/A
4.   display ok You may not run this script directly.
5. else
6.   display ok Function " , %1 , " not found.
7. stop
8.  

[Trigs]

I think you're right.  Gotta love when cut/paste goes wacky!  Looks like I just bolted on the call handler, so the easiest fix for that is to just change this:

Yea, that's what I ended up changing as well. I believe the same issue was present in TM_AdvancedFileSystem ( http://www.scriptuo.com/index.php?topic=22.0 )  I didn't check any others.

Any thoughts on the client crash?

Here's my use case:

Code: [Select]

call tm_ngfs.txt TM_NGFS_InitializeScript TrigBot

// some code to init
call tm_ngfs.txt TM_NGFS_RegisterVariables TrigBot std std scriptEndTime
call tm_ngfs.txt TM_NGFS_SaveVariables TrigBot

// bunch more code running script
call tm_ngfs.txt TM_NGFS_LoadVariables TrigBot // Crashes client here

I'm going to do a little more testing in isolation - I'll report back if I have a fully repeatable crash.

[TrailMyx]

Unsure about that.  Any script that heavily uses namespaces seems to be a little more susceptible to crashing.  It's kinda always been that way.

I normally get around many of the crashing by not using "call" at all and just importing the subs I need into my code.  Makes debugging easier also.