Okay, sorry for my absence! I started off trying to implement some new suggestions, then started trying to fix the new bugs that came up, and just ended up in a terrible mess that took much longer to sort out than I'd like. A lot of new bugs were introduced in V1.013 (and to a lesser extent, in V1.012 - like the compiler suddenly not highlighting errors any more). Remind me not to release new versions late at night in future...
Anyway, to business. Firstly, CS:
CS wrote:Do you think it might be possible to make file tabs (when you have multiple documents open) closable on double / middle click, just like in Firefox or Visual Studio?
Okay, this is done now - fortunately, it was one of the simpler changes.
CS wrote:From the same approach I think a 'compare scripts' function might be useful - that is, something like WinMerge, where you choose two files that will be displayed next to each other. Highlighting of differences would be awesome, but just having them on the screen right next to each other would be great.
I had to do a lot of this (though mostly looking at the codearray parts) when I was testing the compiler, so I agree that a comparator can be useful. I've introduced a relatively simple one that allows you to open another file to compare against the current script and highlight the differences in red. As I said though, it's not very sophisticated so the slightest difference is recognised. Also, it's a bit slow if you try to edit the code in the comparator (I've got something in mind to fix this though).
CS wrote:And one more convenience item: I'd like to be able to shift the dividing bar between the code and the command panes to the right, i.e. resize them in favor of the code view pane.
I thought this sounded like a good idea too. Therefore, I set about introducing the capability... and inadvertantly unleashed an army of problems which I've been battling ever since. To cut a long story short, you should now be able to resize the Script Editor part and even hide the Object List altogether if you want (via the View menu).
Unfortunately, the trade off for this seems to be that using Ctrl-Tab to switch forward through opened scripts no longer works (but oddly, Ctrl-Shift-Tab to cycle backwards still works). I have no idea why this is and I have been unable to work around it thus far.
Starcub wrote:However, I have a problem in that none of the script files in my \t directory are loading (the files in \script load fine).
As Enrico777 mentioned, the files in the "\t" directory aren't scripts (or at least shouldn't be, unless you've put some in there yourself). They're the language files that provide all the names of things etc. At some point I'll figure out a way of making sure that only script files can be opened but for now I'd just avoid opening those files.
bunkerprivate wrote:Bug: saving a file throws an uncaught exception.
Steps to reproduce: open a new file, attempt to save it anywhere; or open an existing file and attempt to save it under a different name.
This was because of the new script backup function I added - I forgot to check that the original file exists, so if you tried to save to a new file (rather than saving over an existing one) it would crash. Hopefully it's all fixed now.
bunkerprivate wrote:Bug: textfield snaps to the top after most operations
This one has plagued me for ages, and I still haven't thought of a good way to fix it. What I've done in this version is get it to snap back to the cursor location; this is better than looking at the top of the script each time, but unfortunately it usually puts the cursor right at the top of the window, which is still a bit disorientating.
The problem is caused by the incredibly ugly way I handle the syntax highlighting, which is basically to take the undecorated text from the box, add the RichText bits to it, and put it back in the box again, replacing everything that was there. Then I have to restore the cursor position but as you've noticed, this isn't the cleanest solution... If you have any bright ideas I'd be very grateful!
bunkerprivate wrote:Bug: saving with errors is not allowed
Details: I'm reporting this as a bug because it means I cannot backup my work as I go which could result in data loss.
This is actually intentional, would you believe it. My thinking is twofold: firstly, it (in theory) means that only valid script files are ever saved to disk, so X3 won't have any problems when it loads (dodgy script files can cause it to crash, as I discovered the hard way); secondly, I added in the save-to-txt capability for just this reason, so you can save a script as simple text without bothering the game or requiring a compile. You can then reopen the txt file and continue from where you left off.
Actually I could add in an autosave that works in this way - every five minutes, say, it would save a text file of the current script you're working on. Would that be useful, or is it a bit excessive?
bunkerprivate wrote:Bug: compile never finds referenced script files.
I almost wish I never introduced this capability, since it's never worked quite right!
You were quite right, it was always checking in the /scripts directory. I've hopefully fixed it now - it should check the location of the current script first and then the /scripts directory second.
bunkeprivate wrote:Bug: after compile, the indentation is lost.
Didn't realise I'd forgotten that - I got into the habit of compiling then saving separately, so I hadn't noticed. Anyway, fixed now.
bunkerprivate wrote:Bug: assignments are given extra values
Okay, there's good news and bad news here. The bad news is that this wasn't just a cosmetic problem - the compiler was somehow generating an extra (invalid) string on the end of any expression ending with a string. So any file you've saved like this will have this problem - it's not a loading problem. The good news is that it's fixed now, so if you cut off the extra string, it shouldn't come back.
bunkerprivate wrote:Bug: syntax colouring is wrong for literal array indices
Yeah, as you noticed I've put this in the manual. I use regular expressions for the syntax highlighting but I've not managed to quote perfect it; in this case it was a trade off between numbers being highlighted correctly, but highlighted everywhere
- in variable names, literals, and commands - or numbers being highlighted mostly in the right places but with the character to the left highlighted too. I chose the latter since it seemed less noticeable...
bunkerprivate wrote:Feature requests: - Warn for undeclared variables
Good idea. I've added this in now, so it will warn you if you try to use a variable before it's been assigned to. It might not be 100% perfect though, so we'll have to see.
bunkerprivate wrote:- Search function for expressions
- Descriptions for each expression (also searchable). Would be nice if you could also search the descriptions of other scripts.
I wasn't quite sure what you meant here - what do you mean by expressions in this context? And when you say descriptions of other scripts, can you be more specific?
bunkerprivate wrote:Please don't mistake my pedantry with ungratefulness; this is a whole lot better than the internal script editor! It's possible that if you open the source of your program, I might be able to help in a more meaningful way though actually I'm a C++ programmer and I only looked at windows.Forms long enough to go 'yuck' and get back to my Qt program
Not at all, you've been very helpful! Accurate & repeatable bug reports are worth their weight in gold. As for opening the source, I did consider putting it up on SourceForge or somewhere but frankly, the code is so embarrassingly awful in many places that I decided not to.
I started it partly as a way of learning the ins and outs of C# (since there's no better way to learn a language than to use it), since I too mostly use C++, but this was nearly two years ago and the older parts of the code are abysmal - and that's after
a complete rewrite at one point. Unfortunately, and as the number of bugs can attest, the interface is one of the oldest (and buggiest) parts of the program...
At some point, possibly to coincide with X3TC, I might try to overhaul the code (updating it to C# 3.0 at the same time, as it's much
nicer - it even has templates now). In which case I might well open the source at the same time, but we'll see how things go.
Note to self - the Initialise() function is not to be called more than once.
bunkerprivate wrote:Oh and for some reason, it seemed to open all my files again when I did the reload.
Okay, this should be fixed now...
Enrico777 wrote:I hope whimsy will come online soon to give you guys some feedback. He was very quick at fixing things lately.
Again, sorry for the delay! I have less spare time now than I did last week and these bugs/improvements took a lot longer than expected. Hopefully I haven't introduced quite as many bugs as I did with V1.013; my changelog entries are getting bigger
, not smaller, which is worrying! So I'd be very grateful if anyone has time to verify the changes to make sure I've not broken anything else, and thanks once again to all those who pointed out the new bugs.
Incidentally, V1.014 is here
. I'll update the main post next.