Jump to content

Mac Editor v1.0.8


Niemand

Recommended Posts

I heard that there's this big contest about to start, so I got all excited and decided to release a new (Macintosh) editor update.

 

As usual, you can download it from my Utilities Page.

 

Improvements in version 1.0.8 include:

  • The object selection system has been significantly revamped, so that a number of additional types can be selected, namely special encounter rectangles, area description rectangles, and town entrance rectangles. Any slected object can be removed using the delete key (obviating the need for certain special deletion modes/tools which existed before) and any selected object can be moved using Option+arrow keys. Selectable rectangles can now be redraw without being first deleted.
  • Sticky placement mode for stains and objects: hold shift and click the tool button for things like webs and blood stains to keep that placement tool active until you slect another. Great for where to need to distribute blood and slime liberally.
  • Command+arrow keys can now be used to navigate quickly among towns or outdoor sections. (Right and left are used for towns, all four directions are used outdoors.)
  • Automatically added floor frills will avoid the edges of towns which are set to repeat edge floors.
  • Changed the grid line spacing in the zoomed-out view mode to be powers of 2.
  • Fixed the beastly changing text-size bug for text areas.
  • Fixed the bug which caused clicks on buttons to sometimes be ignored.
  • Fixed some drawing bugs affecting buttons.
  • Internal image resources are now PNG files, rather than PICT resources. Slowly but steadily we crawl towards the 21st century.
As usual, I have neglected the Windows users. I hang my head in shame. Perhaps sometime in the near future I will figure out how to install the copy of Window 7 I have into a virtual machine and be able to actually do some real work on the Windows editor. In the meantime, it is recommended that you bribe me to try to speed up the process.
Link to comment
Share on other sites

I think I found a bug with the editor. Whenever you're trying to change the direction a selected creature is facing, if you click on the place at the bottom where it says "Facing:", it won't actually change the direction where it's facing. However, if you click there and then click on any of the buttons at the corners of the screen, or use the arrow keys to navigate around your town, the creature will change its direction the number of times you clicked before navigating.

Link to comment
Share on other sites

Faerie_Storm was having trouble with deleting (and selecting) town rectangles; I'm not sure if the problem was solved, but is there some special way to select them rather than just using the hand tool to click on them?

 

Also, how to resize the rectangles? You said that it can be done without first deleting them.

Link to comment
Share on other sites

@Duck: Good catch, there are some redrawing issues that I need to fix. (Not sure how that happened, as I never removed any of the redraw calls, but apparently I need to add some more.)

 

