Brilliant Breakthroughs and Impossible Projects
-
@Griatch
There's a common piece of code on MU*s called 'places'. It's representative of locations in a room you can sit at as groups, like 'comfy couches that sit five' or 'corner booth that sits 4'. tabletalk is a command that emits to only the people at that location, like people stuffed into the booth having a private conversation, etc. -
@Bobotron said in Brilliant Breakthroughs and Impossible Projects:
@Griatch
There's a common piece of code on MU*s called 'places'. It's representative of locations in a room you can sit at as groups, like 'comfy couches that sit five' or 'corner booth that sits 4'. tabletalk is a command that emits to only the people at that location, like people stuffed into the booth having a private conversation, etc.Ah, I see. I've seen that feature under different names in different codebases. So how is the place implemented in mush? Somwthing like a property on an object in the room and when you sit by it you get a flag on yourself that the tabletalk command then checks to know who to send to?
-
@Griatch
Less flags and separate objects, and more attributes and lists of DBREFs. Using flags would be too intensive, since a room ideally can have multiple places, so it's easier to do attributes on a per-place basis and build around that. I recoded a version for Penn to update it to modern coding (since some functions are deprecated on Penn for the common versions) and it's mostly:- Attributes that represent the locations, how many people can sit at them, and store DBREFs of who are there
- Commands that use the attributes of the place you're set at.
So if you're set at Comfy Couches, and you tt I need some booze..., you'd get (at least on my version)...
- [Comfy Couches] Griatch says, "I need some booze."
Or if you pose, tt :picks up the glass and drains it in one go, slamming it on the table. "I want to get hammered." You'd get...
- [Comfy Couches] Griatch picks up the glass and drains it in one go, slamming it on the table. "I want to get hammered."
Only people at the place see the 'private conversation,' though people at the place also see the rest of the room as well (so a room with 10 people, 4 of them at a place, the people at the place see the things people in the main room are posing too). Code is set up to mimic emits as well, but it functions on a list of DBREFs and pemit() to those people. Extra code is set up to clean up the people sitting (like disconnects or people forgetting to leave the place).
-
@Bobotron said in Brilliant Breakthroughs and Impossible Projects:
@Griatch
Less flags and separate objects, and more attributes and lists of DBREFs. Using flags would be too intensive, since a room ideally can have multiple places, so it's easier to do attributes on a per-place basis and build around that. I recoded a version for Penn to update it to modern coding (since some functions are deprecated on Penn for the common versions) and it's mostly:- Attributes that represent the locations, how many people can sit at them, and store DBREFs of who are there
- Commands that use the attributes of the place you're set at.
So if you're set at Comfy Couches, and you tt I need some booze..., you'd get (at least on my version)...
- [Comfy Couches] Griatch says, "I need some booze."
Or if you pose, tt :picks up the glass and drains it in one go, slamming it on the table. "I want to get hammered." You'd get...
- [Comfy Couches] Griatch picks up the glass and drains it in one go, slamming it on the table. "I want to get hammered."
Only people at the place see the 'private conversation,' though people at the place also see the rest of the room as well (so a room with 10 people, 4 of them at a place, the people at the place see the things people in the main room are posing too). Code is set up to mimic emits as well, but it functions on a list of DBREFs and pemit() to those people. Extra code is set up to clean up the people sitting (like disconnects or people forgetting to leave the place).
This actually brings up some interesting scope. Should we cover in here what all the major differences in the major codebases (mush-ish) are and the pros and cons of them?
I noticed in other threads that some people say they prefer MUX because of X, or prefer Penn because of Y, or Rhost because of Z or maybe a dislike because of one or the other. Sometimes these opinions are based on viewpoints that have long been resolved or no longer an issue.
For example, I remember someone saying they didn't like Rhost because it was under an NDA, which it hasn't been under now for almost 8+ years. Or that Rhost was limited to 4K lbufs, which it can now handle upwards to 64K.
Some issues on MUX not able to handle regexp, and while there's some issues with this, their regexp package has grown significantly. Or Penn having some issues with the comsystem sucking, but recently they added a MUX/TM3 compatibility layer to their comsystem.
So, do you guys (and gals) think it's a good idea to just state things we wished codebase X had? Maybe you'll be lucky and someone can bring up that it does have that or offer alternatives.
I think this would be great for everyone and maybe help bridge some gaps between what is known, what is assumed, and what is not known
-
@Ashen-Shugar said in Brilliant Breakthroughs and Impossible Projects:
Should we cover in here what all the major differences in the major codebases (mush-ish) are and the pros and cons of them?
I wouldn't mind, but I think we should do that in a different thread.
Also, it was I who ran into the 4k Buffer Issue in Haunted Memories, or at least Loki coding around it for a softcoded logging system around the time that I was writing a softcoded logging system, etc.
-
For the longest time, I've had issues where I wish there was a way to save information to a database like SQL, in some known format, and be able to query it. I don't just mean 'just use SQL', but I mean advanced features like... 'related topics', etc.
I basically wanted Graph based storage. I tried using oqgraph, since MariaDB gives access to that, and with MariaDB being binary compatible with MySQL, I could use it. But it isn't well maintained, and it tended to crash things. So I dropped that. (Read: Don't use OQGraph for SQL Graph Storage, it's a trap!)
I recently actually started work on this anew, and in doing so fixed a bug in PennMUSH's SQL handling that enabled single-return Stored Procedures -- creating Graph based functions in SQL. However, SQL isn't really made for this... with enormous tables, this'll get slow. (Read: Stored Procedures for SQL Graph Storage is the best option at the moment)
It's roughly detailed here:
http://mush-mercutio.tumblr.com/post/153345784737/pennmush-graph-frameworkIf I finish this, I may at some point rewrite SceneSys to use this kind of storage, and launch some basic things along with it, like a basic BBS and a basic Jobs system as a POC.
Being reflected on the MUSH and on SQL, would allow easy grabbing through websites, etc.
