That shouldn’t be too hard, even with SH’s broken way of dealing with active elements (the non-appearing caret for example seems to indicate that) I would expect to have some sort of onfocus event that I can hook.
lua won’t be the problem, I’ll deal with that. In the very worst case, it’s proxy classes all the way. What is going to be a problem, however, will be to re-wire JS. But I haven’t touched JS input stuff in ages.
What tricky stuff is there for rewiring the JS? and do you think it’s worth it to add a fake caret? Since it’s totally possible to add one to all text inputs but it might be redundant as they could fix it soon.
I have no idea how JS goes on about event handling, but how do we prevent all the $(top).on('keyup') to be executed?
Depends heavily on the effort it takes to implement it and the “niceness” of the final implementation. I would not bet on a solution in the next update (and I would not expect the next update anytime soon either), so if there is a decent-effort-kind-of-clean way to do it, then yes. Please.
If you could ensure that your event handler when first than event.stopImmediatePropagation() would stop the rest from firing. This could be caused if you could ensure that your js is called first as handlers are called in the order they are added, otherwise look here. You’d need someway of controlling whether or not it stops it but between the two of those you should be able to stop all of them.
I’ll take a crack at adding a caret, I’ll start with the console as making it work on all inputs including ones that don’t exist always would be harder.
Controlling it is easy. It works really nice now, although I’m using bindFirst - I can’t modify radiant and since we’re loaded at god knows which point, it’s a safer bet.
Overloading the stuff on the client would work too if I wasn’t so stupid and had actually looked into the files first. I don’t (necessarily) need to mess around with capture_input, I need to mess around with key_down too. So that’s the next step.
Edit: Alright, pulled it off. Once the console input window is active, all other events are stopped. This includes client-sided stuff (is_key_down, capture_input with keyboard events) as well as any JS event. The result is an actually usable console. Yay.
I’ll tweak around a bit however, I don’t quite like the current minimizing code …
the effort you two are pouring into this is truly dizzying… and most appreciated! given than Houston is effectively shutdown today, i may have an opportunity to peek inside some of the code… i may even change some CSS!!!
fear my coding prowess!!
What? How do you want to do this without a new computer? 
very well… i shall refrain from enlightening the masses with my coding intellect…
now, if you need me, i’ll just be over here in the corner, weeping… quietly…
I’m playing around with the minimizing… I’ve brought down the code to a much cleaner variant which just uses five lines and lots of jQuery internal stuff. However, there are two things really bothering me that probably nobody would ever care for; those two being a glitch (the console/minimize button disappears very briefly when re-opening it…) and I have to adjust the background in order to avoid that it looks… “cut off”.
All in all, I’m really not satisfied about the way it looks right now, but I’m too tired to continue this for today. So, yes, rp.smod (required update; still needs zzz_rp.smod and -rp.smod from 2701) and rp_console.smod.
I think it’s heading into a nice direction, but as I’ve said… currently too tired/annoyed to figure out the last bits of the animation/CSS.
So I’m looking at the minimize code you’ve got and can see the cause for a couple of problems. For example the calc in the height for the lines area is what prevents it from resizing the height correctly. Resizing while it’s minimized is incredibly buggy and there is a few other things like why did you not like my icons?
So some thoughts on why you destroyed a lot of my working code for non working stuff just to add animation when that was really simple would be liked. Seriously adding animations to my version was just a matter of changing the resize commands to animate commands.
Err… It is working? It’s not exactly looking pretty right now, admittedly, but it is working.
Because that’s what Stonehearth does. I can’t recall where I read it, but the idea is to create a “smoother” user experience. Your code didn’t do that; it simply popped in/out (and I think the button didn’t stay at the same location either, but I could be mistaken).
Well that is fixable.
Because that should not be possible. I’ve said it’s a WIP, not a final version.
That was actually not done on purpose. To keep track of whether it is minimized or maximized (I don’t like attaching new attributes to HTML elements) in a very simple way I’ve just used text. Once the stuff is working and I’m saving the mini/maximizing state (and size) somewhere else they’ll come back.
Edit: Oooh, I see what you mean. Yes, this is totally my fault. $('#rpConsoleArea').height(500); should be $('#rpConsoleWindow').height(500); - then it works again.
I’ve changed that when I didn’t check resizing anymore, merely the minimizing/maximizing.
I played around with it a bit and what I did to track it was to add a minimized class to rpConsoleHeader. As for specific fixes.
I could pretty easily make a working animated version if you wanted, if you’ve already got it though I won’t bother.
Before I start answering your points, I’ve uploaded a new version of RP and rp_console. Both are required.
Changes:
Yepp. It was a mistake on my part, as I’ve said before; it was an experiment that had gone wrong. A logical flaw.
But after changing “#rpConsoleArea” to “#rpConsoleWindow” as written in my edit it works fine - even with 100% height. Or is there anything in this version now that goes wrong because of that?
Already fixed. However, not using a proprietary HTML attribute but rather a class.
If you can choose between destroy and disable, never pick destroy. Unless there are very good reasons to believe that you aren’t going to use this again (in a very long time), destroying may cause unnecessary overhead.
When minimized? I mean, when it isn’t, it’s meant to be scrollable. It does contain the log after all.
background-color: inherit; only works if the immediate parent has a background-color so you’ll have to put background-color: inherit; on rpConsoleArea or move the input out of it or it causes a visual bug. While minimized the gap between the text and the bottom of the box is too large, it’s possible to fix by using the maximise class to lower the header slightly. I feel like there was another thing as well but I’ve forgotten what it was.I tried some stuff with making a regex for the parsing and your code is buggy when using escaped quotes just before spaces in quoted segments or multiple spaces in a quoted segment. For example to output "Hello" Dave you should type """Hello"" Dave" which instead gives two args of "Hello" and Dave". This is because if you have an escaped quote just before a space it instead recognizes the escaped quote (but not the quote used to escape it) as an endquote. Something as simple as input of "1 2 3 4 5" will come up with args of 2, 3, 4, and 1 5. I’ve come up with something that should work in every case other than the ambiguous one (an even amount of quotes as an argument). It is
var args = argStr.match(/"(?:""|[^"])+"|(?:""|[^" ])+/g) // Capture all the args, include quotes for quoted args cause lookahead/behind wasn't working
.map(function(s){
return s.replace(/^"((?:"")*[^"])/g,'$1') // If they were a quoted arg temove the quotes
.replace(/([^"](?:"")*)"$/g,'$1') // Actually runs as checking for odd amounts of quotes at start or end
.replace(/""/g,'"') // Escape escaped quotes
});
If it doesn’t work tell me how it fails and I’ll fix it.
Ah, that’s what you are talking about. That was kind of on purpose, but I see that it’s obsolete since the input has a border anyway. I’ve adjusted it to 14px. 100% is not going to work; in an earlier attempt I was trying to simply hide the console area (instead of the whole console window) - I think the input clearly belongs to the console area, not the window per se.
No? With the current code, it’s copying the background color - or at least isn’t displaying any white. Removing it results in a white box. So I would say it does something.
What visual bug?
padding-top 7px, padding-bottom 9px and using the normal border.png seems to do the trick.
if (protoArg.substring(protoArg.length - 1) == '"' && protoArg.match(/("+)$/)[0].length % 2 == 1)
else if (concat != null) concat += ' ' + protoArg;
else if (concat == null && protoArg.substring(0, 1) == '"' && protoArg.match(/^("+)/)[0].length % 2 == 1)
Three little changes and the “bugs” (more missing features, or cases that I forgot) are fixed.
Your algorithm does something completely different, and edge cases are improperly interpreted. Although we could argue about whose implementation is actually broken, print "1 2 3 ""4"" "5" is interpreted as one argument in my implementation (1 2 3 "4" "5) but two in yours (1 2 3 "4" and 5). Your implementation is ignoring that whitespace is the delimiter (not quotes) and that a quote at the beginning of a token does not end said token.
In all honesty, I severely doubt that escaped quotes are going to happen that often to justify that amount of work.
Making it so quotes are only used to end a quoted segment if immediately before the end or a space is trivial even if I’m unsure about that rule. Change to .match(/"(?:""|"[^"]|[^"])+"|(?:""|"[^"]|[^" ])+/g).map(function(s){return s.replace(/ $/,'').replace(/^"((?:"")*[^"])/g,'$1').replace(/([^"](?:"")*)"$/g,'$1').replace(/""/g,'"')}) I feel like this one still fails but I can’t find it or I forgot I found it.
Also what is this?
else if (concat == null && protoArg.substring(0, 1) == ‘"’ && protoArg.match(/^("+)/)[0].length % 2 == 1)
It checks if strings start with an odd amount of quotes why? I said it was an ambiguous case because it was, for example take """". It’s impossible to tell whether they wanted a quoted arg of one escaped quote or an unqouted arg of two escaped quotes. Even worse if you account for the whole escapes only matter if used on a double quote immediately preceding a space or the end of the string.
On a positive note I’ve nearly got the caret/selection box working, the biggest problems I’ve had have been locating where they should go and detecting which end of the selection the caret is at. That last bit is particularly annoying as all js tells you is where the start and end is and not which end the caret is at. I do it via a data attribute but there’s probably a better way that doesn’t involve DOM manipulation but I wanted something that could be easily extend to all inputs like data- attributes can.
Alright, I give up, after consulting the Source engine, I suppose print "foo""bar" is to be taken equal to [ foo, bar ], """" is equal to [ , ] and eugh, I don’t think we really do need escaping after all.
I’m not 100% sure, but perhaps we should ask them to fix the problem or find a way on our own. The mouse wheel doesn’t work either, so I assume somehow the focus/input isn’t captured properly? Something like that?
It’s not necessary to have the fix for all possible inputs, however, in the worst case we’ll throw a function into RP that patches an input manually.
If you don’t care about escaping and quotes end quoted segments just use this .match(/"[^"]+"|[^" ]+/g).map(function(s){return s.replace(/"/g,'')Matches segments then strips all quotes so it’s risky that way. As I’ve said before though if you tell me what you want I can make it do it.
As for carets I have got a working one, there is a slight delay but it works fine and would be relatively trivial to make apply to all inputs I think. It’s just how the load event works that I’d need to test. Just insert the following function. I also couldn’t get jquery to make a proper css animation so it doesn’t blink.
EDIT:
I’ve now got a standalone mod to do it. It works on all input’s of type text so it will apply to the search box as well. It seems to sometimes cause visual artifacts and it fails if you enter text wider then the input and cause it to scroll. The download is caretor.smod.
Right, so I think I got over the worst part of the cold, so let’s continue where we left off.
I think replace(/^"(.*)"$/, "$1") might be a better approach. But to be completely fair, I think I’ll just leave the quotes stuff as it is right now. We’ve wasted too much time on it already and if the current implementation should prove faulty too we can always switch to your regexes.
About caretor.smod: I think if (rp && rp.log) is dangerous-ish. If rp is not defined, it will throw an error (I’m not sure if this is JS behaviour or some sort of strict thing that they’re using too). If you want to properly check for RP, you would need to check that typeof(rp) != 'undefined'.
Other than that, I think it’s nice what you’ve achieved - but it somehow isn’t usable for me, no offence. I tend to be an absolute perfectionist (especially when it comes to these kind of things) and the input lag (i.e. the caret moving just a fraction of a second too late) and the missing selection color are making me kind of… itchy. I’m a horrible Waldorf when it comes to that.