Jump to content

Changing handling of Special Rectangles in the Editor


Niemand

Recommended Posts

As a result of discussion in the massive Windows Editor thread, I have been looking at altering the way special rectangles are manipulated in the editor. Currently, this can be done only by using the three tool modes with the odd, inherited-from-BoE, heavy dot icons. Contrast this with terrain scripts: one uses the 'Place Terrain Script' tool to create a script instance, and thereafter can select the script, change its properties and move it around.

 

What I've been experimenting with is making special rectangles selectable, in the same way as creatures, items, and terrain scripts. Then, changing properties can be done the same way as for the other selectable objects, by letting the user click on them and enter new values from the 'lower left text lines' (the various text displayed below the main view). In testing it already prove to be pretty convenient, and obviates the need for the 'Edit Special Encounter' tool. The next logical step is to eliminate the 'Erase Special Encounter' tool as well and just let the 'Delete an object' tool take over that job.

 

There are two major impediments that I see at the moment. First, I still need to figure out a god way to indicate which special rectangle is the current selection; for all other selectable objects (now including terrain scripts!) I do this by drawing an ugly but attention grabbing pink outline around them. I could do this for special rectangles as well, but I'm not sure how well it will work, since special rectangles already consist of a pair of lines, and while there are no pink rectangles currently used, color is already used to indicate different types of rectangles.

 

The second impediment is the way the object deletion tool currently works: It kills everything deletable on the selected space. When I found this it was not what I, as a user, expected, and I was slightly surprised that I hadn't stumbled across this before by having it delete things I didn't want deleted. This behavior looks like it would interact very badly with allowing special rectangles to be deleted by this tool, as clicking to delete an item or script which happened to be inside a special rectangle would destroy the rectangle as well, and clicking to delete a rectangle in a space that is also contained by another rectangle would cause both to be deleted. I didn't want to jump right into changing it without getting people's opinions, though, since it's a pretty critical tool. I propose altering this tool as follows: First, like the selection tool, only one object would be deleted. Second, the selected object, if there is one, would preferentially be deleted (if it is on the target space). Third (maybe, this idea is a bit shakier), objects which exist exclusively on the target space (items, creatures, scripts) would be favored for deletion over objects which span to other spaces (special rectangles), when this would not conflict with the second rule. I think that this set of rules would do a fairly good job of leading to 'least surprise' regarding the behavior of this tool.

 

Finally, I'm really beginning to think seriously about extending the undo system to encompass creating and deleting objects, and maybe also changing property values. This would take a lot of work, but would provide a good way to mitigate users' problems with the exact details of features like the deletion tool: if the tool deleted something other than what the user expected, he should be able to just hit 'Undo' and at least recover from it.

 

Thoughts, suggestions, or objections?

Link to comment
Share on other sites

Er... for the record, I'm totally fine with things the way they currently stand.

 

But if that's the way the rest of the community is moving with regards to special rectangles, then sure. Let's go ahead and make them selectable/movable. (And by extension, those changes to the deletion tool are quite reasonable)

 

Just please don't bother with numbering them.

Link to comment
Share on other sites

Quote:
Just please don't bother with numbering them.

Avoiding that was the original motivation for this. This way, if you want to know which state a given rectangle is attached to, you can select it and see, rather than having to use the edit tool or having extra numbers cluttering things up in the main view.

I implemented the highlighting, and decided that it doesn't look too bad. Here's what it looks like in action: http://misc.hallsofchaos.net/Special_Rectangle_Selection.png

I hadn't really been planning to add support for moving encounter rectangles around with the arrow keys, like the other selectable items, but it would be easy enough to do.
Link to comment
Share on other sites

My Backspace shortcut only deletes the selected object, just the thing for picking through a pile of items.

Special encounter numbers, I was going to print them on the screen but it did not work. I currently use color coded rectangles for this.

Your item numbers for selected rectangles could be 13,000 +. Terrain scripts are 9,000 + while items are 11,000 +.

Link to comment
Share on other sites

Originally Posted By: Niemand
The second impediment is the way the object deletion tool currently works: It kills everything deletable on the selected space. When I found this it was not what I, as a user, expected, and I was slightly surprised that I hadn't stumbled across this before by having it delete things I didn't want deleted. This behavior looks like it would interact very badly with allowing special rectangles to be deleted by this tool, as clicking to delete an item or script which happened to be inside a special rectangle would destroy the rectangle as well, and clicking to delete a rectangle in a space that is also contained by another rectangle would cause both to be deleted. I didn't want to jump right into changing it without getting people's opinions, though, since it's a pretty critical tool. I propose altering this tool as follows: First, like the selection tool, only one object would be deleted. Second, the selected object, if there is one, would preferentially be deleted (if it is on the target space). Third (maybe, this idea is a bit shakier), objects which exist exclusively on the target space (items, creatures, scripts) would be favored for deletion over objects which span to other spaces (special rectangles), when this would not conflict with the second rule. I think that this set of rules would do a fairly good job of leading to 'least surprise' regarding the behavior of this tool.
Why don't we just eliminate the "Delete an Object" tool as well, and use the Del or Delete/Backspace keys to delete selectable objects? (Unless some of the objects deleted by the Delete tool aren't selectable, of course...)
Link to comment
Share on other sites

Quote:
Why don't we just eliminate the "Delete an Object" tool as well, and use the Del or Delete/Backspace keys to delete selectable objects? (Unless some of the objects deleted by the Delete tool aren't selectable, of course...)

