It is more a theoretical problem I guess than one that has any impact necessarily on game play since really I want to shuttle the room description to a separate window not do anything too complicated with it - still, it would feel cleaner.
Having the room VNUM key both variables but allowing a more descriptive room description variable that can be turned on and off seems like it might be worthwhile. If you were trying to link Room VNUM and Description from these 2 different sources, and the msdp.ROOM_DESCRIPTION updated immediately before msdp.CHARACTER_LOCATION updated - you could tie a description to invalid room vnum. ie, all the child properties are updated at once and a single event for the parent being updated is fired.īut if you had a second msdp variable like msdp.ROOM_DESCRIPTION you would have a separate event fire. My reason for wanting this redundancy is my current understanding of MSDP in Mudlet is that a variable like msdp.CHARACTER_LOCATION updates in a relatively atomic manner. You are right this would be partially redundant with CHARACTER_LOCATION in that both would contain room VNUM. I am aware of msdp.CHARACTER_ but I was thinking we could have something like MSDP only reports back info on the one your engaging - not to mention there is a brief second after a fight you can literally just walk out of the room while fighting other mobs. Another thing the mud does a bad job of is handling fighting multiple enemies. This is very annoying on EU, as something weird is up with the diseases there. I'm not sure it's disease in general or just slurrrr. Disease often crashes the affects variable to a null value - I suspect probably also a syntax issue. If I don't, typing look in a room gives me no room description at all. MXP is very bugged at the moment, I have to disable it. I don't think adding it to CHARACTER_LOCATION is ideal since a lot of the time I would want to turn it off to reduce data, but sometimes I want to read the room descriptions - such as when mapping or exploring an area.ĭoes your roomnvum request differ from msdp.CHARACTER_? cnl 40 Prime Poster Posts: 58 Joined: Wed 12:16 am Status: OfflineĬnl wrote:Feature request: MSDP variable that contains room description and roomnvum. I don't think adding it to CHARACTER_LOCATION is ideal since a lot of the time I would want to turn it off to reduce data, but sometimes I want to read the room descriptions - such as when mapping or exploring an area. (not a huge loss for most players though I'm betting)įeature request: MSDP variable that contains room description and roomnvum. Most variables/data you would get from MXP can be pulled out of MSDP, which works well in Mudlet, however you don't get the clickable links or menu links this way that you would with MXP. Players can disable MXP (can be toggled on/off in sloth by typing mxp). Sloth can switch to using temp secure mode ( [4z ), prefixing the individual MXP tags instead of flagging an entire block, maybe each terminated with [3z. Sloth can encode plain text ampersands inside lock secure MXP blocks as & Until terminated with [7z all loose "&" should be encoded as "&" - if I'm reading the spec docs correctly. I can't find a good authoritative resource on the MXP specification but I think this issue is at least partially on the SlothMUD side.
It is caused by the unescaped & (ampersand) chars in the list. There is a bug where Mudlet does not display store items on list command.
0 kommentar(er)
