Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: FredSRichardson
« on: August 24, 2007, 06:36:11 PM »

I'll cross post some of the IESDP conflicts over at the IESDP forum.  I know they just updated the docs, so perhaps they'd like a chance to straighten some of these things out.
Posted by: devSin
« on: August 23, 2007, 10:58:42 PM »

Unless it's a major structure change, I wouldn't worry about it. The labels can be changed whenever if some other text is deemed clearer. Almost all of the field changes came after exhaustive testing of the behavior. The giant string arrays were formatted so that everything would fit in my 80-char width text editor. I needed to actually be able to see the values. ;) None of them should be pure formatting outside EffectFactory (they were reformatted after I made a real change). Tutu and the demo support is all from Jon. I don't like Tutu and didn't even spend a second thinking about it. The "Is missile?" flag can stay (I guess it depends if you think all projectiles, including arrows and bolts, are missiles; I do, which is why I made the change).

As for some of the other changes: Jon broke CHR to CRE conversion, and I didn't fix it (still disabled); I added support for projectile trap headers in ARE files, but not for recognizing the effects list (the Mac version of ToB doesn't store this correctly, so it would just cause a bunch of useless errors for saved AREs); I didn't add support for Pocket Plane location structures because the Mac stores the offset big endian; I made two tiny changes so that trying to edit and save AbstractStruct data would fail less spectacularly (it still doesn't work correctly, but better than the original source); probably a bunch of other stuff I forgot.
Posted by: FredSRichardson
« on: August 23, 2007, 04:25:26 PM »

Here are my notes on DevSin's changes.  Some of them may come from Jon Olav (i.e. the original code) and not DevSin.  These comments are certainly no meant to sound critical!  I've actually contributed very little in comparison to what DevSin's done with the code (and I think their are other contributers out there who have done a lot, I'll try to get those changes into the code as well).

I don't think I've been complete here by any means.  For the most part I'm perfectly will to accept the changes as they are, but here are a few notes I took while going through the diffs.  Mostly I was trying to look at changes to resource fields and comparing them to what IESDP has to say:

Code: [Select]
DevSin's changes:

Lots of spelling corrections, lots of text changes which I'm inclined
to keep as they are. 

Lots of interface enhancements for viewing different structures.

Lots of fixes in general.  In particular, CHR looks to be better
supported.

BG1Tutu support.

I have to admit that a lot of changes are reformatting (breaking lists
in different places across lines) and I just don't have the patience
to go through each one of these and keep the original when they're
semantically equivalent.


