Terrible Scripting Workflow. Worst Ever! Frustrating! Unusable!


#1

I realize these “new” windows are designed to be more VR friendly but who in their right mind is going to be scripting in VR anytime soon?

What happened to the old scripting window?

HMD Debug window (the only debug window I could find besides console megaspam) is completely useless since there is just too much spam to see any real info (always been this way) but you can’t even resize the window. At least before, you could run the script in the editor and see direct output rather than having to sift through spam (sometimes).

Also… the console does nothing now except state it is the console and offers you the ability to type in it. Useless for debugging if you can’t load a script into it. And… if you type some stuff in it, it freezes and you can never use it again without restarting the whole interface.

What needs to be done is the console needs to be able to load (and reload) scripts like it used to and needs to spit out useful debugging info. The HMD friendly stuff is too much of a hassle to bother with for scripting unless you are just wanting to test things (useless for debugging). Who wants to script for 20 hours with a HMD on?

Ideally we should be able to use an external scripting package that can connect to hifi interface/server for debugging and execution purposes.

This is very frustrating. Script debugging was a hassle already now its just 100 times worse. Maybe I am missing something. Maybe there is a perfectly intuitive workflow I am completely missing?


(yeah my hobby is making memes, lol).


The Open and Honest Content Provider Community Dialog Thread
#2

Yeah, its absolutely a night mare. I tend to simulate nearly everything outside of high fidelity so i can get things done.


#3

Did they remove the scripting window?
When did that happen?
Can it be added back in from the build?


#4

Notepad ++
it always works. :slight_smile:


#5

Can you show me how to run a script in notepad++ and get debug info?

I am not talking about script editors.


#6

Save… ftp… run in HF
I didn’t say it was to be faster.


#7

I didn’t say scripting was impossible. I said it’s a terrorfest. It was better 4 years ago than it is now.


#8

I have not been in HIFI for a very long time now why did they remove the scripting system?


#9

They didn’t remove scripting, they just removed the scripting window. Now it’s just a overlay window that barely works.


#10

There is still a pop-up log window with filtering. Available on the Developer menu. The HMD scripting log was added so that you could debug things will in VR mode… which at least for some of us… we do have to do.


#11

We did remove the “Script Editor” feature last March. This feature was only useful in debugging client only scripts, and we removed it for a couple reasons:

  • It was buggy, and the source of many of our crash reports
  • It wasn’t useful for debugging entity scripts or entity server scripts
  • It wasn’t possible to make it work in the HMD
  • It was unreliable in how it handled changes to the script and often resulted in confusing script state, which caused more harm than good.

#12

Yes it wasn’t perfect but it was a lot better than what we have now.

Really? Do a lot of people like scripting with a HMD? I doubt it.


#13

Maybe you can help me understand how you were using it?

Are you mostly working on client scripts? What are some examples of the types of scripts you built using the script editor? Did you use it as an “editor”? Why?

I understand that you think HMD rendering is not useful, but there are some debugging that can only be done in VR (specifically debugging things related to hand controllers and grabbing)…

We hear you loud and clear that we should not disable useful desktop features just because they don’t work in VR/HMD.


#14

Good thanks.

Yes, but there is really no reason you shouldn’t be able to work on AC scripts as well.

Almost everything I have worked on has been interface scripts that work with offsite API and/or websockets.

No, I am not a masochist. Although it would be nice to be able to load a script like we did before without having to use the gawdawful HMD script loading window and maybe even make minor code changes. In fact I think HiFi could use a decent IDE for scripting. I am kind of scratching my head wondering why it doesn’t (or at least provide a debug interface for external IDEs).


#15

So I’m still confused. I’ve reread your original post a couple times. Are you talking about the Pop Up Debug Log window? With a search filter? Because that window is still available. It’s on the developer menu.


#16

What are you confused about? Pretty much everybody agrees the scripting tools are wrecked. They were pretty bad before but even worse now. It was a bad decision somebody made to remove the desktop tools and replace them with “HMD” versions. Why not just fix the desktop version and have both?


#17

I think everyone agrees there’s lots of room for improvement, but there are a lot of UI elements related to scripts and some of your posts seem to be either unclear on what elements you’re talking about or possibly conflating elements.