@Celtic Minstrel: Selection works as it always has: Shift+S or the hand tool. If there's a bug affecting some rectangles I'll need to know more details to pinpoint it and fix it. (At one point the first rectangle in a zone couldn't be selected, but one of my testers insisted that 'no rectangles could be selected', leading me to eventually give up and ignore his report; it was only later that I found out what I now think he was talking about.)

 

The rectangle resizing may not be as obvious as it should be (although virtually nothing in this editor is). With a rectangle selected one of the text item on the lower left should be '[Redraw]'. Click that and the usual rectangle defining mode will start; once you finish defining a rectangle the one you had selected will change to what you just drew.

Link to comment
Share on other sites

Actually, the above bug may not have been a bug at all; I just discovered that the Mac's "scroll lock" feature was active (this causes the numpad to move the cursor), so I suspect it was that which prevented numpad navigation from working.

 

(Whoever decided that it should be activated by pressing option five times in succession should be fired. With real fire.)

Link to comment
Share on other sites

Sorry about the delay.

 

Originally Posted By: Celtic Minstrel
For clarification, the hand tool for selecting rectangles doesn't seem to work even though I'm pretty sure we both have the same version... and it worked for me...

That doesn't, er, clarify very much. For whom does this not work and exactly what circumstances? What OS version? In a town, or outdoors? For all scenarios opened or just a specific one?

 

Originally Posted By: Celtic Minstrel
Another drawing bug... when selecting a terrain script, there's random pink stuff underneath it.

Okay, I've fixed this again, and I hope that this time it's really gone. (Believe me it was really bad before I fixed it the first time.)

 

I've also made the changes to fix the delayed redrawing, but I haven't yet uploaded the updated copy to my site, as I'm hoping to clear up what, if anything, is going on with the rectangle selection.

Link to comment
Share on other sites

That doesn't explain it, as I'm running 10.6.4 as well. The idea that everything would work for built-in scenarios but not custom made ones is very strange, and further more makes debugging more of a pain.

 

If you are now seeing problems, CM, would you be up for being a debugging guinea-pig? I can make a build with a bunch of logging, let you run it and try doing some things, and then send me the logs. This would be highly likely to take at least a couple of iterations. Just to be clear, the specific problem that you see is that with the selection tool active, when you click inside a special rectangle, the editor refuses to select it?

Link to comment
Share on other sites

Yes, that is essentially what is happening, and yes I'd be willing to test.

 

I can't vouch for it working with built-in scenarios but not custom scenarios, though, since I only tried with the two scenarios.

 

On a random unrelated note, is it possible to place pushable mirrors in the editor?

Link to comment
Share on other sites

Quote:
Yes, that is essentially what is happening, and yes I'd be willing to test.

Okay, I'll email you, hopefully later tonight.

Quote:
On a random unrelated note, is it possible to place pushable mirrors in the editor?

No, and it may not be possible at all: the editor communicates fields, objects, and stains to the game using the preset_field_type type which contains just a location and a short 'field_type', whose possible values, surprise surprise, are totally undocumented. A small amount of investigation into the sequence of values which are known (by virtue of being used explicitly in the editor code) makes me dubious that there are values which the game maps to the missing field and object types.
Link to comment
Share on other sites

Mirrors exist only in the town script, the Editor would have to be given the ability to read that script. After that you could have the Editor draw in appropriate graphics.

As a planning aid, you could create terrain types with mirror graphics, then place them where the mirrors are meant to go. Remove them after the town is designed.

Link to comment
Share on other sites

Quote:
Mirrors exist only in the town script, the Editor would have to be given the ability to read that script. After that you could have the Editor draw in appropriate graphics.

The statement that mirrors 'exist in the script' is, taken literally, not correct. The game has a grid for each of stains, objects, and fields in town. The scenario file, however, does not; instead it has space for 60 preset_field_type objects each of which can specify the type and location of a single field, object, or stain. Unfortunately, it appears that Jeff only assigned numeric codes for a subset of the generally available objects and fields. What you were getting at was correct, though, that the only way to create the remaining field and object types is with the appropriate script calls; this does not have to be done form the town script specifically, although this is usually the most sensible script to do the job.

Teaching the editor to parse and write town scripts would likely be absurdly hard to get completely right, although I suppose I do have tools that would almost do do the job. (Specifically, a script parser and AST representation, but not a script code writer, and while the AST is mutable, it isn't very well suited to such a task.) It would be a huge extension to the editor for very little payoff.

One thing that I do need to do at some point is check what the various other, never currently used, field_type values do, if anything. It may be that we get lucky and jeff has them all wired up but never used them. I'm just warning that this looks unlikely, and if it in fact isn't so that there isn't much we can practically do about it.
Link to comment
Share on other sites

Another note on the drawing/update bugs... when editing a terrain script, rectangle, or other selectable object, it seems that the updated value is not displayed below the terrain area until you reselect the object. For example, I place a terrain script, and it says that its script is "dummy"; I click on that to change it to "specobj", but it still says "dummy". Clicking on it reveals that it really is "specobj", and reselecting it of course updates it, but it'd be better to update it right away.

 

Originally Posted By: Niemand
A small amount of investigation into the sequence of values which are known (by virtue of being used explicitly in the editor code) makes me dubious that there are values which the game maps to the missing field and object types.
Well, might it be worth exploration?
Link to comment
Share on other sites

Quote:
Another note on the drawing/update bugs... when editing a terrain script, rectangle, or other selectable object, it seems that the updated value is not displayed below the terrain area until you reselect the object. For example, I place a terrain script, and it says that its script is "dummy"; I click on that to change it to "specobj", but it still says "dummy". Clicking on it reveals that it really is "specobj", and reselecting it of course updates it, but it'd be better to update it right away.

Already fixed, in the current development version.

Quote:
Well, might it be worth exploration?

I think it's worth at least trying, and I plan to do so.

Also, email sent.
Link to comment
Share on other sites

I think I've found more bugs, this time with Reload Scenario Data.

 

First of all, it sometimes doesn't seem to work after an error was encountered (such as a missing graphic or a syntax error). After a syntax error, attempting to reload the data again will cause the current scenario to be unloaded, forcing you to reopen it. As I recall, this usually occurs only after trying twice and failing.

 

Also, it doesn't detect default objects that have been modified and then "unmodified"; presumably because it takes the terrain, floors, etc in memory and parses the scenario's data script to modify them. Shouldn't it discard the terrains, floors, etc in memory, then parse the core data files followed by the scenario data file?

Link to comment
Share on other sites

Quote:
First of all, it sometimes doesn't seem to work after an error was encountered (such as a missing graphic or a syntax error). After a syntax error, attempting to reload the data again will cause the current scenario to be unloaded, forcing you to reopen it. As I recall, this usually occurs only after trying twice and failing.

To the best of my knowledge it has always unloaded the scenario after a single failed attempt. This is annoying, but somewhat necessary, since if any part of the load fails the editor has in general corrupted its only version of the definition data. This owes, obviously to storing all of the data in global variables and having the loading routines write to these variables directly. The correct approach would be to the loading into temporary structures and make the swap only when the load completes without error. This would be nice to have fixed, but it will be somewhat cumbersome, so it will be at least a little while until I get around to it.

Quote:
Shouldn't it discard the terrains, floors, etc in memory, then parse the core data files followed by the scenario data file?

It most certainly should, and I've made changes to hopefully bring this about. Said changes are present in the latest testing build (which I somehow suspect you'll get to peek at very soon).
Link to comment
Share on other sites

Yes, this happens because previously items were set as contained when placed on a container, but didn't necessarily change when moved to other spaces. Now, just about any time something happens with items or containers the editor scans through the whole town and sets every item to be contained or not, based on whether it's in a container right at that instant.

 

In order for what you're try to do to make any sense, you would need to make sure that the game actually know to do sensible things with an item that is contained even when no container is present, and that when a container becomes present it will properly notice the item which was already there. I assume that what you're looking for is something like having the item initially be inaccessible, then having a container appear to contain it.

 

In order to get what you want to work, we would both need to test that the game is actually capable of getting it right, and then alter the editor to be a lot smarter about setting item containment; basically it should automatically:

  • Set a new item to be contained if placed on a container
  • Set all the items on a space to be contained if a container is placed there (by any means, including some pesky ones like pasting a chunk of terrain)
  • Set all items on a space not to be contained if a container on that space is remove (again, including by cases like terrain pasting)
  • Set an item to not be contained if it is moved off of a space with a container to a space with no container
  • Set an item to be contained if it is moved onto of a space with a container from a space with no container

I think that covers it all; there are certainly a number of places that would have to be audited to make sure that they would carry out the above points correctly, but never touch items unnecessarily, to avoid destroying user settings without cause.

Link to comment
Share on other sites

Quote:
The Change Terrain Randomly is a place where a container or non-container would be placed; I'm not sure if you've covered that case.

I was assuming that this, the pencil, paintbrushes, spraycans, paintcan, and maybe autohills, along with anything else which can be found, would all fall under points 2 and 3.

Quote:
Anyway, how shall we test that the game will "get it right", as you put it?

My thought on doing this was to make a temporary build of the editor which lack all ability to automatically update item containment, and use it to produce a preset item like the one you want, then try manipulating it in the game to see how it behaves. Equivalently, one could hex-edit the scenario file to flip the correct bit for one item.

With regard to 'then try manipulating [the test item] in the game to see how it behaves', the things I would want to check are: Is the item visible and able to be picked up when lying out on the ground but marked (arguably incorrectly) as being contained, and, after changing the terrain under the item to a container, does the item behave like one which was in the container all along? If either of these tests results in something breaking weirdly in the game, we would need to retain the editor's enforcement that an item may not be contained outside a container. Otherwise, we would learn what strategies can be used to make this trick do something useful, such as whether the item can sit, invisibly, on its space waiting for the container to appear, or whether it should be hidden in a space inaccessible to the party and then moved into place at the same time the container is created.
Link to comment
Share on other sites

I can do the test, but it isn't high on my list of priorities, particularly since work is going to keep me very busy for the next week or so. So, if you don't do it, I will eventually, but it may not happen very soon.

 

If you want to do it entirely yourself, as it's not all that hard: You can check out a copy of the editor code from svn, comment out all calls to set_all_items_containment() (I think that's the function in question, and I think that doing this would be sufficient), run it, and mess around with item containment manually to your heart's content.

 

