Duck and Cover

Thanks, though it nearly killed my geriatric pc. Sure glad I was extracting the tga's one row at a time, and hadn't wasted too much time putting the map together. Though I bet Red's off somewhere laughing his head off that we hadn't noticed this before.

Hmm since you've extracted the map in one file and can play about with channels in photoshop better than I can in Corel, is there any channel data worth noting around the lakes?

requiem_for_a_starfury wrote:Though I bet Red's off somewhere laughing his head off that we hadn't noticed this before.

You're probably right. I noticed that it would display them all when in Preview Mode last week when I first started. It...um...well, for some strange reason it just never occured to me to tell it to render. :oops:

requiem_for_a_starfury wrote:Hmm since you've extracted the map in one file and can play about with channels in photoshop better than I can in Corel, is there any channel data worth noting around the lakes?

No. It's all in RGB channels, no alpha or spot channels. So, while we are now "in business" for modified versions of the core map -- and w/o having to x-fer it!!! -- we're still sitting at square one when it comes to impassability and/or variable travel speed.

Still, I'm glad I found this!

OTB

Is there anyway to set campaign variables to trigger from the date, i.e. you have to reach your mission by March 15th otherwise if you get there too late you'll automatically fail the mission? I don't think there is, so it kind of makes travel speed rather redundant in FOT, since it doesn't matter how long you wander around looking for REs and SEs. To be honest as long as you still travel faster in a vehicle than on foot is all that really matters. The only thing I want to be able to do is prevent travel over certain areas like water.

requiem_for_a_starfury wrote:Is there anyway to set campaign variables to trigger from the date, i.e. you have to reach your mission by March 15th otherwise if you get there too late you'll automatically fail the mission?

No, there's no way to do that. The clock is completely irrelevant to this sort of thing. That's straight from the mouth of Ed Orman and his cabal of code monkeys.

Funny, how an ancient RPG -- by the standards of the gaming industry -- has more sophisticated triggers than a squad-based game that was supposed to build on it.

Actually...that's not funny...

Requiem wrote:I don't think there is, so it kind of makes travel speed rather redundant in FOT, since it doesn't matter how long you wander around looking for REs and SEs. To be honest as long as you still travel faster in a vehicle than on foot is all that really matters. The only thing I want to be able to do is prevent travel over certain areas like water.

You know, that's a good point. Since you could go out and wander around for over a year between missions 1 and 2 all w/o affecting the game it just really doesn't matter in game terms, and that's what I'm going to worry about.

Like you said, as long as we can block off water, we're golden.

Now to figure out how to block off water...

OTB

Yeah, in FO 1 & 2 travel time played an important part in the game, but without any time limits it's an waste of time to be worrying about it in FOT.

When you use Redviewer to extract a zar to a tga file it should include an alpha channel. I tried extracting a few of the squares to tga's and they did have alpha channels but those channels were clear.

Also last night I tried walking the world map and did not find any areas where travel was slowed. I didn't check everywhere though, I forgot to remove the random encounters from the test campaign....

Jimmyjay86 wrote:When you use Redviewer to extract a zar to a tga file it should include an alpha channel. I tried extracting a few of the squares to tga's and they did have alpha channels but those channels were clear.

The squares I was importing didn't have alpha channels. (May have been me fucking up in Photoshop, though.) I just made three new versions of the map, w/different alpha channel settings (Additive, Negative 1, and Negative 2) and I checked them all, including the original (where the Alpha Channel setting in Red!Viewer was "None") and all four have alpha channels. However, they are all clear. I'll dick around w/this more later on. Right now I'm out of RAM and my machine is chugging along on Virtual Memory.

OTB

For the want of anything better to do I converted the tga of the map to a png and opened up the BOS.cam in the campaign editor. I imported the image, and since the grid was the same size none of the data was messed up so I saved it as a test and loaded it in FOT. Once I had watched all the raiders explode in my dummy brahmin wood ( ) I went to the world map and the lakes were still blocked off. So I reduced the png to 25% and made another test.cam, this time since the grid squares didn't match all the positioning data had been lost and in game I could now walk across the lakes.

I'll have a go at reducing the map so it matches up with the 50 pixel grid setting and see how that affects things.

