16 réponses à ce sujet

[OldTimeRadio]

Here's what it looks like:

 

 

It's a "sampler" tile.  The only one I'm aware of.  It's got mainlights and sourcelights and the two obelisk pieces and the animesh flag do things when you turn the various animloops on.  The window pane on the ground has a day/night transition.  Sort of a "here's some of what you can do on a tile" kind of thing.

 

But there's a little more going on with this guy than meets the eye.

 

One thing I find interesting is that the texture on the animesh flag is listed as "replace_tex".  I sussed out that that this texture name is actually a hardcoded hook that causes NWN to read into replacetexture.2da.  Replace the entry in row 0 of that 2da with the texture of your choice and the flag will be textured with it.  I am guessing that there might be more of this, related to the undocumented Tile_ReplaceTex field in the .ARE GFF inside my open temp0 directory.  I've tried adding that field as a BYTE and a couple of others and setting them to 1 but no luck in getting it to tick over to the next row's texture.  Any guesses how it might work?  I'm working under the assumption that it was slated to be something you could modify in the tile's properties (like turning an animloop off and on) but the change never made it into the toolset, though at least the basic retexturing function seems to work in the game.  I'm thinking it was to be used to allow you to do a very basic reskin on a tile without having to make a whole 'nother model.

 

Another interesting thing, I think, is the use of a light called "AuroraLight01" which also maps to a hardcoded string in NWMain.exe.  Two mysterious funky hardcoded things in one model!  Well, seems like that, anyway.  Do you tile builders use AuroraLight01 intentionally?  Do you know of it?  It sort of looks like a canned light source (i.e. nothing special that I could see) you kind of throw in there (it's connected to the "a dummy", interestingly) and maybe it changes color or something.  I haven't messed with it hardly at all and IDA debugger isn't giving up any sexy clues...except that there may be another something-something (dummy?) called "sourcelight" that does something.

 

If there's no interest, I'll maybe fiddle with these a bit more but I'd be happy to do whatever I can to help someone or someones look into this further.  Just tell me what you need.  I've already extracted tms_c08_01.mdl in binary form, renamed it an hex edited the internal name so it's a flawless duplicate of tms_c01_01, the grass tile for the Microset.

 

I believe there are a decent number of tiles which aren't in .SETs but does anyone know of other 'weird' tiles or models like this, where they sort of demonstrate something or seem to have unusual data?

 

Thanks!

[T0r0]

Nothing to add OTR but the fact that this ol' gal (NWN) still has a few tantalizing secrets tucked away is amazing to me.

[T0r0]

Dbl post

[Zwerkules]

Another interesting thing, I think, is the use of a light called "AuroraLight01" which also maps to a hardcoded string in NWMain.exe.  Two mysterious funky hardcoded things in one model!  Well, seems like that, anyway.  Do you tile builders use AuroraLight01 intentionally?  Do you know of it?  It sort of looks like a canned light source (i.e. nothing special that I could see) you kind of throw in there (it's connected to the "a dummy", interestingly) and maybe it changes color or something.  I haven't messed with it hardly at all and IDA debugger isn't giving up any sexy clues...except that there may be another something-something (dummy?) called "sourcelight" that does something.

Apart from the name it doesn't look different from any of the lights used for the orange glow at night in animated windows. Usually those are named l_dayn0x. The animations are also the same. I haven't checked where it is placed, but I guess it's near that window.

I guess sometimes they named it AuroraLight0x just like they often named emitters OmenEmitter0x.

[Bannor Bloodfist]

One thing I find interesting is that the texture on the animesh flag is listed as "replace_tex".  I sussed out that that this texture name is actually a hardcoded hook that causes NWN to read into replacetexture.2da.  Replace the entry in row 0 of that 2da with the texture of your choice and the flag will be textured with it.  I am guessing that there might be more of this, related to the undocumented Tile_ReplaceTex field in the .ARE GFF inside my open temp0 directory.  I've tried adding that field as a BYTE and a couple of others and setting them to 1 but no luck in getting it to tick over to the next row's texture.  Any guesses how it might work?  I'm working under the assumption that it was slated to be something you could modify in the tile's properties (like turning an animloop off and on) but the change never made it into the toolset, though at least the basic retexturing function seems to work in the game.  I'm thinking it was to be used to allow you to do a very basic reskin on a tile without having to make a whole 'nother model.

 

 

Have you attempted a simple thing like just renaming replace_tex with replace_tex01?  Or variations there of, in the tile mdl itself?  IE, whatever is the name of the 2nd row in the 2da?

[OldTimeRadio]

Had some RL distractions so just getting a chance to look at this again.

 

@Zwerkules - I agree and thank you for taking a look.   So far, it just looks like "AuroraLight01" I'm seeing in the strings is probably just a coincidence.  I'm thinking now that that string in the code may be related to the light that you can make with an entry in placeables.2da.  Some of the other strings around it are ones from that and lightcolor.2da.  It looks like the thing it was demonstrating on the "sampler" tile is just that you can have non-main and non-source lights connected to an "a dummy" and animated.

 

@Bannor - That's a good idea and I tried it but it didn't seem to change the texture.  It did clarify something in my mind which is, even if that did work (i.e. "replace_tex1") then it would essentially be the same as just putting a different texture name in the bitmap field of the model.  The way this sort of thing appears to work is it's a setting on the model...that isn't in the model.  Kind of like how the main and sourcelight colors and the boolean animation loops modify the model without those changes being in the model.  Unfortunately, after trying a number of different data types for Tile_ReplaceTex in my sample area's .ARE file or a similar type change in the .SET, none of them seem to get it to move onto that next texture.

[Bannor Bloodfist]

Well, it appears just from the fact that it points to a 2da, that the intention is to allow multiple rows, else why use a 2da?  As to directly naming a field for a specific row in that 2da, it would still allow a SINGLE location where you could theoretically re-skin, without having to manually edit every tile, as long as the original tile-set was setup in such a way as to allow you to use that 2da for the texture names. ie. Tile_ReplaceTex with an index of some sort.  I get the idea you are just attempting to figure out how to access that specific index.  Regardless though, the individual tiles in a given set, would have to be setup correctly for an indexed array to work.  I have never seen that "Tile_ReplaceTex" except in that specific model.

 

I believe OMB played around with that a bit, but I just can't remember.  I do know that CTP spent quite a bit of time investigating all the various features/objects/animations etc, in that tile to be able to figure out how to accomplish various things... unfortunately, we never actually pointed out that tile to the rest of the community, other than in passing... ie not making forum posts about it, just internally chatting about it.

 

Some of the stuff I created tutorials for, came from investigations of the lighting affects, specifically day/night transitions, and some other bits from that tile.

 

Anyway, back to Tile_ReplaceTex, if that is a single pointer, which is what ANY reference to any 2da is, a single pointer, can only point in one direction.  if you auto-index that, and every single object in that particular mdl used the same Tile_ReplaceTex and it somehow auto-indexed to the next row, you would end up with all sorts of issues with mismatched texture replacements going on because there was no way to specify which row in the index to grab from.  Basically what I am attempting to say, is that I don't believe it was intended as an auto-index type of feature, just as a way to point out that you could, reference a row in a 2da for the texture name to be used for a specific object in a mdl file.

 

Did that make sense?

[OldTimeRadio]

Yep, I see what you're saying.  I tried several meshes with the replace_tex bitmap on them and it appears to grab the first mesh in the node hierarchy with "Replace_tex" as the bitmap and ignores the other meshes.  But it's still a good idea.  Looking over the model again, I noticed that it's anim mesh.  Can't really tell how important that particular bit is.  I'm probably going to keep plugging away at the thing I was looking at for the other thread, but if anyone wants to look at it more, shoot me a PM and I'll see what I can rig up for ya.

[Bannor Bloodfist]

Yep, I see what you're saying.  I tried several meshes with the replace_tex bitmap on them and it appears to grab the first mesh in the node hierarchy with "Replace_tex" as the bitmap and ignores the other meshes.  But it's still a good idea.  Looking over the model again, I noticed that it's anim mesh.  Can't really tell how important that particular bit is.  I'm probably going to keep plugging away at the thing I was looking at for the other thread, but if anyone wants to look at it more, shoot me a PM and I'll see what I can rig up for ya.

(please ignore the following three lines) It is animesh because it is a flag, that is weighted to move with the wind.  (I mean the individual vertices use a bit weight of the color red, to determine how much they react with the strength of the wind)  I doubt that has any bearing on the texture bit,

 

UNLESS they (bio-engineers that wrote the code) are using the animesh tag as an extra bit to toggle special processing in general.

 

(please ignore the following two lines) I doubt that is the case here, and it would be easy to check by just assigning that particular replace_tex to a solid object, say a stone and see if something different happens. IE: The animesh tag and associated parent, are only there because the flag moves with the wind, and has nothing to do with the texture applied.

 

I would suspect that it simply replaces the assigned texture as you have already found. 

 

Likely, tt is simply a way to reskin, without having to manually assign the new texture name to each mdl... IE, if all the mdls in a given set were created to use the various replace_tex, replace_tex01, replace_tex02 etc in that 2da, you could simply assign a NEW 2da, IE an overriding 2da, to re-skin without having to manually go through and either create new textures of the same name (which has override issues with OTHER sets in a given mod) or by having to manually rename each texture bit in each module.  It was likely something that a particular engineer use as his/her style or something that was just never actually implemented as it was more trouble that it was worth with outsourcing etc... Bio had outsourced some tilesets and other objects, creatures, etc, and by having things outsourced, it becomes more problematic attempting to force artists to create using specific naming conventions etc...

 

You should know how it goes, artists in particular, are very prideful (rightfully so in some cases) and want things their own way, seldom do they like to follow rules set by others unless it is absolutely necessary.  So forcing someone to name a texture for a wall to be "replace_tex02" or "replace_tex04"  or whatever you choose, becomes more and more problematic... sensibly, most textures are named in a way that makes some sort of logical sense as to the object they are coloring with that texture.  Using the replace tex would be powerful only if you were choosing to re-use all the objects and get them re-skinned with a single set of textures applied by that 2da, and if you were wanting to have it as a centralized, controlled re-skin process.  Bioware didn't bother with that in the long run, they just re-skinned whatever needed it the same way that the community has done, either by replacing existing textures using the same name OR by manually replacing the bitmap fields in the objects that are being re-skinned. (The later being the best way as it avoids the bad replacing of OTHER objects, tiles, etc with a renamed texture.)

 

P.S. Edit notes:   sections converted to italics above are only left so that folks can follow the entire conversation, but do reflect BAD statements created by me personally.  To whit, I stated that animesh was used for the flexible flag. when in actuality that would have been accomplished using auroraflex sometimes referred to as danglymesh.  Thanks to Zwerkules and OldTimeRadio for making note of my mistake.  Basically, just ignore the italicized text above and you will be better off!  Again, I am leaving it in place to allow the ability to completely follow the entire conversation(s) herein.

Modifié par Bannor Bloodfist, 14 mars 2016 - 10:20 .

[Zwerkules]

It is animesh because it is a flag, that is weighted to move with the wind.  (I mean the individual vertices use a bit weight of the color red, to determine how much they react with the strength of the wind)

You confused animesh with danglymesh (AuroraFlex) here.

[OldTimeRadio]

I think you're getting anim mesh confused for danglymesh but I hear the rest of what you're saying.  Just to be clear, the reason why I think there's more to it than just the "Replace_tex" texture hook, itself, is that there is a GFF field for the area (.ARE) file called  Tile_ReplaceTex and a .SET file line called ReplaceTexture.  I managed to delete enough regkeys so that the NWN Toolset BETA installed on my machine and, wading carefully through legacy bif's resources, I was able to locate the replacetexture.2da but it was exactly the copy as we have it today.

 

Speaking of the BETA, lots of interesting stuff in there including many self-decribed "test" models in ASCII.  Looking over it just since last night, there are some really choice bits, including a node patch (as opposed to trimesh) model, an ASCII file which uses a precursor of the ASCII format we have today and a bunch of TXI's for doing bumpy-shiny on bodyparts (specifically) and some other esoteric material.  I can't imagine any of that stuff would run in the game though- the ASCII command simply don't exist for it in 1.69- but it's interesting to look over.

 

Makes it a bit more irritating to wait for any enhanced edition which may or may not come out in the future.  So many promising things apparently just out of reach.

[Frith5]

Am I far out in the field to wonder if this wasn't an early attempt to make seasonally changing tilesets or the like? If the .2da actually worked, it would make summer textured tiles into winter textured tiles?

​Just musing.

 

-JFK

[Jedijax]

Thought the same thing, but it could be used for a plethora of other effects if such were the case.

Close

[Shadooow]

you know virusman enabled texture replacement in NWNCX...

[OldTimeRadio]

@Frith5 - It looks like it was basic enough to just switch one texture per tile- which would have done fine to swap the ground texture out.  I'm not investigating this too much but if me or somebody fleshes this out and it turns out it could just do the one texture swap per tile, it probably would have been good for variations but not huge deviations.  For instance, you can swap a regular ground out for a snowy ground...but the trees still wouldn't have snow on them.

 

@Shadooow - That's a good point but do you happen to know whether or not that texture replacement "just works" or whether you have problems with people seeing the old texture if they join or enter the area after the switch is made in either single player or multiplayer.  

 

Ninja-Edit: Since I made a demo of this very feature (which, ironically, I don't actually have anymore), I decided to check out the thread and see what I forgot.  It appears that it wouldn't work on a tile, at least at that time.  Do you happen to know if something was updated or changed since that was posted?  

 

Humorously, a little down in that same thread, VirusMan actually mentions replacetexture.2da and I liked his message (4 years ago?) and forgot all about it, lol.  His message doesn't appear to be indexed by Google, either, which is a special kind of frustrating in its implications.

[Shadooow]

No I never messed with this NWNCX feature.

 

However I was trying to make SetAnimLoop function and there was problem with server-client mode. Anim loop is changed however client won't see a change until he reloads the area (if he is in it at the moment of calling the function).

 

I suppose the same problem will be there.

 

This is solveable but there must be a custom server-client message to tell client to do that as well. Which is a bit problematic due to the NWNX plugin architecture. The actual modularity in plugins means that either you get nwnx_connect functionality or setanimloop functionality. Anyway, solveable...

[Bannor Bloodfist]

You confused animesh with danglymesh (AuroraFlex) here.

Duh, picking myself back up from the floor after banging head on the desktop, repeatedly for such a stupid mistake.

 

You are absolutely correct in that aspect, yes, I was referring to danglymesh/auroraflex... I can't believe I did that.  I can remember feeling so, well uh, knowitall by point that out to others in the past, then I go and do the same damned thing... what an Idiot.  I will attempt to edit that post to reflect same.