75 replies to this topic

[Aliya]

Wow, I NEED to try this one out! Is sounds great! Why I didn't see it earlier?

[Miloch]

For some strange reason, the bam backgrounds show up as green.

What's strange is that no one's commented on it before. The background palette entry should be set to cyan (RGB 0,151,151) instead of green (0,255,0).

[berelinde]

It wasn't like that before. I've been using this mod for ages, and I didn't have this issue on the old computer. Only now that I'm using it with the Widescreen mod, although I doubt that has anything to do with it.

[Miloch]

It wasn't like that before. I've been using this mod for ages, and I didn't have this issue on the old computer. Only now that I'm using it with the Widescreen mod, although I doubt that has anything to do with it.

I'm looking at some of the BAMs both with BAM Workshop and DLTCEP. Some of them have the proper cyan background (such as jl#pb038.bam, which I guess is a tannish dye) and some have the green background (such as jl#pb000.bam, a blackish dye).

[vilkacis]

It shouldn't matter what the bg colour is as long as it is set to display as transparent - I've been using pure green as bg for item bams since forever. What's more, I want to say that all of these should have green backgrounds except for the ones where pure green is a component in the actual picture.

All I can think of is that maybe there are some very specific graphical setups that do require a specific colour to be used as transparent, but that would be ridiculous... or at least that's what I'd say if we weren't talking about the Infinity Engine, which is so full of "WTF is going on here" that nothing like this should surprise me anymore. It's not a solution, but you could try and see if anything happens if you fiddle with the number of colours displayed and/or resolution settings.

I'll have to look closer at this if/when I get back to working on Rupert again.

[Miloch]

All I can think of is that maybe there are some very specific graphical setups that do require a specific colour to be used as transparent, but that would be ridiculous...