Here are some changes where I went to IESDP and saw an inconsistency.
I'm sure I haven't caught them all (it's very tiring):

Ambient.java
    IESDP has:
        0x0026  2 (bytes)  Height of this sound.
    DevSin takes this out


Actor.java
    IESDP has:
        0x002c  4 (dword)  Spawned flag (0=no, 1=yes). Used in memory.
        0x0034  4 (dword)  Actor orientation. 0-15, starting south and incrementing clockwise.

    DevSin has each of these as a 2 byte field.

Animation.java
    IESDP
        0x0034  4 (dword)       bit 7: (0) Visible in dark / (1) Invisible in dark

    DevSin has unknown for bit 7

AreResource.java
    Not sure, some diffs I can't make sense of

Song.java
    IESDP
        0x0050  4 (dword)  Probably used only in PS: T -
                                        I suspect it has the meaning
                                        as described in SongFlag.IDS
                                        in this 
    game. Check AR1363 and AR1700 (PST)
    DevSin
        Reverb from REVERB.IDS (if REVERB.IDS exists)

SpawnPoint.java
    IESDP
        0x007a  2 (word)  Spawn method. (1=Rest,2=Revealed)
    DevSin/NI
        Has hex value.


PartyNPC.java
    Changes I don't understand, but I'm inclined to accept as correct.

Viewer.java
    "Is missile?" is changed to "Is bullet?" but this flag is set for
    Darts, so isn't "Is missle?" correct?

ProResource.java
    Significant changes, I don't have the patience to go through all
    of them.

VvcResource.java
    IESDP
        0x0018      2 (word)        Misc. flags
                                        bit 0: Unknown
                                        bit 1: Tranlucent
                                        bit 2: Unknown
                                        bit 3: Transparent
                                        bit 4: Mirror Y axis
                                        bit 5: Mirror X axis
                                        bit 6: Unknown
                                        bit 7: Unknown
                                        bit 8: Unknown
                                        bit 9: Blend
                                        bit 10: Unknown
                                        bit 11: Unknown
                                        bit 12: Unknown
                                        bit 13: Unknown
                                        bit 14: Unknown
                                        bit 15: Unknown         

    DevSin:
        Drawing
            bit 1: Transparent
            bit 3: Translucent


    IESDP
        0x001a      2 (word)    Tint:
                                    bit 0: Unknown
                                    bit 1: Unknown
                                    bit 2: Unknown
                                    bit 3: Greyscale
                                    bit 4: Unknown
                                    bit 5: Glowing
                                    bit 6: Unknown
                                    bit 7: Unknown
                                    bit 8: Unknown
                                    bit 9: Red
                                    bit 10: Unknown
                                    bit 11: Unknown
                                    bit 12: Unknown
                                    bit 13: Unknown
                                    bit 14: Unknown
                                    bit 15: Unknown
    DevSin
        Color adjustment
            bit 1: Blend
            bit 3: Greyscale
            bit 5: Brighten
            bit 9: Desaturate

    IESDP
    0x0020  4   (dword)
                    bit 0: Looping
                    bit 1: Sequence 2
                    bit 2: Sequence 4
                    bit 6: Wallgroups do not cover
                    bit 8: Use BAM

                    # 00= Play only the first sound (0x0078 , no
                          graphic or second sound (0x0080))
                    # 01= Play both sounds (repeat the second for the
                          duration of the effect) but without graphic
                    # 02= Play both sounds, one after the other, for
                          the duration of the effect (without graphic)
                    # 03= same as 01
                    # 04= same as 02
                    # 05= same as 01
                    # 06= same as 02
                    # 07= same as 01
                    # 08= Play the BAM sequence only once with both
                          sounds, ignore Y and Z positions and repeat
                          this for the duration of the effect.
                    # 09= Play the BAM sequence with both sound, the
                          first only once and the other for the
                          duration of the effect, ignore Y and Z
                          positions.
                    # 0A=same as 08
                    # 0B=same as 09
                    # 0C= Play the BAM sequence only once with both
                          sounds, use Y and Z positions and repeat
                          this for the duration of the effect.
                    # 0D= Play the BAM sequence with both sound, the
                          first only once and the other for the
                          duration of the effect, use Y and Z
                          positions.

    DevSin
        bit 0: Looping
        bit 3: Draw animation
        bit 6: Not covered by wall


(skipping a bunch)
Tilemap.java
    IESDP
        0x0006  1 (byte)  The upper 7 bits of this byte
                                        are a bitmap indicating which
                                        of the overlays are to be
                                        drawn. The 0th overlay (the
                                        base layer) is always drawn. 

    DevSin
        Unknown

AreaEntry.java
    IESDP
        0x0000  8 (resref)      Name of this area (as referenced by
                                area links?)
        0x0008  8 (resref)      AREA resref for this area

    DevSin
        These two look like they're swapped.

Posted by: FredSRichardson
« on: August 23, 2007, 09:10:00 AM »

Okay, I'm working on compiling a list of changes when they look like there's a contradiction with IESDP.  In these cases, I honestly don't know who's right.  I'll post that in a short while.
Posted by: FredSRichardson
« on: August 23, 2007, 08:50:29 AM »

Oops, my mistake!  Yes, you're right, they're all LF terminated (except the license files, but I bet these just came from the originals).

I wouldn't mind changing all my sources to LF instead of CRLF, but I guess I don't care too much.  Emacs deals with both pretty well ;)
Posted by: devSin
« on: August 23, 2007, 12:38:29 AM »

