Open Seifert69 opened 3 years ago
In my opinion the editor (the www/ directory) should be in it's own repository. While it is indeed a part of this package, it's rather a beast of it's own.
I wasn't sure where to put this idea, if it belongs elsewhere, or just gone, let me know.
Worth discussing, but I’m going to disagree. Abstracting this particular project it’s effectively saying front-ends should be contained in their own repo separate from back-ends, which I completely disagree with. Coming back around to this particular project, I certainly understand that HTML and CSS feel alien to the rest of the MUD code, however even so I think it’s rather important to keep it there given the scale of impact on the overall project.
I think if we can find a good recommendation / example of how it could be built in the browser then it'll be easy to judge the scope and ultimately how to best integrate it into what we have.
PS. My previous comment was because I had not seen both posts
What about something in this direction?
This looks like an upgrade of the previous link
https://github.com/videsk/DynForms
Probably can't deal easily with arrays I suspect
I can see your point, and you aren't wrong, though I don't 100% agree. (But that's almost always the case, there can always be arguments made both fronts).
As for the front-end, it all depends on how deep you are willing to go on the mud end for advancement of the web. If the mud can pass a structure (maybe a data file storage of the necessary structures) then the web aspect will be pretty simple to build. You obviously do not want the web to be able to parse mud files.
Personally, I think there should be a secondary communications port for this web front-end. Simply for data transfer between the web and the mud, most likely a daemon.
Ive got a reasonable way og sending structured data to the client embedded in the HTML stream :-) I can make a JSON if you can make a form :-D
On Mon, Sep 28, 2020, 17:31 Thridi notifications@github.com wrote:
I can see your point, and you aren't wrong, though I don't 100% agree. (But that's almost always the case, there can always be arguments made both fronts).
As for the front-end, it all depends on how deep you are willing to go on the mud end for advancement of the web. If the mud can pass a structure (maybe a data file storage of the necessary structures) then the web aspect will be pretty simple to build. You obviously do not want the web to be able to parse mud files.
Personally, I think there should be a secondary communications port for this web front-end. Simply for data transfer between the web and the mud, most likely a daemon.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Seifert69/DikuMUD3/issues/64#issuecomment-700091087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOOMXSS3NFS4G5MDGYDCC3SICT63ANCNFSM4R3QY2XA .
I was planning on it! 👯
Cool. Then give me a little time and I'll do a basic sample. What format do you want? JSON?
And one more question. If I have a list of pick values with non sequential integers, how do you want that represented?
JSON works fine for me, extremely simple.
Can you give an example of the values?
I'll work on it. Wait a few days plz :)
On Mon, Sep 28, 2020, 19:00 Thridi notifications@github.com wrote:
JSON works fine for me, extremely simple.
Can you give an example of the values?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Seifert69/DikuMUD3/issues/64#issuecomment-700160018, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOOMXTZ3OFUZHIIRIKAVFTSIC6JXANCNFSM4R3QY2XA .
I did a quick sample of what base unit data could look like in JSON. My first JSON ever so bear with me if something should be done differently.
{ "idx": "cityguard@midgaard", "namelist": [ "city guard", "guard" ], "inside_descr": "", "outside_descr": "A City Guard wanders about here, trying to keep the peace.", "bright": 0, "wizi": 0, "manipulate" : 0, "flags" : 0, "hitpoints-max" : 100, "alignment" : 0, "keyname": "", "openflags" : 0, "opendiff" : 0, "baseweight" : 250, "capacity" : 0, "size" : 175, "extralist": [ {"namelist": [], "descr": "The guard looks strong and has a scar.", "values": []}, {"namelist": ["scar"], "descr": "The scar is pretty big.", "values": [1,2]}, ] }
"openflags", "flags" and "manipulate" are bitvectors. E.g. openflags can assume these values:
There's no drop-down selector here, but e.g. on the race of a NPC the final result is an integer, but a very small part of the list is here:
/Ants, beetles, butterflies,lobsters, shrimp, crabs,scorpions, spiders, ticks/
....
Not sure if you'd hard code these into the client? Guess we could also generate an include file somehow from the .h C files.
Please LMK what you'd like to see to be able to work with it.
The JSON structure you provided will work fine for me.
As long as i'm provided with the desired output and such, I can always code the mud parts easily enough. :D
I suppose I'll take the same format back to the server and validate it there? :)
On Mon, Sep 28, 2020 at 11:07 PM Thridi notifications@github.com wrote:
The JSON structure you provided will work fine for me.
As long as i'm provided with the desired output and such, I can always code the mud parts easily enough. :D
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Seifert69/DikuMUD3/issues/64#issuecomment-700281551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOOMXRTE3EKZ67KN2NQMUTSID3HHANCNFSM4R3QY2XA .
Absolutely, no data from the client should be assumed to be valid... which I know I am stating the obvious
How would you like text strings encoded (they can contain e.g. HTML characters, newlines, etc.) ? Base64? URLEncode?
Here's a programatically generated JSON example for web form editing. Not yet encoded until I hear if you have a preference. I removed the invalid line breaks by hand.
{ "idx": "temple@udgaard", "namelist": [], "title": "Temple of Udgaard", "inside_descr": " You are inside the small and humble village temple in Udgaard. A simple stone altar, with strange stone carvings, is placed against the north wall. A small humble donation room is to the east. The temple exit is south to the Village Square.", "outside_descr": "", "extralist": [ { "namelist": [ "stone altar", "altar" ], "descr": "The stone altar is very simple and engraved in it are a lots of strange symbols. Perhaps the symbols are worth examining.", "intlist": [] }, { "namelist": [ "symbols", "stone carvings", "carvings" ], "descr": "Some of the symbols clearly represents various Gods while other appear to be normal text. The symbols you do understand looks like this: Pray to odin if you are new and helpless.", "intlist": [] } ], "manipulate": 32768, "flags": 50160, "baseweight": 10, "capacity": 30000, "size": 180, "key": "", "openflags": 0, "opendiff": 0, "bright": 0, "minv": 0, "maxhp": 100, "hp": 100, "alignment": 0, "room": { "roomflags": 0, "movementtype": 0, "resistance": 0, "mapx": 424, "mapy": 420, "north": { "toroom": "heal_room@udgaard", "namelist": [], "difficulty": 0, "exitflags": 0, "key": "" }, "east": { "toroom": "udonate@udgaard", "namelist": [], "difficulty": 0, "exitflags": 0, "key": "" }, "south": { "toroom": "square@udgaard", "namelist": [], "difficulty": 0, "exitflags": 0, "key": "" } } }
I'm not sure they need to be encoded. If they are able to be json-encoded then it should be fine. Any loading/saving in the editor can be handled there, as either way they will need to be.
I'm quite certain it needs encoding :-) I'll look into it and will pick one. Guessing it primarily should be easy to deal with on the client side in JS to both encode and decode. So that'll be my priority :)
On Wed, Sep 30, 2020, 18:28 Thridi notifications@github.com wrote:
I'm not sure they need to be encoded. If they are able to be json-encoded then it should be fine. Any loading/saving in the editor can be handled there, as either way they will need to be.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Seifert69/DikuMUD3/issues/64#issuecomment-701501149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOOMXWV4VN65QUX2HVCSN3SINMD7ANCNFSM4R3QY2XA .
Figured out I primarily just need to transform newlines to \n. I'll get that done and hook it into the client one of these days :)
I pushed the latest so you can pull & compile & launch.
As immortal type:
wedit room
for example and the json data is sent to the client. I made a receiving function for you in the JS. And you can also see it in the console.log
LMK what you need plz :)
Not tested thoroughly ! I just realize I only tested that wedit room works :))
How do we plan on handling "access"? Is it going to be handled by the MUD or the client or a combination? I can send a username+password packet to the server and request a simple boolean return value to determine a valid user. I'm just not entirely sure the end-goal for the web editor. Is it direct integration with the mud or is it separated entirely? I can pretty much build whatever is wanted, I just need to be clear on what is wanted.
I imagined that you're logged into the mud and type " E.g. "wedit room". I'll check everything server side. So your challenge is to make a good form and send back the json.
We'll have to work together once you're to set e.g. sector type , capacity, etc. Especially object types and values are important. Or char races.
On Sun, Oct 4, 2020, 18:44 Thridi notifications@github.com wrote:
How do we plan on handling "access"? Is it going to be handled by the MUD or the client or a combination? I can send a username+password packet to the server and request a simple boolean return value to determine a valid user. I'm just not entirely sure the end-goal for the web editor. Is it direct integration with the mud or is it separated entirely? I can pretty much build whatever is wanted, I just need to be clear on what is wanted.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Seifert69/DikuMUD3/issues/64#issuecomment-703282467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOOMXR6I2PF7HKXUQ75S53SJCQ7ZANCNFSM4R3QY2XA .
The changes are now also live on test and production. Only full data for rooms so far, I didn't get around to objects and NPCs yet.
This is an extremely early draft of the editor so far.
Super nice! Looks clean and simple.
The IDX field is read only. Feel free to email me with questions on field types, drop down values, etx
I'm in the middle of moving. Next week I'll add data fields for objects and NPCs. :)
I'm wondering if there might be a good online editor for structured data. It could also be an editor that can be included as JS on the client. That's actually preferable.
For example to edit an object, NPC or room.
The editor preferably might be able to have a formatted input design. So we can configure how the data is entered.
Data exchange format can be anything, JSON, XML, etc