The UI to load scripts is the ‘Running Scripts’ dialog. It’s still there, and seems to be pretty reasonable as a UI to browse for and find scripts, and then run them. It could use some polish in the tree view, but I think it’s otherwise reasonable.

There is the ‘Log Window’, which is one way of seeing script output, although you could also tail a log file in a console window, which is what I usually do to see script debugging logging, since I can pipe it through grep and the like.

There is the built-in Qt script debugger, which is something of a hidden feature. It allows you to actually step through a script and add breakpoints to it, as well as inspect values. It looks like this: http://doc.qt.io/qt-4.8/images/qtscript-debugger.png , However, this isn’t our tool, it’s something built-in to Qt’s QScript implementation, and it has a number of limitations, like it can only debug a script which is running on the main thread, so we have to load a script in a special way to debug it, which in turn can change the behavior of the script and in some cases cause a deadlock, since scripts normally expect to be running on a thread other than the main thread. Additionally, since QtScript is deprecated, this tool isn’t going to be getting any features or maintenance in the future.

There is also the old script editor, which had some limited functionality for editing and running or stopping scripts in the window itself, but no actual debugging functionality. This was removed quite a while back as ZappoMan describes.

Maybe you can clarify what part of the UI you’re talking about with a screenshot? We want to understand and help, since script developers are pretty critical to creating good content for our ecosystem.


#18

What I’m confused about is, I’m trying to understand your specific complaints so that I can either help identify workaround in the existing product (things that work) and so we can better understand what specific things are problematic so we can improve those things.

  • The old Script Editing window - I still don’t understand how it was useful. It didn’t have a real debugger, it was an editor but like you said only a masochist would use it as an editor, it had console like features.

  • The pop up log window - this is still available… and hasn’t changed in over a year. It is available on the Developer menu.

  • “Qt” Script Debugger - this is available as Austin describes, add #debug and debugger; to any script. This is a full fledged debugger with variable inspection, breakpoints, etc.

  • Entity Script Server Log - this is available on the developer menu, and it shows the logs from the entity scripts running on the server. It’s very similar to the pop up log window.

  • The Running Scripts window - you’ve expressed some frustration with this, but I’m not understanding what your complaint is… can you please give us something more to go on?


#19

I posted a screenshot in the first entry of this thread. The console spam is blurred out but it is irrelevant anyway.

For starters these HMD windows that seem to get used for everything don’t work very well on my system. Most of the time part of the windows are hidden off the edge of the screen, and the text is barely legible (see screenshot) and sometimes they show a pink background. These windows need to react to the main window size so this oversizing problem doesn’t happen. It feels very clunky trying to move them, too.

The HMD debug console shows a lot of irrelevant information from currently running scripts. Zappo mentioned another debug window but I haven’t been able to find it anywhere.

The scripting console isn’t usable at all. If I type something into it and hit return it just stop and does nothing. Closing it and opening it doesn’t reset it.

It seems the scripts you have to run to be able to use these HMD-friendly scripting helper windows eat up a lot of memory and take up too much window space. Making them resizable would be ideal, even though I am fully aware of the challenges of making dynamically-sized overlay windows (I made a JS windows library myself and avoided making them resizable too).

IMO the whole HMD windows system just comes off as a temporary placeholder because it feels very clunky and incomplete. I mean it’s still beta after all, but we are at a point in the beta where we really need content developers to start developing content. The frustration levels of these things have been adding up for me almost to the point of walking away from scripting entirely even though I have a lot of money wrapped up in this. It has definitely put a dent in my workflow even moreso than the old scripting tools.

Sure the HMD script tools are great for testing in VR, but that’s about all they are good for. They are pretty terrible if you absolutely don’t need to be testing in VR space. I guess some expert scripters might not have much of a problem with this since they are probably writing 100% bug free code but for the rest of us still learning and experimenting, having to deal with this stuff to figure out what is going on is a lot of work already without adding on the frustrations.


#20

One more thing… the controls on the overlay windows feel really laggy and not very responsive. Maybe this is what gives me the impression that these scripts are hogging memory or maybe they really are hogging memory, I don’t know.