Open Lucas-C opened 2 years ago
The clear
command is already implemented. Or are you talking about something else?
I'll take some time this weekend to look at your other links, but all your suggestions are nice. I'm not sure I'll have the time to implement them, since this is an old project and I'm quite busy right now, but I'll see what I can do.
Additionally, you can always make a PR, of course, you're already part of the project. As long as those features don't bloat or make the page heavy, it's ok.
The song game for instance takes quite a while to load, the idea of the terminal is to be there always ready for the players to access it and try to find things/find clues messing around the terminal, reading "emails" and "files". Making the application heavy and or slow doesn't really sounds like an improvement. Apart from that, more commands, "programs" and features are of course welcomed to the project.
About state management, are you thinking on using localStorage? Or are you talking about keeping the state only for the session?
The decrypt
command is nice, but I didn't understood the purpose of the block
command, as it wouldn't propagate to other users... Github pages are read-only (I mean static), any user blocked would work only in the client's browser.
If it's only for roleplay purposes though, it's fine.
For clear
, I wasn't clear: the command already exists indeed, I was suggesting to also add an option in software programs that would perform a clear before displaying the program output. I have just opened this PR in order to implement this: https://github.com/jacksonbenete/email_terminal/pull/10
By sharing those ideas here, I just want to know your feedbacks on them, and if you think they can fit with the project. I probably won't implement all of them myself, but I certainly do not expect you to implement them just because I thought they could be cool ^^
About audio / sound: I'm pretty sure it could be done without performance impact. And I agree that keeping the interface fast to load & fluid to use is very important.
Regarding state management, I initially thought that would be purely single-session-based, but using the browser LocalStorage
could be nice!
I got a couple extra ideas:
allow program to insert images in the terminal. It would be nice if players found visual clues by running programs...
persistant commands history stored in LocalStorage
.
I think I could actually give a shot at those 2 features...
By the way, are you still playing TTRPGs nowadays? 😊
You mentioned that you were busy: if you don't have the time or interest to deal with my ideas & PRs, I would fully understand. If you are ok to trust me a little, you could give me extra permissions on this repo, so that I can contribute stuff without notifying you. I could also simply work on a fork on my side.
Also, knowing myself, my interest in this project may vanish after a few weeks ^^ Especially if I don't find an occasion to use this in a TTRPG session soon!
Unfortunately I'm not playing anymore. I'm living in another country and my players are both distant and busy.
It's just normal to lose interest on something, so let's take advantage of your enthusiasm right now. haha I'll give you extra permissions so you can approve the PRs.
Thanks for giving me commit access to the repo!
Just to be clear: do you agree that I push commits to the master
branch without creating PRs?
I think I'll start with 2 features, and maybe I'll also add a Javascript code linter as part of GitHub Actions pipeline.
I wasn't very caring in the start of the project so I was committing directly to master
because I wasn't expecting the result to be good and to open source the thing.
I would suggest you to create branches and PR, as it'll be easy (for me) to follow what is going on, and it's a good practice for all of us.
But if you think it's too much trouble, I'll not be mad with commits directly to master
in a simple project like this one.
Ok, I'm totally fine with PRs 😊 Do you want to take the time to review all of them, or should I feel free to merge them after some time ? Tell me how many days I should wait if so
You can merge them whenever you want, no problem.
I'll just see the list of closed PRs later when I have the time, it'll be organised for me to follow the changes.
If it was directly on master
I would be a bit lost, even though the commit message should help.
Hi!
Those are just suggestions about features that could be interesting for the project:
[x] clear: a command and a software option that would discard all previous terminal lines - cf. #10
[x] allow program to insert images in the terminal. It would be nice if players found visual clues by running programs... - cf. #12
[x] persistant commands history stored in
LocalStorage
- cf. #13[x] include software programs in
help
: shouldn't thehelp
command list custom programs? - cf. #16[x] implement tab suggestion in
tabSuggestionHandler_
insrc/terminal.js
- cf. #16[x] Image glitch effect - cf. #17 & #26
[x] CSS text effects:
[x] state management in software programs: cf. #24
launch nukes
command that makes the whole page go "red alert", with some CSS effect ; anunlock cell#0
/unlock door#A
command that could virtually open some accesses in the secret complex, that could be displayed in ASCII with amap
command; ablock agent007
that could block (or unblock, asadmin
) a user from login in; adecrypt mail#3
command that would change the content of an email... I'm not sure this project needs to simulate a real filesystem, as you suggested in #6, as this feature could serve as a very good substitute.[x] prompts: software commands that expect input (like the
read
unix command). cf. #24 This could be used to make program that works as riddles: they ask for something, and they only reveal some extra information if the user provides the correct answer.[x] replace
telnet
+login
by assh
command[ ] sound effects. For example, I find the ones in thelab game terminal quite fun! The keyboard sounds logic is here
[ ] reduce the number of JSON files: loading many JSON files can be detrimental to performances. I think having a dedicated directory per server is nice, but maybe the content of
mailserver.json
,userlist.json
&manifest.json
could be merged into a singlemanifest.json
file? Also, maybe JSON files could be cached per session, so that useless HTTP call to retrieve the same file are avoided.What do you think about them @jacksonbenete?
Also, there are a few interesting web-based "fake" terminals to maybe draw inspiration from: