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.
Inconveniencing the Infinity Engine since 2001.
News:
Quest Pack released! Download from http://www.pocketplane.net/quest!
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.
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:
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
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.
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.
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.
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!).
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
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.