Imagine the sound of the heel of a hand meeting a forehead here. Yeah, this sounds like the right way to go. Good thing I hadn't yet wasted the time to do the tricky part of the overly complicated "Delete an Object" tool idea yet.
Link to comment
Share on other sites

  • 4 weeks later...

-BUMP-

 

I've gotten the changes implemented fully, I think, with the exception of any extension of the undo system (so use that delete key with care!).

 

If possible I'd like to get one or two people to give the latest build a try and make sure that things work consistently after the changes. (There's a lot of ugly spaghetti code that all had to be wired up just so, and I live in the perpetual fear that I may have missed some part of it.) Interested persons would need to be on Mac OS, since I haven't yet gotten to applying any of these ideas to the Windows version.

 

Also, as a step toward not really the future, but more like the present, the editor will no longer carry around its built-in graphics as PICT resources, but as modern PNG files. That still leaves a whole pile of other types of old style resources to be modernized, but it should be a move in the right direction.

Link to comment
Share on other sites

I'll help with the OS X testing for this.

 

Also, any word on existing bugs for the OS X version of the editor?

 

1. I don't know if this was ever changed, but you cannot copy text from outside the editor and paste it into the text boxes of the editor for the 3 introduction screens.

 

2. The cursor for the displayed text does not line up exactly with the actual position of the text.

 

Example: I have 255 characters, I place the cursor after the 20th character. However, if I add or delete a character the characters resize themselves on the screen and I find I've actually edited the 30th or so character...

Link to comment
Share on other sites

Originally Posted By: Dahak
1. I don't know if this was ever changed, but you cannot copy text from outside the editor and paste it into the text boxes of the editor for the 3 introduction screens.

2. The cursor for the displayed text does not line up exactly with the actual position of the text.

These, or at least the first, relate to the horrible, old (and deprecated) user interface libraries the program uses. I tried to fix them a while back and was forced to admit defeat. The first one I couldn't seem to do much about because components involved are basically black boxes with very few interfaces for additional manipulation. The second seems like it should be more tractable, since it is assumedly a drawing bug in the editor itself, but my attempts to correct it either accomplished nothing or rendered everything even more appallingly broken. I might take another shot at it, though.
Link to comment
Share on other sites

This is a matter that needs to be tackled fast.

In the meantime you can hex-edit. Enter "Intro 1" as the text for the first paragraph on the first Intro page, ditto "Intro page 1, paragraph 2" is the text for the next paragraph on page 1... Save the scenario and open it in an editor. Then see where the text for each paragraph is found, at the start of the bas file.

Link to comment
Share on other sites

Jubilation! I think I have finally vanquished bug #2 from above! It turned out that the way the bug worked was pretty subtle, as it had to do with the order in which items were drawn by Jeff's code and by the OS. The dumb part was that once I figured the details of that out, it required changing a single number in the source code (from 12 to 0) to fix it.

 

I've glanced a bit more at bug #1, and the problem isn't exactly that one can't copy and paste, just that the editor somehow has it's own, partially private pasteboard which is used. The rest of the system can see what's in the editor's pasteboard, so you can use copy-and-paste to get data out but the editor is somehow blind to data copied from other applications, so you can't get data in (despite that being the direction one is more likely to want to go). I have a bad feeling that this has to do with internally incompatibilities which have built up inside the OS which we run into by using libraries that Apple would really prefer to have people never look at again (the editor can't even be compiled except as a 32-bit PPC binary, despite the fact that I'm working on it on a 64-bit Intel machine).

 

@Dahak: I've sent you the latest version; thanks for taking a look at it.

Link to comment
Share on other sites

Oh yes, that bug is licked.

 

A question, is there a reason Jeff originally had 6 boxes? It is absolutely needed or can we have 1 window to type in and a running count of characters towards the max?

 

Also, as a future enhancement can we use the built-in Mac OS X spell-check functionality for intro screens?

Link to comment
Share on other sites

Quote:
A question, is there a reason Jeff originally had 6 boxes? It is absolutely needed or can we have 1 window to type in and a running count of characters towards the max?
Because, I suspect, he found that 6 255 character paragraphs would fit reasonably well on the game screen. And yes, it can't be altered without totally rewriting the editor's custom dialog engine; the portion of the ancient UI library it uses won't handle strings of more than 255 characters.

Quote:
Also, as a future enhancement can we use the built-in Mac OS X spell-check functionality for intro screens?
No. See remarks on horrible ancient libraries above.

The above problems, and a number of others, could be fixed by rewriting the editor to use more modern Carbon libraries or to use Cocoa, but that's a really big job, since a large fraction of the code would have to be thrown out; doing the job correctly would really involve starting essentially from scratch. I'm picking away at the edges of the problem, from time to time, trying to get pieces ready to move into position, but there's a lot to do, and I don't have time to attack it head on.
Link to comment
Share on other sites

The good thing about being able to paste into the intro dialog box is that you can write the string in a text editor before hand. Thus you can spell check and see how you are going for string length in each paragraph. Then when you are ready you can copy the string and paste it into the file.

Hex-editing is to be used only where necessary, it is a pill unless you are familiar with it. You may be able to paste a string of text into the file without the need to convert it into hex numbers, certainly this can be done on the Windows hex editor Hexplorer.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...