Up to Main Index Up to Journal for July, 2020 JOURNAL FOR SATURDAY 18TH JULY, 2020 ______________________________________________________________________________ SUBJECT: Respawn, in-flight events and duplication issues DATE: Sat 18 Jul 20:15:16 BST 2020 No update for a while and for that I apologise. I’ve not been feeling myself recently. Not exactly ill, but very lethargic and woolly headed — I spend all day feeling like I have just woken up — which makes programming very hard. I’ve been busy making the debugging of WolfMUD easier. The main reason being to tackle the current respawn, in-flight events and duplication issues. I’ve finished implementing my little tree graph drawing package and I’m quite happy with how it finally turned out. All of WolfMUD’s attributes have been updated to use the new text/tree package for their Dump methods. There is now a trio of dump commands. The #DUMP command produces an ASCII tree graph. The #UDUMP command draws the tree graph using nicer Unicode characters if your telnet client and terminal can support Unicode. Finally there is the #LDUMP command which writes the ASCII graph to the server’s log for later review. The Thing attribute has a new DumpToLog method so that you can easily drop something like t.DumpToLog("my label") in the code for easier logging of the state of a Thing. Some nice examples: >#DUMP LATTICE `- 0xc0000bd240 *attr.Thing - uid: #UID-E ("a curious brass lattice"), | collectable: false, attributes: 6 |- 0xc0000bd180 *attr.Name - "a curious brass lattice" |- 0xc0000bd1c0 *attr.Alias - aliases: 2 ["#UID-E", "LATTICE"], | qualifiers: 0 [] |- 0xc000183bc0 *attr.Reset - after: 10s, jitter: 10s, spawn: false | `- 0x0 event.Cancel - due: expired |- 0xc000098bd0 *attr.Vetoes - vetoes: 1 | `- 0xc00000db00 *attr.Veto - cmd: "JUNK", msg: "The lattice cannot be | junked." |- 0xc0000bd200 *attr.Description - "This is a finely crafted, intricate | lattice of fine brass wires forming a roughly ball shaped | curiosity." `- 0xc000183c80 *attr.Locate - origin: 0xc00004e4e0 "Fireplace", where: 0xc00004e4e0 "Fireplace" >#UDUMP LATTICE └─ 0xc0000bd240 *attr.Thing - uid: #UID-E ("a curious brass lattice"), │ collectable: false, attributes: 6 ├─ 0xc0000bd180 *attr.Name - "a curious brass lattice" ├─ 0xc0000bd1c0 *attr.Alias - aliases: 2 ["LATTICE", "#UID-E"], │ qualifiers: 0 [] ├─ 0xc000183bc0 *attr.Reset - after: 10s, jitter: 10s, spawn: false │ └─ 0x0 event.Cancel - due: expired ├─ 0xc000098bd0 *attr.Vetoes - vetoes: 1 │ └─ 0xc00000db00 *attr.Veto - cmd: "JUNK", msg: "The lattice cannot be │ junked." ├─ 0xc0000bd200 *attr.Description - "This is a finely crafted, intricate │ lattice of fine brass wires forming a roughly ball shaped │ curiosity." └─ 0xc000183c80 *attr.Locate - origin: 0xc00004e4e0 "Fireplace", where: 0xc00004e4e0 "Fireplace" >#LDUMP LATTICE > (meanwhile in the log we see…) Debug @ WolfMUD/src/code.wolfmud.org/WolfMUD.git/cmd/dump.go:85 ("#LDUMP") `- 0xc0000bd240 *attr.Thing - uid: #UID-E ("a curious brass lattice"), | collectable: false, attributes: 6 |- 0xc0000bd180 *attr.Name - "a curious brass lattice" |- 0xc0000bd1c0 *attr.Alias - aliases: 2 ["LATTICE", "#UID-E"], | qualifiers: 0 [] |- 0xc000183bc0 *attr.Reset - after: 10s, jitter: 10s, spawn: false | `- 0x0 event.Cancel - due: expired |- 0xc000098bd0 *attr.Vetoes - vetoes: 1 | `- 0xc00000db00 *attr.Veto - cmd: "JUNK", msg: "The lattice cannot be | junked." |- 0xc0000bd200 *attr.Description - "This is a finely crafted, intricate | lattice of fine brass wires forming a roughly ball shaped | curiosity." `- 0xc000183c80 *attr.Locate - origin: 0xc00004e4e0 "Fireplace", where: 0xc00004e4e0 "Fireplace" With the new debugging in place I’ve been tackling the respawn, in-flight events and duplication issues. I’ve implemented my three solutions detailed in my last journal entry[1]. However I’m still getting an odd nil panic, and I have no easy test case to reproduce it yet. Testing and debugging is therefore taking a long time — most of it spent waiting for the server to crash with just the right data logged. The server can run for a few minutes or hours before crashing. If it’s hours that’s a huge log to analyse looking for clues. Luckily I have my desktop, a Raspberry Pi 3 and a Raspberry Pi 4 all running the server code at the moment. In order to not wear out the SDCards with all of the logging everything is logged to the desktop. None of these changes have been released yet due to it all being a work in progress. I still need to work out how I’m going to release these fixes. At the moment I’ve got a hotfix branch created from v0.0.15 (commit: 5fd69de). I’m thinking I’ll have to create a v0.0.16 release and cherrypick everything into the current dev branch which is quite a ways ahead. I need to be careful not to break the public dev branch which is published — so rewriting history would be a very bad thing. I could revert the dev branch changes, apply these changes and then reapply the dev branch changes. I don’t think the dev branch is quite ready for prime time otherwise I could put the hotfix on the dev branch, release that and be done. The server has just fallen over, time to go analyse the logs and debug… -- Diddymus [1] Journal for Journal for Monday 29th June, 2020: ../6/29.html Up to Main Index Up to Journal for July, 2020