Unwanted invisible placeables in m44ab.

[e-varmint]

Here's something strange: I'm working on using unk_m44ab (unknown temple catacombs) in a mod. I extracted everything, removed all creatures, placeables, triggers, and waypoints from the .git file. I then made a .mod file that I can use to walk around in and "whereami" at the locations where I want new stuff. Everything works OK, except that any placeables that I put in the center of the large room on the West side of the map are invisible. I can tell that they are present, because they block my path.

 

Does anyone know what's causing this?

[Darth InSidious]

Have you checked/tried changing the Z co-ordinates?

[e-varmint]

Have you checked/tried changing the Z co-ordinates?

Yep, that was the problem. I typo'd a 6 instead of a 0, then copied the bad placeable 8 times.

 

Now, how can I make the room brighter? The objects are on the floor again, but it's so dark in this room that I run into them anyway.

 

Edit: Changing the brightness of the lightmaps makes the core objects of the module brighter, but my placeables/players/doors are still dark. I guess I need a way to change the ambient light level.

[Darth InSidious]

Altering the TweakColor and UseTweakColor settings should allow you to alter that. I think the fields are called that, anyway. I don't have a GFF editor available here, though...

[e-varmint]

Altering the TweakColor and UseTweakColor settings should allow you to alter that.

 

Great! Where do I find these settings?

[glovemaster]

In the GIT file under each door/placeable struct.

[e-varmint]

In the GIT file under each door/placeable struct.

 

I'm not finding any existing fields for TweakColor. Which type of field (dword, etc) should I add, and what is the proper syntax?

 

Is there a tutorial somewhere that describes the various fields that K-GFF can add?

 

Thanks!!!

[tk102]

TweakColor is a DWORD. (looks like the decimal representation of a 3-byte RGB value)

UseTweakColor is a BYTE. (0 or 1)

 

I discovered this by opening up a another .git file and looking at a door struct and a placeable struct.

 

There is no K-GFF centric tutorial. K-GFF is a tool used in other tutorials.

[glovemaster]

Here:

http://glovemaster.110mb.com/images/tweakcolour.png

101per.git

 

TweakColor is a DWORD with as Tk said ^ a 3 byte RBG number so i think red is 25500 and green is 02550, blue: 00255

And UseTweakColor is a BYTE with values 0 (NO) and 1 (YES)

 

EDIT: Ah, Tk beat me to it...

[tk102]

Actually I think

R = 0xFF0000 = 16711680

G = 0x00FF00 = 65280

B = 0x0000FF = 255

 

R and B might be inverted -- dunno.

 

White = 0xFFFFFF = 16777215

[e-varmint]

Thanks!!! I'll start researching 3 byte RBG numbers. If I can find or concoct some sort of list, I'll post it here.

 

Edit:

Ah, TK beat me to it too!

[glovemaster]

I found this:

All the colors are entered as a number. If you have the color expressed as RGB, each component in the range 0..255, the formula for the color number is color = 65536*B + 256*G + R

In other words, the color is expressed as a decimal number whose hexadecimal representation is 00BBGGRR.

So, Tk was right, R and B are inverted

 

EDIT:

I had some time so i decided to make a program to work this out for you: here is the download link if you want it i have included source code and its all pretty simple so im not going to go to the trouble of licence and copyrights.

 

3 Byte RGB Calculator

[e-varmint]

I found this:

 

So, Tk was right, R and B are inverted

 

EDIT:

I had some time so i decided to make a program to work this out for you: here is the download link if you want it i have included source code and its all pretty simple so im not going to go to the trouble of licence and copyrights.

 

3 Byte RGB Calculator

Nice Work!!! You should put this in one of the tutorial threads, I suspect that modders will be quite interested in this.

[Leviathan]

Off-topic : If I am not mistaking, the problem you have adverted to earlier as regards the fact hexadecimal values have to be transposed in order to be deciphered and turned into decimal numbers matches the sort of notions taught during courses dealing with Networks and Data Transmission. More precisely, contrary to what has been stated above, values encoded using the Hexadecimal Numbering System are already susceptible to be converted towards another Numeral System by reading them the same way computers would do. Indeed, by assuming these machines can only handle one figure at a time while informations are being transmitted, we can easily assume that submitted numerics will be reconstituted in a more logical way if their different figures are accounted from the last one to the very first of theirs. As a consequence, this process implies that the communicated numerals are read invertedly, which is eventually way more efficient than our own counting method. Nevertheless, both these two techniques are quite alike, since they involve that their respective users are reading numbers the way they consider it is meant to be done...