Edit Reducing the image didn't work, though I couldn't get the grid lines to exactly match up. I also tried cutting a section out of the png, but that didn't work. Corel doesn't like pngs and alpha channels, it converts the channel to a mask so I tried removing the mask and converting the png to paletted 8 bit, removing the rgb channels strangely this still worked. For some reason I also tried flipping the image horizontally so instead of the lakes brahmin wood was in the mountains, when you travel up to where the lake was you hit an invisible barrier.

I also tried importing the original png and the 8 bit one into brand new cams, starting from scratch, these didn't stop me from travelling across the lakes.

I presume then that either the channel information has been stored in the bos.cam and as long as you keep the same grid and image size you can import any image you want and you'll find the same areas blocked off as in the original map.

Perhaps the masking channel information was something done seperately and not part of the image? I know in Corel you can save alpha channels seperately to the main image, though not as pngs.

Yeah it's pretty amazing that running on my new machine with 512Mb RAM, I still can't run this fricking game and Photoshop at the same time....

OnTheBounce wrote:The squares I was importing didn't have alpha channels. (May have been me fucking up in Photoshop, though.)

Okay, I was high here. The tiles as exported did have alpha channels. Once I imported them into my huge world map PSD they didn't.

I've just fired off an email to Ed Orman about this. If he can't help us, hopefully he can put us in touch with someone who can. (Or maybe Red! can figure out how this passable/impassable terrain works?)

OTB

Ed Orman got back with me. He apparently has some milestone at work on Friday, so he's really busy. However, he said he'd check into this as soon as he had time.

Cross your fingers, gents.

OTB

Okay, The Ed Himself got back to me and here's what he had to say:

]ed[ wrote:Ok, I think I remember. You create a grayscale version of the terrain image and put it in the alpha channel of the PNG. Black means slow movement, white means fast movement (or the reverse). When you use Import Image, it then brings in the diffuse and the alpha channel, and bases movement off that. Whether Black means impassable or just really slow, I'm not sure.

I'm pretty sure that's what we did. I've shot off a question to Rob and Karl (programmers on Tactics) to see if I'm right.

I tried what he said and here's a link to the result.

This should look familiar to some of you. I know it does to me.

Oh well, Ed informs me that he's forwarded the question to Rob (Maddock?) and Karl (Burdack).

I know this isn't a hot priority for some of you, but I figured I'd let you know where this issue sits as of today.

Cheers,

OTB

Yeah, there is something more to it than the black in the alpha channel. I tried most variations of that and it still didn't work.

Hmm whether it affects the travel times I don't know, but even if it does I don't see how it has anything to do with the blocking off of certain areas. Since as OTB pointed out only the lakes are impassable and as a greyscale the lakes are neither black or white. Plus as I pointed out in my (rather rambling) previous post that with the existing BOS.cam the masking data remains as long as you import an (same size) image with the same grid size (75).

Okay, Ed Orman got back with me and here's what he had to say:

]ed[ wrote:So I spoke to Alistair (one of the programmers still at MF). He had a look on the server and found the original PNG image we used. He was pretty sure that it had a grayscale alpha channel with black being impassable. I don't know what _format_ the PNG was.

Any idea what is meant by "format" of a PNG? I'm going to putz around w/interlacing and some other things today. Hopefully I'll stumble onto the right combination...

OTB

http://www.libpng.org/pub/png/

What program did they use to make the png's?

Ed Orman's response:

Ed Orman wrote:Format prolly wasn't the right word. I meant whether it was 16/24/32 bit. I'm thinking 32 bit, since it had an alpha channel.

Good luck!

I can't remember PS supporting 32-bit format for PNGs...I'll tinker a bit more, though. Edit: 32-bit would be RGB w/Alpha at 8-bits per control channel. Correct?

Thanks for the link, JJ86, I'll poke around there, too.

OTB

I have Macromedia Fireworks which supports 32-bit Pngs.

Could you try to fiddle a bit w/it and see what happens? I would think that simply using a grayscale version of the map and pasting that in as the alpha channel should yield some results.

Can-you-can-you...please-please-please?!

If necessary I can send you a small extract of the core campaign's map.

OTB

Yeah, can you send me a small portion of the map?