I don't think it's hardware-specific. I just consoled in the two dyes I mentioned above (jl#pb000 and jl#pb038) and confirmed the green background appears on the first one but not the second. I looked at your palettes and the problem seems to be when you have your green more than once in the same palette, then perhaps the transparency is not getting picked up properly.

[vilkacis]

Wow. I think you've found an explanation that actually makes some kind of sense.

...it still doesn't explain why it works for some people and not for others, though. (I know I didn't see any green backgrounds while testing the last version, or I would have fixed them, d'oh.)

[Miloch]

Wow. I think you've found an explanation that actually makes some kind of sense.

Well, someone had to .

...it still doesn't explain why it works for some people and not for others, though. (I know I didn't see any green backgrounds while testing the last version, or I would have fixed them, d'oh.)

Colour blindness?

I can confirm that on my setup (same game machine I've had for years) the green background appears on the first slew of dyes, the last slew and indeed the majority of dyes in each category. There's a stretch around the middle that are ok. I messed around with the config settings to see if I could get rid of it but no luck (thinking it might be something in the software transparency). But I'm running a fairly bogstandard unmodded install at 800x600 (also tested at 1024x768) with more or less the standard graphics config. I have "transparent shadows" checked (tested without that too), 32-bit colour depth and that's it. I have a crappy old ATI card if that makes a difference. So maybe folks with cards that allow the "software transparent BLT" and the rest of those settings don't have this issue for some odd reason, but I can't even select those options with my card. Or it could be folks didn't really give a damn as long as they got their pink hair/armour out of the deal, or thought they were supposed to be green, or were smoking crack when they played/tested the mod, or the engine is full of all sorts of weird quirks or who knows what else.

Rather than quibbling or hypothesising further though, this should be fairly easy to fix, if incredibly tedious to do it manually. If I were a real WeiFu ninja, I'd offer up a few pithy lines of code to fix it. I'm thinking maybe something could be done with DECOMPRESS_REPLACE_FILE (that may not even be necessary if your BAMs aren't compressed) and a surgical WRITE_BYTE or two to fix the palette, but it'd probably require a keener brain than mine to produce that actual code.

Now I hadn't intended to go through this mod with a fine-toothed orcish club, but beware! My paw has been forced! Why, may I ask, are you extending area scripts with an AreaCheck()? This is only a valid trigger for CREs according to the IESDP, no? I don't claim to know much more than jack about scripting, so I could be dead wrong as usual, but I'm curious.

Edit: mind > mine

Edited by Miloch, 22 May 2009 - 03:16 PM.

[vilkacis]

You're not seriously expecting me to remember what I was thinking all the way back in 2007, right?

It's possible that I was originally intending to have all the bafs in a single file and have it checked globally, or something along those lines. It's also possible that the bgt/tutu issue had something to do with it. It does look like an area check should be necessary for the BG1 portion (since it attaches the same script to both versions of the Friendly Arm, even thuogh the area names are different), but I really don't know why I kept them in the other ones.

I doubt I used IESDP as a reference at the time - probably just looked at other mods for code that seemed like it worked, tested it and kept whatever didn't crash the game horribly.

[Leomar]

Attached are the traified files and the German translation of Rupert the dye merchant.

Translator is Meresin.

Greetings Leomar

Attached Files

•  Rupert_TraifiedwithGerman.7z   11.82K   456 downloads

[Lollorian]

Heya I got the same green backgrounds thing in me BWP8 install. Like Miloch mentions, only the first and last set of bottles have the green while the ones in the middle don't. Maybe I should mention that I use the W_GUI and widescreen mods too

WeiDU.log here, if need be

Thanks,
Lol

[Miloch]

this should be fairly easy to fix, if incredibly tedious to do it manually. If I were a real WeiFu ninja, I'd offer up a few pithy lines of code to fix it.

Well. It involved a bit more than that, but with a combination of BAM Batcher and PSP scripts, I fixed the suckers (I think). I scripted in drop shadows on the large icons while I was at it, because they didn't have any.

Just drop these in your rupert/bams folder or if you've already installed the mod, dump them in your override folder.
 rup_bams.rar   67.12K   434 downloads
You owe me one, vilkacis, you lazy bastard .

Edit:

Can you make the paints/dyes not dispellable?

Fixed this while I was at it too. Extract these to /rupert overwriting the existing items (or again, your override if you've already installed the mod).
 rup_itms.rar   116.54K   452 downloads
This is the code I used, if it's of interest. No reason to include it in the mod if you include the updated items.

COPY ~rupert/armour~  ~rupert/armour~
	 ~rupert/buckle~  ~rupert/buckle~
	 ~rupert/hair~	~rupert/hair~
	 ~rupert/large~   ~rupert/large~
	 ~rupert/leather~ ~rupert/leather~
	 ~rupert/small~   ~rupert/small~
  READ_LONG 0x64 hf //Extended header offset
  READ_SHORT 0x68 hc //Extended header count
  READ_LONG 0x6a fb //Feature block offset
  FOR (i1 = 0; i1 < hc; i1 += 1) BEGIN //Cycle through extended headers
	READ_SHORT (hf + 0x1e + (0x28 * i1)) fc //Feature count
	READ_SHORT (hf + 0x20 + (0x28 * i1)) fs //Feature offset
	FOR (i2 = fs; i2 < (fs + fc); i2 += 1) BEGIN //Cycle through ability effects
	  READ_BYTE (fb + 0x30 * i2 + 0xd) dx
	  PATCH_IF dx != 2 BEGIN //Dispellability to change to
		WRITE_BYTE (fb + 0x30 * i2 + 0xd) 2
	  END
	END
  END
BUT_ONLY

Edited by Miloch, 28 September 2009 - 04:12 AM.

[berelinde]

Miloch, you rock.

[vilkacis]

I'm not lazy, I just knew that if I put it off long enough, someone else would come around and do it for me

AHEM! Here's a bottle of virtual scotch for your work:



...this is totally going in the next version, and I should get around to those additions I was thinking about before.

[Yovaneth]

Well he can't complain that you haven't given him a decent bottle of whiskey for his efforts....

-Y-

Edit: three serious typos in just seventeen words... gah.

Edited by Yovaneth, 01 October 2009 - 06:53 AM.

[Miloch]

Well he can't complain that you haven't given him a decent bottle of whiskey for his efforts....

My only complaint is that it's not a real bottle .

[Leomar]

I'm not lazy, I just knew that if I put it off long enough, someone else would come around and do it for me

That is not fair.

O.K. I'm someone else and done it for you... unbelievable...

Attached is the new version with the following:

VERSION 1.1
- Miloch's fixes: http://www.shsforums.net/index.php?s=&showtopic=24786&view=findpost&p=463770 
- Traified the mod
- Added German translation by Meresin
- Changed to README-command
- Added VERSION-flag
- Updated to WeiDU v211

The only thing I want from you is, to upload the new version here:
http://www.shsforums...mp;showfile=153


Greetings Leomar

Attached Files

•  Rupert_v1.1.zip   818.41K   495 downloads

[vilkacis]

That is not fair.

Well, I'm not complaining.

Done and done- updated both the OP and the page in downloads. (Thanks, by the way.)








I still hope to get a 2.0 version of Rupert out at some point, with the additions I was thinking about.

[vilkacis]

UPDATED MY JOURNAL:

Rupert 2.0 is out. Rejoice! And stuff.

Edited by vilkacis, 23 December 2009 - 05:49 AM.

[Lollorian]

Hi there,

There's a small typo in line 24 of rupert\rupert\JL#RCMAG.baf (GNOMOE -> GNOME)

Cheers,
Lol