search

KSP-KOS / KSLib

The standard library and examples for the Kerboscript language
MIT License
120 stars 40 forks source link

Adds beep character to the spec_char #61

Closed abenkovskii closed 9 years ago

abenkovskii commented 9 years ago

I also compacted spec_char a bit using this information: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS.Safe/Compilation/CompiledObject-doc.md

abenkovskii commented 9 years ago

@benthor, if you are using TELNET this is for you.

benthor commented 9 years ago

very cool, thank you!

abenkovskii commented 9 years ago

@akrasuski1, could you please check out this?

akrasuski1 commented 9 years ago

I can't, because under Ubuntu, the terminal is set to not make any sound while printing '\a' character. Fixing this is quite a bit of hassle.

Either way, example file has two typos: TELENET -> TELNET here -> hear

abenkovskii commented 9 years ago

Thank you. Is everything else OK?

akrasuski1 commented 9 years ago

Yeah, though I did not check much - the endl and quote were already there, after all. So I didn't check the only thing introduced in this PR.

Dunbaratu commented 9 years ago

If you'd like, you can make an issue over in kOS for me to add a BEEP to the in-game GUI terminal that will respond to the existence of the 0x0007 unicode char on the output stream. Then this would work in both GUI terminal and TELNET terminal.

I was meaning to do it but I keep forgetting. Putting it in the issues list will help (there is an issue already but it's mangled up with other unrelated requests).

akrasuski1 commented 9 years ago

Sure - I just thought you were too busy doing short circuiting and dother things.

Dunbaratu commented 9 years ago

Just a warning as I started to look into the implementation of this, the current way the telnet system works, using the beep char from spec_char.ksm in a telnet will confuse the heck out of the telnet repainting system. This is because the kOS telnet repainting system doesn't realize the beep character doesn't really take a space on the screen. It gets put into the screen buffer as if it takes a spot, so if you printed print beep + "hi". the memory frame buffer THINKS your screen cells look like this:

+---+---+---+---+---+
| \a| h | i |   |   |
+---+---+---+---+---+

When they actually look like this:

+---+---+---+---+---+
| h | i |   |   |   |
+---+---+---+---+---+

(It doesn't know that the \a character doesn't really "print" and take up a cell.) This messes with the algorithm. I'm fixing it now in my new PR but this is just a warning that it doesn't quite work right as-is before I get that PR in.)

abenkovskii commented 9 years ago

Should it be merged to the master or to the develop branch? @akrasuski1, what do you think?

erendrake commented 9 years ago

I think it is good practice to always merge features into develop and then peroidacly merge develop into master. Just my 2 cents

abenkovskii commented 9 years ago

@erendrake Well... develop is supposed to follow the current kOS/develop state while master is a version for the current kOS release. In my view KSLib is not yet at that state of maturity when updating the main branch at the same rate the kOS releases is the right thing to do.

abenkovskii commented 9 years ago

@erendrake A problem with this PR is that the latest kOS release doesn't process a character 0x7 properly: https://github.com/KSP-KOS/KSLib/pull/61#issuecomment-104409720. That's why I think it should be in the develop branch.

erendrake commented 9 years ago

@abenkovskii i am sorry if i was unclear. i think that you should always merge new features into develop.

abenkovskii commented 9 years ago

@erendrake We need a version of KSLib compatible with the latest kOS release too. Do you think that the name "develop" is too ambiguous? May be it should me in a separate fork? The "next release" version gives us the ability to update the main KSLib to account for all breaking changes and new features as soon as the new kOS version releases.

TDW89 commented 9 years ago

Would the following branches make sense:

space-is-hard commented 9 years ago

@TDW89 Can we discuss your branch suggestions on Slack in a couple hours?

TDW89 commented 9 years ago

@space-is-hard i can stay round for a bit it has just gone midnight here so it will probably have to be a quick descussion