Alternatively, I could do the commenting out and send you another special build, which would let you perform the tests.

Link to comment
Share on other sites

If it's just the one function, you could comment out the function body instead. Less work! tongue

 

If you could do the commenting and send me a build right away, I could do the test tomorrow. After tomorrow, I'll be gone for a bit, so if you can't find the time to do it by then, don't bother. smile

Link to comment
Share on other sites

Tested, and the good news is it works! The item cannot be obtained while the space is not a contained; neither get nor search works. The item is also not visible. Once the space is changed to be a container, it can be searched to obtain the item.

 

One slightly odd effect is that you can search the object that has the item contained in it even though it is not searchable. (At least, I'm assuming Vahnatai stone table is not normally searchable.) But that's not a big deal, right?

Link to comment
Share on other sites

Quote:
Tested, and the good news is it works! The item cannot be obtained while the space is not a contained; neither get nor search works. The item is also not visible. Once the space is changed to be a container, it can be searched to obtain the item.

Excellent, this sounds like the best case of what I'd imagined.

Quote:
One slightly odd effect is that you can search the object that has the item contained in it even though it is not searchable. (At least, I'm assuming Vahnatai stone table is not normally searchable.) But that's not a big deal, right?

That's weird. So just to clarify: there's no way to tell that the item is there, but whatever terrain is on the space will be mysteriously searchable? I think that I could certainly live with that.

It looks like I'll be adding 'smarter containment handling' to my editor to-do list, then.
Link to comment
Share on other sites

Originally Posted By: Niemand
That's weird. So just to clarify: there's no way to tell that the item is there, but whatever terrain is on the space will be mysteriously searchable?
Precisely. So, I guess, don't put it on space you can walk through? (Actually, if you did, I bet you could get it by pushing a crate over the space... let me check that...)



EDIT: Yes, that is correct. If you make an item contained in a passable space, it is possible to obtain the item by pushing a crate over the space.
Link to comment
Share on other sites

  • 3 weeks later...
  • 3 months later...

Original post #209141 - Jun 29, 2010 11:08 PM Mac Editor v1.0.8, by Niemand

"•Sticky placement mode for stains and objects: hold shift and click the tool button for things like webs and blood stains to keep that placement tool active until you slect another. Great for where to need to distribute blood and slime liberally.

•Command+arrow keys can now be used to navigate quickly among towns or outdoor sections. (Right and left are used for towns, all four directions are used outdoors.)

•Changed the grid line spacing in the zoomed-out view mode to be powers of 2.

As usual, I have neglected the Windows users. I hang my head in shame. Perhaps sometime in the near future I will figure out how to install the copy of Window 7 I have into a virtual machine and be able to actually do some real work on the Windows editor. In the meantime, it is recommended that you bribe me to try to speed up the process."

- These were all done for the Windows version, some time ago. -

 

"•The object selection system has been significantly revamped, so that a number of additional types can be selected, namely special encounter rectangles, area description rectangles, and town entrance rectangles. Any slected object can be removed using the delete key (obviating the need for certain special deletion modes/tools which existed before) and any selected object can be moved using Option+arrow keys. Selectable rectangles can now be redraw without being first deleted."

- Now that I seem to have sorted out the horses and boats, this might be worth looking at for Windows. -

 

Original post #210481 - Jul 16, 2010 4:47 PM Re: Mac Editor v1.0.8 by Celtic Minstrel

"On a random unrelated note, is it possible to place pushable mirrors in the editor?"

- This problem was solved totally for the Windows editor. I hex edited the town record of a town in a Bas file. (The fields occur at offset 5,668, thereare 60 of them, each record takes 4 bytes so preset_field_type preset_fields[60] has a total length of 240 bytes.) Then I started the game, entered the relevant town and saw what fields corresponded to what numbers. This yielded the figure 2 for the oblique_mirror and 8 for the facing_mirror. The methodology should work for a Mac Editor, I would do it but I am not on a Mac. -

Edit:

I downloaded Niemand's source code, this may enable me to understand how things work with the fields. Hence I may be able to assist in the search for the method of placing the mirrors with the Editor.

 

Link to comment
Share on other sites

  • 2 weeks later...
Originally Posted By: Ishad Nha
- This problem was solved totally for the Windows editor. I hex edited the town record of a town in a Bas file. (The fields occur at offset 5,668, thereare 60 of them, each record takes 4 bytes so preset_field_type preset_fields[60] has a total length of 240 bytes.) Then I started the game, entered the relevant town and saw what fields corresponded to what numbers. This yielded the figure 2 for the oblique_mirror and 8 for the facing_mirror. The methodology should work for a Mac Editor, I would do it but I am not on a Mac. -
Did you figure out quickfire as well, by any chance?
Link to comment
Share on other sites

I doubt he has, and I doubt he will (although I'm still hopeful): all objects and stains are accounted for, but no fields. This kind of makes sense since (with the exception of quickfire) fields are ephemeral, so placing them ahead of time wouldn't do much; they would likely fade before the party would see them. Since quickfire is a special case though, maybe Jeff assigned it a code.

Link to comment
Share on other sites

  • 4 weeks later...

As a bit of a progress report: I've gotten mirror placing put into the Mac editor, mostly by directly copying the code from the Windows side. I also made a quick check myself of the first 32 preset field IDs, and it looks like there aren't any others assigned besides the ones we now know. While is possible that Jeff used one of the other value out of the full range of -2^31 to 2^31, I rather doubt he did it, and would suggest not bothering to hunt through all values exhaustively.

 

I've also got some more and less visible-to-users shiny things coming, namely automatic updates and a (32 bit) Intel-native build of the editor. I still need to do a little more testing, as there are some crashing bugs in the update process, and I've already found two data corruption bugs arising from endianness details, which leads me to be suspicious that more are lurking. Nonetheless, the new release should come soon.

Link to comment
Share on other sites

  • 4 weeks later...

I think you're looking at an old copy of the code; there's nothing like what you describe near that line in the ToT:

Code:
else{	current_terrain.info_rect[selected_object_number].right = // Line 1185	how_many_dlog(current_terrain.info_rect[selected_object_number].right,				  current_terrain.info_rect[selected_object_number].left,				  OUTDOOR_SIZE,"Set right boundary:");}

 

I made a quick search of that file and couldn't find any occurrences of current_terrain.exit_dests which seemed to be out of place, but if you can find the problem again in the latest revision, let me know.

 

(You may have to update your working copy later; my website seems to be down at the moment. Since the login page for the management panel is also down, I'm going to hope that this is general glitch which will be resolved without action by me.)

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...