Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
As long as there's going to be a 1.0.9 update, I'm proposing the following small addition to the information in the pilotlog.txt file:
Contribute0: 0x002A01FF Contribute1: 0x80000001
That's it. Right now there's only some very clunky in-game methods for determining Contribute flag bit states. And those methods can only show one bit at a time instead of a pair of 32-bit hexadecimal representations. There's very little development usage of these powerful flag bits for a couple of reasons, the lack of a clean display of their current content for troubleshooting purposes is one. The not very meaningful checkbox matrix in the Novatools resource editors is another reason. I've edited my copy of the Novatools DITLs to change that checkbox layout to a bit-weight versus nybble matrix, so that problem's solved. But right now I'm using 64 mฤsn resources to test the Configure flags content during game play and it's very cumbersome to mentally reassemble the individual bits into their hexadecimal form.
I'm hoping that Mr. Burch can be convinced that this is a needed, meaningful, and probably very simple addition to implement.
Please ...and thank you very much in advance for at least considering the idea.
Do you think you can post those modified DITLs somewhere? It sounds quite useful. I wish I could hack things like that.
------------------ (url="http://"http://evula.org/macunderground/SWN/")Star Wars: Nova(/url) (url="http://"http://forums.evula.com/viewforum.php?f=23")SW:N Forums(/url)
That is an excellent idea. It'd make troubleshooting much easier for developers, especially if you use contribute/require extensively.
~ SP
------------------ Fear the SpacePirate, He made a (url="http://"http://www.evula.org/infernostudios/search.html")plug-in search page(/url)... And he'll board your ship! -mrxak *** (url="http://"http://www.evula.org/infernostudios/")InfernoStudios(/url) was last updated 06 June, 2004. ***
Yes, that can be added easily enough. Good suggestion.
mcb
------------------ "If it's not on fire, it's a software problem."
Echoboom: That's a simple matter of going into your ResEdit Preferences file with ResEdit and finding the DITLs with Contribute/Require checkbox sets. ResEdit has a very good built-in DITL editor, so it really is very simple.
On a side note, I have no idea what a bit-weight versus nybble matrix is, so could you at least post a screenshot?
EDIT: Typo.
------------------ The programmer's code of entomology: there's always another bug. There are 10 types of people in the world: those who understand binary and those who have friends. Windows users: stop asking for plugins. (url="http://"http://www.aznt.com/EVN/EVNEW/")Make one yourself.(/url) (url="http://"http://www.cwssoftware.com")Sephil Saga Website(/url) | (url="http://"http://www.evula.org/infernostudios/search.html")Add-ons Search Engine(/url)
(This message has been edited by orcaloverbri9 (edited 06-27-2004).)
Quote
Originally posted by Echoboom: **Do you think you can post those modified DITLs somewhere? **
I would need permission from the Sutherlands (Dr.Ralph & Roger) to do that. I will ask, but don't get your hopes up.
Originally posted by orcaloverbri9: **On a side note, I have no idea what a bit-weight versus nybble matrix is, so could you at least post a screenshot? **
A nybble is four bits, which is one hexadecimal digit. The bit-weights of those four bits are 1, 2, 4, and 8. So a bit-weight vs. nybble matrix has bit-weights represented on the ordinate axis in descending weights from top to bottom and nybbles represented across the abscissa with the most significant nybble leftmost.
Originally posted by Arturo: A nybble is four bits, which is one hexadecimal digit. The bit-weights of those four bits are 1, 2, 4, and 8. So a bit-weight vs. nybble matrix has bit-weights represented on the ordinate axis in descending weights from top to bottom and nybbles represented across the abscissa with the most significant nybble leftmost.
Hmm...sounds interesting. I'm starting to get an idea of what the hell you're saying. I almost understand...but if you have 4 bits by 1, 2, 4, and 8, wouldn't that mean only 16 checkboxes? If you could give me a screenshot of sorts, I would appreciate it, because the default Contribute/Require setup is kinda weird to me, too.
I'm not going to post any images of the modifications I've made to the Novatools editors until I get permission from the Sutherlands, which may, or may not come to pass. I can however provide you with a textual representation that should not step on anyones copyright toes.
Each 32-bit hexadecimal number contains 8 nybbles. The matrix layout is such that the 4 bits for each nybble are arrayed underneath the respective hex digit. These textual examples should make it clearer:
hexadecimal= 0x76543210 matrix= 8..OOOOOOOO 4..XXXXOOOO 2..XXOOXXOO 1..XOXOXOXO
and...
hexadecimal= 0xFEDCBA98 matrix= 8..XXXXXXXX 4..XXXXOOOO 2..XXOOXXOO 1..XOXOXOXO
hexadecimal= 0x12488421 matrix= 8..OOOXXOOO 4..OOXOOXOO 2..OXOOOOXO 1..XOOOOOOX
(edit: gud spelers untie)
(This message has been edited by Arturo (edited 06-28-2004).)
Ah, okay...so you have two of those next to each other for the 64 bit flag. Cool. It makes more sense to me to have the left be the first number from left to right rather than the last. That must have been some annoying rearranging.
Anyway, I now understand the concept. Thanks!
I defined the word "tedious" while I was rearranging (count 'em) 576 checkboxes. In some resources I've arranged the two 32-bit matrices side-by-side and in others I used an over-and-under layout. On the other hand, the ordering of the nybbles is based not on my personal preference, but rather on the HLNG ordering used both in the Nova resource templates and in the ConText utility dumps of the Contribute-Require 32-bit hexadecimal numbers.
Hmm...I can't get ResEdit to work quite properly with my modified rรคnk resource DITL. I'll see if it makes a difference whether you're using the Classic environment under OS X or if you're running standalone 9.
Originally posted by orcaloverbri9: **Hmm...I can't get ResEdit to work quite properly with my modified rรคnk resource DITL. I'll see if it makes a difference whether you're using the Classic environment under OS X or if you're running standalone 9. **
If you deleted anything from the DITL and even if you put something you deleted back in, you've corrupted the linkages between the DITL and the RSSC resources. Also don't use the "Renumber items..." from the DITL menu as that will cause the same problem. Other than that it boils down to ... "I hope you made a backup".
Originally posted by Arturo: If you deleted anything from the DITL and even if you put something you deleted back in, you've corrupted the linkages between the DITL and the RSSC resources. Also don't use the "Renumber items..." from the DITL menu as that will cause the same problem. Other than that it boils down to ... "I hope you made a backup".
Dammit. I think I deleted some of the labels (A, B, C, D, E, F, G, H, 1, 2, 3, 4, 5, 6, 7, 8).
There's a "Renumber items..."? But can't I just, say, delete a checkbox, then make a new one and renumber it to the same number?
Originally posted by orcaloverbri9: **But can't I just, say, delete a checkbox, then make a new one and renumber it to the same number? **
Here's how it works. All of the items in the DITL (stands for Dialog ITem List by the way) have an item number (press the option key to see them). Those item numbers are used by the actual editor software code that's in the associated RSSC resource. When you delete any item, it's number becomes available and the simple minded DITL editor doesn't just remove that one deleted item's number, instead it immediately does an automatic renumber of ALL the items (can't be stopped). However that renumbering does not alter the RSSC code in any way (can't), so the RSSC code is now pointing at all the wrong items because all of the numbers have been shuffled. That's what I wrote before, deleting or renumbering immediately causes a corruption of the item number linkage between the DITL and the RSSC. Believe me, I know whereof I type, because I have made that error in the past.
You could of course record the item number of everything before you start editing, and then check that all the numbers are correct before saving the DITL, but that's a lot of note-taking to do. The easier method for saving yourself is to follow a practice of - a) always making a backup before every editing session; and never delete any of the original items. My personal preference, since I've been doing beaucoup DITL editing lately, is to make daily backups with a date suffix added to the backup's filename. That way I can only lose one days worth of work if I really screw up, but I rarely make the same mistake twice.
Oh, and of course never edit the ResEdit Preferences file that's being used by ResEdit, always work on a copy, quit ResEdit, then copy that working-copy into your preferences folder. I'm going to be posting a DITL editing tutorial thread, with images of examples, as soon as I'm done putting the finishing touches on the Novatools update that I'll be posting to the addons. Should only be a few more days.
Originally posted by Arturo: < snip>
Oh, I see. So what does it do to the other item(s)'(s) number(s)?