DESCRDBREF is not a direct replacement for CONDBREF about fuzzball

[wyld-sw]

You are absolutely right, this case (relying on traditional connection numbers in a loop) does need special handling with the new direction. We recommend using #-1 firstdescr and nextdescr to navigate the connections in a similar way.

@tanabi contributed a version of the 3who MUF that includes both techniques dependent on server version (the version in starters is just for fb7.1 at this point). Hopefully it helps, and please reach out if we can assist in getting you back up and running at full strength.

backward compatible 3who
7.1 release with modification notes

@tanabi, if I missed anything that would be helpful here, please let me know.

[tanabi]

@Sqrlly @wyld-sw Yeah -- the connection vs . descriptor thing in MUCKs has been a longstanding complication in both the guts of the server and in terms of MUF prims. For 7.1 we decided to make the breaking change to get rid of the connection stuff and thus simplify some things at the expense of making certain cases more complicated.

It is, however, pretty trivial to make backwards compatible code as you can see from our 3who example. It is probably possible to fix your macros to work with the new system. If you'd like me to help, I am super happy to do so, I just helped SPR out with ... actually one of your MUFs converting it to the new system (your @who program).

I am totally happy to take on whatever conversion work you need done to minimize the impact to you and your MUCK :)

[Sqrlly]

Yes my @who is one I'm working on too. I know how to rewrite it so it works with the descr's. I use them for lots of stuff like bootme and reconnect. But I hoped to keep all older programs compiling and working as-is without having to modify them, preferably. With condescr (and fixing the incorrect condbref macro) I was able to do that.

If not going to provide a function to convert con numbers to descr numbers, you may need to just remove all the con* macros as there's no way they're going to work, and might as well make the programs unable to compile and clearly show what isn't supported rather than getting strange runtime errors that will take time to figure out why.

And even one of the older mucks I support running fb 5.68 looks to be compatible with descr's. So can probably make the changes and still use it there too. Or I'll check for the version to be safe.

(Looks like I don't own my WHO program on SPR currently. Used to be a wizard there for a while. I suspect WHO doesn't need the W-bit though.)

[tanabi]

@Sqrlly The @who program does neeed a wiz bit because it looks up hosts :)

So I spoke it over with @wyld-sw and this is kind of a situation where you can't please everyone. I run a MUCK myself, and when I think of all the weeds that the 'con' prims are in ... I dunno, I think most cases, our internal macros to map the old CON* stuff to DESCR* stuff does a best-case attempt at compatibility. For the majority of programs, including random stuff like @bootme which are common but somewhat rarely used, our internal macros keep them running without crashing.

I'd, personally, rather have a couple weird edge cases (like 3who and your @who) bite me than connect to a MUCK with dozens of errors in all kinds of nooks and crannies that might take weeks to find them all.

Making changes like this is always pretty painful, but we do our best to minimize impact. Very sorry it has caused you grief though.

[Sqrlly]

Then I suggest just leaving CONDESCR in there for compatibility (remove the other con* ones as you have). And stuff like CONDBREF and CONHOST macros include CONDESCR before the DESCR replacement. That should then leave everything compatible like you want.

[tanabi]

@Sqrlly So you're proposing, basically, that CONDESCR would map a number to a number of hops on the descriptor linked list? That would enable a sequential number of calls which allows the old 0 to CONCOUNT style loop at the expense of being massively inefficient (we'd be navigating the descriptor list many, many times ... If I'm not mistaken, this is O(N^N) though I'm not great at my O's :) ).

I dunno, there's a relative minority of MUFs that use the old school loop architecture vs. MUFs that use random CON* prims in them to do assorted things. Most of the newer MUFs that do similar things use ONLINE_ARRAY from my surveying around. The conversion is really super easy to do, too. I think adding a bad implementation of a deprecated feature to avoid a few relative edge cases is probably not a good idea.

@wyld-sw I am pretty sure there's a descriptor hash table in addition to the linked list, but is there any way to use that to do a sequential mapping of 0 ... N connectors so we could do a CONDESCR without navigating the linked list? It's been awhile since I've looked at that sector of the code, I don't want to shoot something down only to find out later it was possible, because it's good idea if we can implement it reasonably.

[Sqrlly]

Well actually it's 1 to concount/descrcount. And CONDESCR already existed and worked fine. And yes, it mapped a connection number (1...N) to it's equiv descr number. That's all it did. You could look at how that was coded before it was taken out in fb7. That would be the only old 'con' function needed and the rest are already mapped over to their equiv descr* function. And a couple of in-server macros would need to be fixed.

And yes I also agree for writing new muf code or code you're already editing to use the new descr functions. Documentation for the old primitives can point people to the new ones. But for programs that already exist, rather than having them suddenly be broken (like happening here), that would allow simple compatibility for the older code. Not all mucks have coders with 30 years muf experience to track down the issue and recode stuff for them. :-)

[Sqrlly]

(Hrmm, I have at least a dozen references to con* functions in WHO alone... contime, conidle, condbref, condescr, conhost, conuser, concount... All broken other than maybe concount, across 400+ lines of code, 20+ user functions/words.. all going to have to be revamped because no easy fix...)

Oh I might have a way. A few helper functions, cd-first, cd-next, cd-valid defined differently based on muck version (con vs descr). But then when all the other stuff gets called like contime, conhost, it will act like there's a con number on the stack, but those running on fb7+ will actually have a descr number, and all those will work. Until you fix the macros as mentioned above. But I can deal with that and redefine them in program. :-)

Shoot. I have it working, but I don't. #-1 firstdescr / nextdescr lists the connections backwards, from longest ontime to least, which is the opposite of what's expected for WHO. Going to have to get more clever. Looked at the 3who, but it builds the whole list first and reverses it as it goes. Also doesn't look like it considers Dark players that shouldn't show nor be in the count for non-wizards using it. I might be able to use a hidden array in a variable.

And Success! Took me all night and 50-some extra lines of code, but works from fb5 (and probably older but that's all I had to test it on) to fb7 as it currently is. If we put condescr back and update the con* inserver macros I'll have to adjust it again, but that's fine.

[wyld-sw]

Maybe instead of #-1 FIRSTDESCR / NEXTDESCR, you can loop through: #-1 DESCR_ARRAY. I believe FIRSTDESCR/NEXTDESCR work like that (in apparent reverse) to simulate popping from the array.

We used #-1 FIRSTDESCR / NEXTDESCR when updating 3who because the existing logic needed to restructure the order for 3-column presentation anyway, so an array wouldn't help much with that logic.

Hopefully this allows less code for compatibility.

Thanks for mentioning that 3w doesn't respect Dark players. We can definitely look into that.

[Sqrlly]

Yeah I ended up using the DESCR_ARRAY for fb7+. Though can't use it for fb5 compatibility because arrays are introduced in fb6. FIRSTDESCR / NEXTDESCR was so close to using con numbers that had figured I could keep all the main logic the same but just slip descr numbers in instead. Of course replacing 1 + with a 'next' function.

I do still recommend restoring the CONDESCR primitive and fixing the other macros. Or removing all the con macros and let those programs using them fail to compile. @tanabi was worried about all the old programs using con breaking because of that, but they are already broken. None of the con macros besides concount will work without condescr in there. Because they're being passed a con number and you can't correctly call a descr function with a con number without converting it first.

And thanks for the help and input too. :-)