I guess the biggest difference is that my files have Windows EOL format (CRLF) while DevSin's are in Mac EOL format (CR).  The other option out there is to use *nix EOL format (LF).  I'm not big fan of Windows, but I'd settle on CRLF format so long as we can all deal with it.
Say what? They better be CRLF or LF. I put my hand on the bible that I haven't saved anything with CR line endings in the last five years, and if there are CR line breaks in that code, they didn't come from me.

I edited a couple of files directly in NetBeans, which may have tried to be helpful and use CR line breaks, but I can't imagine they'd do something that stupid...

EDIT: I just checked a random sampling of the files from my local sources, and they are all LF (which I would tend to agree with when working with Java tools). Maybe yours got changed to CRLF somehow or they got fudged when pushed into the repository?
Posted by: FredSRichardson
« on: August 22, 2007, 07:32:51 PM »

Okay, it's been forever and a day since I last worked on this.  And DevSin has made up for it by providing his change ;)

I've merged in DevSin's stuff with my last release, so it really looks like DevSin's code with a few minor tweaks.  I guess the biggest difference is that my files have Windows EOL format (CRLF) while DevSin's are in Mac EOL format (CR).  The other option out there is to use *nix EOL format (LF).  I'm not big fan of Windows, but I'd settle on CRLF format so long as we can all deal with it.

I'll try to get this version up for review pretty soon.
Posted by: Ascension64
« on: January 08, 2007, 07:54:04 PM »

You might not need to...the Beregost thing is probably a little too wayward to add to a general editor like NearInfinity, after some thought about it. I'm working on a GUI-based version that can process SAV files directly...it's going well.
Posted by: devSin
« on: January 08, 2007, 12:41:20 PM »

Undesirables == people who don't read the fixpack forum, I guess.

You can shoot notes to Fred or igi if you have questions or suggestions; it's their project.

The JAR I've posted features only things I actually cared (and had the time) to change, but I don't have any interest in maintaining it or otherwise modifying it.
Posted by: Miloch
« on: January 08, 2007, 09:57:49 AM »

Undesirables = people with little knowledge who might request enhancements?

Like for example, how hard would it be to add Ascension64's beregost.class (Tutu Beregost crash fixer) to the JAR?  I'd do it myself but I know very little (i.e., nothing) about Java.
Posted by: devSin
« on: January 07, 2007, 10:52:42 PM »

I put it up forever ago. I hid it in Cam's playthrough bugs in the fixpack forum to keep the undesirables away. :D

It's recent enough and shouldn't contain any bugs that weren't in previous 1.33 betas, but don't use it with nuclear materials or anything. There might be a small issue with the precedence of some checks somewhere that I introduced that I'd want to reinforce, but you shouldn't ever see it. There's also a couple issues with the world map where the IESDP is wrong (for BG2, at least), some minor spelling errors, and I didn't add support for Mac NWN (I've since done it locally), but it's pretty much all I'm ever going to do with it.

Make sure to read the license if you want to modify and/or redistribute. But you should probably just wait for Fred to roll it into the SourceForge tree (someday!).
Posted by: cmorgan
« on: January 07, 2007, 09:39:15 PM »

That JAR is wicked cool - lots more info. Thank you for putting it up.
Posted by: berelinde
« on: January 07, 2007, 06:20:14 PM »

Is there an actual new version of NI on the horizon?
Posted by: devSin
« on: January 07, 2007, 05:01:07 PM »

I put up a better build with better source of my crap. It should be a *lot* more diffriendly (all but EffectFactory), and I don't really have any reservations with just dumping in the changes en masse. There are one or two changes I'd want to make afterward, but I don't care enough right now to update the source archive. ;)

JAR
Source

EDIT: (1/9/07) source archive updated with latest changes (for Fred)
EDIT: (1/27/07) JAR and source archive updated with minor changes
Posted by: Caedwyr
« on: August 05, 2006, 06:43:00 PM »

Let's start with the small stuff (e.g. getting people to recognize when to use "your" and when to use "you're") before moving on to more complicated things :).

Like were, where, wear, we're.