Plugin problem

Richard,

In response to:

#1: Yup. Found that out.

#2: Doesn’t work if the 3DC file references object library items that don’t follow #1.

#3: Yeah, I threw in an oopsy handler that asks the user if they want to copy the original texture to the andquot;properandquot; 3DC subdirectory.

Also, about 3DC not keeping track of the original 3DO objects in libraries…does this mean if I add something to the library, the 3DO file is, strictly speaking, no longer necessary afterwards?

-Mel Ebbles

Richard,

Interesting thing…if you drag and drop a textured object from an object library into the scene, GetTexturePath will return an empty string when called from a plugin.

Judging from where I have my stuff, it looks like it’s returning the full relative path…my textures are in the same directory as the 3DO objects that I added to the object library.

Any chance of getting this fixed? It’s pretty much the only thing holding up my DarkBasic exporter plugin.

-Mel Ebbles

Addendum part deux:

Good news.

I’ve implemented a workaround…a new andquot;errorandquot; trapper in my plugin catches those instances, then asks the user if they want to locate the texture file in question. If not, it skips that texture during the export.

If they choose to locate the file, then the file is copied properly to the export directory. The user has the option afterwards of having the plugin copy the texture to the 3DC texture directory. It works.

Once you’ve copied an errant texture to the 3DC texture directory, you’ll never get the warning for that texture again.

So for starters, I think I’ll recommend to users that all textures be in that directory anyway…the locate/copy on error plugin feature is just a convenience for the sake of elegance.

So far the plugin has successfully done these things:

Writes 3DC lighting data to DarkBasic loader module with accurate results…for all compatible light types

Exports all 3DC objects to individual DirectX files in the same directory as the DarkBasic loader module

Writes static collision data to the DarkBasic loader module, which can be automatically implemented just by calling the normal DarkBasic sliding collision functions

Copies all textures to the same directory as the objects and DarkBasic loader module

Writes and saves DarkBasic code into simple functions like LOAD_MAP(), FLUSH_MAP(), and COMPILE_RETAIL_MAP() that can be called from any DarkBasic program

I’m working on additional plugin features at the moment also. It’s been an interesting project.

-Mel Ebbles

Addendum:

Tested it further, narrowed it down to GetTexturePath not liking files to be located anywhere other than the /Media/Textures folder in the 3DC directory.

I would appreciate that being fixed before 6.0. I really don’t want to put the users of my plugins through an inconvenient setup phase where they have to relocate all of their prefabs and textures just to make 3DC happy before the plugin will work consistently.

-Mel Ebbles

The textures need to be stored:

1) with the object library

or

2) where the 3DC file is saved (if it is a new document that hasn’t been saved this doesn’t apply)

or

3) in one of the andquot;standardandquot; folders. (media/textures etc.)

3DC doesn’t keep track of the original location of objects (3do files) added to object libraries so it may not be able to find the texture files associated.

If the texture files are in one of the three above locations then let me know the situation and I will fix it.

Richard

No, I sure didn’t. andnbsp;

Richard

Yeah, it is strange.

Whenever something odd happens, my first reaction is to re-examine my code as the first source of bugs or errors.

Initially I thought that I hadn’t declared, referenced, and set the 3DCApplication object properly before calling GetTexturePath, but when I replaced my file I/O routines with messageboxes that displayed the paths in question, I discovered that 3DC prefers textures to be in specific places.

Since that behavior on 3DC’s part was consistent, I soon dismissed the thought of it being a bug in 3DC. My pseudo-error handler takes care of those andquot;special-casesandquot; where textures aren’t in the right directories to begin with, which satisfied my desire for userproofing.

Before implementing that, though, I tested the plugin and found that if a 3DC file contains object library items that didn’t have their textures stored as you described, it wouldn’t work.

The cause was my object libraries violating the andquot;ruleandquot; that the textures really ought to be in the same directory as the object library if they didn’t exist in the default 3DC media subdirectory. My object library was one directory level above the textures used. Oops.

Saved 3DC files that reference textures that exist in the same directory, however, do export correctly. The problem happens only when I use poorly-organized (textures either do not exist alongside the CLO file or are not in the appropriate 3DC media subdirectory) object libraries.

So everything’s pretty much peachy at the moment, I guess <!– s:) –><img src="{SMILIES_PATH}/icon_e_smile.gif" alt="" title="Smile" /><!– s:) –>

I’m extending the plugin’s capabilities even further, and it looks like it’ll soon be capable of handling almost every possible DarkBasic feature from within the 3DC environment. Heck, if I threw in some of my ancient VB code, I could also do all my DarkBasic programming inside 3DC also.

Heh heh…bet you never expected to see 3DC Pro turned into a very capable DarkBasic IDE.

-Mel Ebbles

#2 should work. I just checked the function and it uses the same internal 3DC function that I use to find texture paths. The only time I know this to fail is when the 3DC file has not actually been saved yet (obviously).

And no, you don’t need to keep the 3DO file. In fact, I very rarely use 3DO files at all. Instead I add them to the object library using the andquot;add to object libraryandquot; right-click function.

Richard