Universal Model Converter - Side Development Thread

[Tcll]

just showin off progress as it comes
(just to keep everyone informed I'm still hard at work)


my CPU isn't even putting up even a minor fuss! :D
I'm SO glad I did this redesign! ^_^

this UI would probably lag like ballz with the old build :3
(including the fact I don't have much done on it)

each scrollbox you see there is drawing 8 quads total on a large varriation of stack-layers.

anyways, I still gotta get this stupid filter-select box working and make it scrollable, then I can start working on the file-list scrollbox
(I hate the selectbox and scrollbox widgets because they require alot of brain-work)

the scrollbox draws on specified layers for cutoff and cutout
the selctbox currently needs 2 extended widget types for the buttons and clickoff area

talk about migranes... lol

EDIT:
btw, the GUI currently doesn't support a D-click action, so instead of worrying about that complex addition and delaying the release even further, I'll just suport the file select with the basic:
click a file/directory from the list (which will show the file name in the entry)
if the selection is a directory, update the scrollbox and directory with the new data
if the selection is a file, return the filepath and close the dialog

I'll support D-click events and other complex additives in an update

like I said, I want to get a release out ASAP, so I'll worry about minor convenience functionality later.

 

[Tcll]

this was a freakin headache:


still got alot more to do, but the hard part is over

I'm so close to being able to have my own file explorer! =D
(a step up towards UGC)

EDIT:
update:
much better:


it's decently fast too
(the display lags only a tad when hovering over the items)

EDIT2:
update:

like I said... easy *crosses arms* ^_^

EDIT3:
not finished yet though, the widgets aren't actually removed, and can still be clicked:

just thought I'd notify

 

[Tcll]

just posting another update:
got the hitdefs to stay w/in scrolling range


the widgets are still drawn behind the overlay quads though >_>

EDIT:
progress

/mouse wheel

I'm still working on the scroll button
but yes, everything that works, works properly

also, I'll work on the bookmarks and file history in a future update
convenience is saved for later... heh

 

[Tcll]

just wanted to post an update:
the scroll button now works perfectly,
but there's currently a catch with how I've coded everything else:

what I need to do is disable the other hitdefs while holding LMB and re-enable them upon release.

what you're currently seeing is the active scroll button's hitdef expanded to the full window
(I tried going a range, but the button would lose focus and glitch up)


so yea, as for the catch, if you're scrolling and release your LMB over a button, that button will perform it's action.
(I didn't do a check for this.holdL upon LMB release in most of my widgets)
^that should be fixed in the release

EDIT:
well, that was easy to fix, I don't have to disable the other hitdefs
all I had to do was activate the releaseL() code if holdL was True.
holdL only becomes True when that widget's hitdef is clicked.

 

[Tcll]

here's another TODO:
my GUI's layering system consists of:
- layer().stack()
- layer().overlay()

the overlay system was used for the selection boxes and was a stack drawn in the forward direction (inverse of the stack layer) over the stack layer.
the same effect can be achieved by using a new stack layer and rendering the stacks with an inverted draw order.
layer( 1, invert=True ).stack()

the difference between this and the old method is 1 less for loop for a slight increase in performance

 

[Tcll]

I hate this freakin select-box widget >_<

I need 3 widgets just to do this:


and now I plan on using a scrollbox for the selection items >_<
(because I can do that now *awesomeface*)
so that's 2 more widgets for a total of 5 widgets just for 1 widget >_<
at least this one isn't migrane enducing... heh

gotta love complexity

 

[Tcll]

got the filters working... somewhat:


and now you see why I need a scrollbox... heh
and thus you see my hatred for this widget

it's really not all that complex as every addition requires small amounts of code,
but the complications come in when the small amounts of code to add falls in 5 or more class methods...
THAT's why I hate this thing >_<
(it's migraine enducing when trying to keep track of literally everything going on here in your head)
^ this includes the stuff you can't see

at least it's easier to work on this now with the new GUI layout, but when something goes wrong, you still have to look at everything. >_<

 

[Tcll]

just posting an update:

I'm almost done with the file dialog (file history and bookmarks are for later)
I'm still working out some functionality and display issues with the select box items, but the filters work perfectly

the filters come from the scripts themselves:
ugeScriptFormats('Hal Labs', ['dat'])
ugeScriptFormats('Blender data file',['blend','blend1','blend2'])

if you select a filter, the outer select box "Select a script" is updated with the script linked to that filter.
you can change that though, for 2 reasons:
- you want to simplify your file search by using a file format supplied by a different script
- the model format's file type is not marked as supported by any script (reason for the "All Formats" filter)

speaking of "supported", that filter will return in an update (listing a compilation of the formats supported by all scripts)
the functionality for that is a bit complex to add at the moment... >_>
(keep in mind you should be able to add and edit scripts while UMC is running)
^ the file I/O processes refresh the scripts before running the I/O functions

 

[Tcll]

I'm sure you guys have been waiting a long time for this functionality

thanks for being patient, but please be patient for just a little longer

I wanted to attempt to make the release by today, but unfortunately I'm still running into complications.
there's alot that's been cut to make this just as functional as before:
- script UIs
- model management
- control panel features

I'll still work on the display panel, or at least what I had, I'll work on more by the next update.

EDIT:
btw that "Wavefront" was selected via the file dialog, and not the action displayed.

EDIT2:
I can promise a release by next week
(if all goes well that is)

I nearly forgot about FORMAT.py being unfinished, and a few COMMON functions as well.

 

[Tcll]

finally got importing working


EDIT:
btw, this was done entirely with the UI, I currently don't have Ctrl+I mapped to the model import dialiog... heh

 

[Tcll]

just to show off some of the display problems I'm having:



this one's really just a few 20 or so missing function calls... heh
I'm not sure exactly as to why the title-bar data is missing,
though I have a suspicion it's the scrollbox cutoff for the script UI...

script UIs won't be available by the release, however,
there's been a few scripts I've really needed them for, such as Wavefront for separate UV channels,
so I do intend to add that functionality throughout updates.

 

[Tcll]

just recently found an issue regarding textures with MDL0 files...
due to the new scripting standards, ugeSetImageData() thinks there are no image scripts.
(rmbr how they used to be specified in the script header)

yea, with the new scripting standards, this process was made fully automated, so it tests out whichever scripts work with the file format.
though I think I might add a few options later on to make things a bit more manual
reasons being the same reasons I added the script select box on the model import tab.

 

[Tcll]

there we go, almost back in business

and even missing images:

ERROR: ugeSetImageData() image 'metal00' not found.
ACTION: Skipping

now I just gotta work on the export panel, which is roughly the same as the import panel,
and I think I'm just gonna restore the display panel to what I had before.

Ctrl+I is bound btw, and automatically opens the import panel

EDIT:
btw, functionality isn't as quick to import...
after selecting your file, it doesn't immediately import.
this was specifically set so you could:
1: select your file
2: select the import script (if needed)
3: set the import options in the script UI
4: now import

I can add a Use Defaults toggle when selecting your file, but it'll require a selected filter before being active...
only then will it immediately import when you select.

 

[Tcll]

here's something I was an idiot about...
I hadn't considered how much disabling hitdefs would hurt the system more than help it...
take a look:

all of those disabled (useless) hitdefs are still being processed per event action.
this'll really take a chunk out of your FPS if not planned for a fix in an update.
(I'm not adding too many widgets by the release, so there won't be too many hitdefs for the events to play with)

also, I'm considering automated switching to the management panel after importing.

I'll probably set that as a disabled option.
speaking of, I'll worry about options in an update as well...
I'm just restoring the functionality I had with the old UI for now.

 

[Tcll]

aaand working on the export tab:

I've just ran into a few problems with the file dialog on this issue...
the drawing data is named after the import dialog because I didn't name the dialogs >_<

the export tab won't be exactly the same as the import tab...
the next shot will show a new scrollbox showing the model data for data selection on what to export.
(this of course won't be available by the upcoming release... heh)
^ it'll be in an update

also, I know I promised a release within the week...
if that doesn't happen for whatever reason, it will be released soon after.
(more than likely it will be a delay due to coding errors, or if not that, then life issues)

I've been saying it many times... I want to be done with 3.0a so I can work on 3.0
but I still can't let it go w/o making it the best it can be for what little it can do... heh
by the time I let it go, it'll support basic animations, like what BrawlBox supports. ;D
(though as stated before, while it'll support them, you won't be able to play them)
^ I'll make sure to show as much as possible toward what they contain.

 

[Tcll]

hey, I just found something that might make me a little late...

I don't have keypress events supported by the entry widgets...
let alone a hitdef to activate them so your keypress can be entered...

I can finish the display panel an make a release and what not...
but as far as saving a file, you'll have to use your file browser to create the new file before saving over it.

I'll add a refresh button to the dialog so you can create your file, refresh and then save...

*thinks about it while typing*
I'll make the release and add the support in a minor update

this is so people can do what they need to, since they've been waiting so long.
but for those who want to wait, feel free, you won't miss out on anything.

 

[Tcll]

well... to show off some progress on things... here's the export stuff nearly complete

the refresh symbol '↻' isn't supported by the font... heh

"nearly" because I want to use the import filename for the export filename and add the extension via the script selection
when opening the save dialog, the file should already appear as given,
though I'm contemplating disabling it if you havn't imported anything.
(contemplating because what if for whatever reason you want to export a blank scene)

 

[Tcll]

also, I can't help multitasking... heh
https://www.daniweb.com/software-de...h-level-classobject-work-on-a-cpu#post2150771
^I'm trying to figure out how to identify a class from binary opcodes.

yes, this is for UMCSL in an update to UMC3.0 :3

 

[Tcll]

haha, I forgot I borked the OBJ script XD

it exports an OBJ with materials.mtl properly...
but the OBJ is pretty much blank

won't be too hard to fix

no, the hardest part that I forgot about when I made the announcement...
when setting a bone matrix, you need to specify the relation of the matrix...
yea... that's still not finished, but just about everything else, except for a few small things, is

string()() is one of these things, struct()() is another relatively larger thing.

I've been too focused on the GUI to worry about these things...
I can hold off on struct()(), but string()() is a definite need.
(I can't leave it as is, because it's changed in 3.0 for automation)
^any R/W structure uses that format: object( settings )( R/W )

so yea, I won't be able to make the release considering this
once these minor things are out of the way, I'll be sure to notify.

 

[Tcll]

well, in recent info, I've just found out how far I got in FORMAT before getting overwhelmed with everything...

ugeGetTextureName()

this is the first function for data retrieval from textures, and the last function I've worked on.
this is going to hurt your exports a tad since I havn't gotten to images, let alone the rest of the texture data...

I'll make the release w/o this support, but it WILL be added in an update.
at least you won't have to port your scripts when it arrives.

that sucks...
well... at least we have support for weights now, so rigged exports should now be possible.

I could really use some help with a DAE script if anyone's willing.

 

[Tcll]

just fixed the script reloading
all scripts reload just before starting the import or export process after clicking the button.

OT: I'm thinking about using SDL to map the Enter key to the model import/export actions, and might have that implemented by the release.
(might, because I'd have to change the event to be mapped in GUI instead of VIEWER)
^ though it's very simple, so things are looking promising

anyways about script reloading:
this will change in 3.0 for a more accurate update
^any script will be reloaded if any changes are found.


I can't say when I'll release, but I can say all I knowingly have left to do is the display panel and string()().
hopefully I can find anything else that's borked so I can clear up other issues before the release.

EDIT: one thing I forgot about: ugeCompress()/ugeDecompress()
I'll be implementing these next update
(they are rather needed for FSYS files)


I'm also considering a new method to deal with compression (won't harm the old)
for a compressed model format containing multiple models:

ugeScriptCompression('LZ77')

def ugeImportModel( FileTypes, UIC ):
....for FileID, FileType in FileTypes:
........if FileID == 0: continue # skip initial file
........ugeSwitchFile( FileID )

how this works is it creates a list of filetypes...
say your import is an FSYS file:
FileTypes = ['fsys','fsys']

I'm not sure if FSYS files have an internal model format,
but if it does, the initial format will be replaced with the sub-format.

EDIT2:
eh... you know... I have plans to keep string working as is even with the extension, so I think I'll hold off on string()() and just keep string() until the next update.

 

[Tcll]

first test of the toggle button

I'm not exactly sure why the text isn't displaying yet, but I'll figure it out... heh
it's probably hiding behind the scrollbox BG

everything seems to be going smoothly, though I'll need to realign my old coords to make it fit in the scrollbox

the box size is 20px, and the spacing is normally 15px, 10px in special cases.
I'm thinking I might need 10px for the Y spacing to make everything fit properly... heh

in any case, I'm gonna hold out a bit longer for beta testing
I have tons of minor UI issues to fix as well as minor support problems currently.

I'll see what damage I can buff out tomorrow

and heck, beta testing time may even give way to a few more scripts. ;D
Just look forward to the release because it will be soon!

 

[Tcll]

the display panel is almost done! =3

^ not sure what's up with the perspective selectbox, but that's the reason for beta testing

I havn't yet implementedthe KBd shortcuts properly, but I can start working on them now

and just to show off how much less CPU the new UI uses, you already know I have ALOT more dfined, so here's how much less CPU the current UI now uses:

old UI (no model import):


new UI (FitPikachu00.mdl0):


I do have a few more optimizations which can cut down on CPU usage, but those will take a while to do, so I'll get those by next update.

what I have now won't hurt the CPU (even low end compys will hardly be affected)

 

[Tcll]

well, I think I figured out the issue with the perspectiveselectbox...
I think it has to do with python's backend handling of dictionaries causing a confliction in my recompiler which is screwing with the stack priorities...

the widgets aren't exactly solid yet, but this may fix itself over time...

I figured this out by simply changing the selectbox widget names which caused the bone display selectbox to act up as well...
and adding more widgets also affects it...
so yea, it's definately a backend issue with my layers... I'll try to fix what I can, but this is as random as hash() returning an even number.


EDIT: figured it out

for some reason the stack is fluctuating between priorities p and p1 when the select box is set at p1.
as such, either the selectbox or it's button draws on the same stack as the display panel's scrollbox BG.

I've fixed this by bumping the selectbox widgets up a stack.
(I'll look into that and optimize it by the next update)

 

[Tcll]

fixed up a few display issues and added some functionality


Enter now imports or exports if a script is selected and text is entered into the file entry

I'm still working out a few kinks, especially with the hitdefs

EDIT:
just fixed the scrollboxes
so now scrolling over them won't zoom the model.
(you still have viewer control for any other input)

 

[Tcll]

just fixed up the hitdefs, mostly:


the problem I'm having now is the yellow selectbox...
the hitdef is supposed to cover the button as well.

also, NumPad 5 still doesn't change the projection selectbox value just yet

EDIT: 5 changes the selectbox value now

still fixing the hitdef issue

 

[Tcll]

figured out the hitdef sizing issues...
it was in my display panel update code... heh

            if this.DSB.hitdef.enabled:
                for I in [this.DLT,this.DWT,this.DTT,this.DNT,this.DBS,this.D3S,this.DGS,this.DPS]:
                    if I.hitdef.X > this.DSB.X: I.hitdef.X = this.DSB.X
                    elif I.hitdef.X < this.DSB.x: I.hitdef.X = this.DSB.x
                    #else: I.hitdef.X = I.X
                    
                    if I.hitdef.x > this.DSB.X: I.hitdef.x = this.DSB.X
                    elif I.hitdef.x < this.DSB.x: I.hitdef.x = this.DSB.x
                    #else: I.hitdef.x = I.x

                    if I.hitdef.X == I.hitdef.x: I.disable()
                    else: I.enable()

the problem was what's now commented out
so that works now ;D

the reason I don't need what's commented out is because the widgets are positioned prior to that code being executed.

 

[Tcll]

I AM NOW BETA TESTING! :D

for those who want to try it out, you can download a zip of my folder here:
https://copy.com/3Zg7S8HwFyVaXstm

Please understand, this is my active collaborative repository, which is updated as I edit the src.
alot of included scripts here don't work properly if at all and won't be in the release.

the official release will be hosted on GitHub

 

[Tcll]

just to notify, I know about the GL error on some model imports:

importing TyPichu.dat 100%
Converting from import format...
Verifying data...
Finalizing...
Updating Viewer


Traceback (most recent call last):
  File "Z:\home\tcll\sync\copy\UMC_v3.0a\API.py", line 40, in run
    VIEWER.Init()
  File "Z:\home\tcll\sync\copy\UMC_v3.0a\data\VIEWER.py", line 1039, in Init
    else: __Draw_Scene() #no 3D display
  File "Z:\home\tcll\sync\copy\UMC_v3.0a\data\VIEWER.py", line 565, in __Draw_Scene
    __GL.glCallList(__MODEL_DATA)
  File "Z:\home\tcll\sync\copy\UMC_v3.0a\data\Python\x86\lib\site-packages\OpenGL\error.py", line 208, in glCheckError
    baseOperation = baseOperation,
GLError: GLError(
	err = 1281,
	description = 'invalid value',
	baseOperation = glCallList,
	cArguments = (270L,)
)

this will eventually be found, I'm not sure what causes this, so please don't report these cases

 

[Tcll]

I'mma delay the release a bit, you guys will like this, trust me.
https://copy.com/Sz3nt7HLHmBL0ECQ
@ beta testers: don't use this yet

 

[Tcll]

well, thanks to this script I've been working on, I think I've just found a major bug with my format validator... heh
the validator (for those who don't know) was designed to validate the imported data just after completing the import process (before updating the viewer)

here's where the bug comes in, as I've just run into this... heh
my validator's major usage was for checking bone relation and correcting flaws.
what I'm running into is empty primitives or facepoints, which would inevitably crash UMC with:

GLError: GLError(
	err = 1281,
	description = 'invalid value',
	baseOperation = glCallList,
	cArguments = (270L,)
)

the problem with 3.0a is it displays the data as given to it (not saying this is a bad thing entirely as structure DOES matter)
what the viewer should be doing is converting the data to a local copy strictly for OpenGL compatibility.
(this is why I rewrote the interface in 3.0)
that way, it would preserve the original data given to it and make calculations for export conversion

but for now, again, I'm working on 3.0a just to give everyone something to work with while I work on perfecting 3.0

EDIT:
and here's the first official test of the new script

this library I got is very annoying
but it's being used with blender and a bunch of ither things, so it more than likely will improve... heh
especially with me on the case!

 

[Tcll]

just had a new idea for retrieving the vector arrays from UMC:

ugeGetVertArr( ObjectName=None, regulate=False )

- regulate = True # find the largest vector and resize the rest to match
- regulate = 3 # all vectors in this array will be returned as (3)D

why regulate?
because UMC can mix vector dimentions:
[ # vertices:
[ 0.0, 0.0, 0.0 ],
[ 0.0, 0.0 ],
[ 0.0, 0.0, 0.0 ],
[ 0.0 ],
...
]
regulate = 2:
[ # vertices:
[ 0.0, 0.0 ],
[ 0.0, 0.0 ],
[ 0.0, 0.0 ],
[ 0.0, 0.0 ],
...
]
regulate = True:
[ # vertices:
[ 0.0, 0.0, 0.0 ],
[ 0.0, 0.0, 0.0 ],
[ 0.0, 0.0, 0.0 ],
[ 0.0, 0.0, 0.0 ],
...
]

EDIT:
done and applied:

>>> def _regulate(List,Dim):
if Dim.__class__ == bool and Dim == False: return List
if Dim.__class__ != int: Dim = max([len(vec) for vec in List])
return [ vec[:Dim] if Dim<=len(vec) else vec+([0.0]*(Dim-len(vec))) for vec in List ]

>>> l
[[0.0, 0.0, 0.0], [0.0, 0.0], [0.0, 0.0, 0.0], [0.0], [0.0, 0.0, 0.0, 0.0]]
>>> _regulate(l,2)
[[0.0, 0.0], [0.0, 0.0], [0.0, 0.0], [0.0, 0.0], [0.0, 0.0]]
>>> _regulate(l,True)
[[0.0, 0.0, 0.0, 0.0], [0.0, 0.0, 0.0, 0.0], [0.0, 0.0, 0.0, 0.0], [0.0, 0.0, 0.0, 0.0], [0.0, 0.0, 0.0, 0.0]]
>>> _regulate(l,False)
[[0.0, 0.0, 0.0], [0.0, 0.0], [0.0, 0.0, 0.0], [0.0], [0.0, 0.0, 0.0, 0.0]]
>>>


applied to what?

ugeGetVertArr( ObjectName=None, regulate=False )
ugeGetNormalArr( ObjectName=None, regulate=False )
ugeGetColorArr( ObjectName=None, channel=0, regulate=False )
ugeGetUVArr( ObjectName=None, channel=0, regulate=False )

note: don't think 'regulate' will always be the 2nd or 3rd argument...
this is likely to change if I add any new features.
'channel' is solid though and will always be 2nd

so if you want to regulate an array, here's an example to be followed so you don't break your script in future releases:
ugeGetColorArr( OID, 0, regulate=4 )

 

[Tcll]

ok... somehow an extra print statement just fixed my GL error issue...

I tried everything to fix this, including supporting half the possible major issues with my verifier...
but then I found out Marth (one of the models that caused the issue) imported just fine w/o materials:

so I added a default texture (just plain white) to see if that was the problem... nope...
enabled materials and still got the error

it wasn't until I tried a debug print statement on the reference image names during display-list compilation that it finally decided to work:


and heck, I'm guessing the default texture helped me find another object on the slick star:


I've commented out the print statement in my code, and tested a bunch of other error-causing models which now work...
but there's no change in how everything imports... it's still just like the old screenshots... heh

but yea, I have no idea how to explain how a print statement fixed a GL issue... lol
either way... that's a huge fix that no longer has to be worried about

 

[Tcll]

well, good news, Roo will be happy
I've found my old PMD models =3


also, since RTB has a max script for Sm4sh models, I can also work on that, though I sent a request to him to hopefully get some help though...
(I really need some work off my back)

but if push comes to shove and RTB says no (even after me offering to fill in his blanks)...
I guess I could take over on it (no promises by the release, even if UMC scripts are easier to write than max scripts).

if RTB helps out on it, I might have it by the release.

 

[FuzzyQuills]

Hi!

I am presuming this is designed to help convert models to mdl0 for Brawl mods? Also, nice effort attempting to include 20 other formats (Including blender) in!

 

[Tcll]

yea, however, I must mention, I've been working on program support for the scripts, so the MDL0 script is currently import only and is buggy.
(it is of course intended for improvement)

and thanks! :D
it actually isn't too hard to support new formats (this is exactly what my aim was)
if you'd like to join in on supporting a new format, unlike other major programs, scripting is VERY easy.
(and that's saying alot even for 3.0a which lacks loads of support)

and the reason why I still don't yet have collada 1.4.1 properly supported is because pycollada currently sucks
(the pycollada extension is perhaps the most used between supportive programs)
but the problem is it only supports triangle meshes, and not the full primitive set, and even lacks color vectors currently.

I'm of course in contact with the (very busy) developer, so things should hopefully change soon

I'm not sure if I want to mess with pycollada as the src is perplexing to decipher...

 

[Tcll]

well, I've just gotten an idea for a control panel button
and it allows me to work with supplying both UT and PT data as is

so the UT functions WILL be available by the release, BUT CURRENTLY, they'll do the same thing as the PT functions.
(use the UT functions to directly supply untransformed data)

here's how this will work, since I only have 1 buffer to play with:
you import your data, if the data is UT or UnTransformed, there will be a button (next update) in the control panel which will allow you to recalculate and transform the model data.
(if the data is PT or PreTransformed, DON'T USE THE BUTTON)

if you use the button on PT data, you will double-transform it, meaning it will look funky.
you won't be able to untransform, I'm leaving that feature out to prevent issues.

WARNING: This is a control panel feature, meaning it edits model data, use with caution.

the transform button won't be available in the release, but it will be in the next update.

why is this issue so sudden?
working with sm4sh data, unlike Brawl or Melee, the inverse bind matrices for bones are NOT supplied.
this means my verifier will have to create them just after the import process completes (before the viewer is updated).

so how do I deal with data imported afterwards?
why, deal with it as it was meant to be dealt with.

the problem with UMC 3.0a is it directly displays the data given to it.
(there's no transformation going on, and nothing is hidden)

meaning, when you import a sm4sh model, it will ALWAYS look something like this:

^normals included

to get the images I've been getting all the way up to here, I've been applying the transformations via the script.

in the next update, I will no longer be doing that, meaning you'll have to hit the transform button after importing Melee Pichu


in UMC3.0 there will be no transform button, this feature is specifically for UMC3.0a because it's only a single-buffered interface.
this means the UT functions will work as they're supposed to in 3.0 even though 3.0a will support them.

to fully support UT data in 3.0a would mean a huge drawback in development...
3.0 is already in the works and is already designed far better.
(for example SES 2.0 is a function list instead of a plain storage format, and is executed like a script rather than read from)

so this is the line 3.0a has drawn, and I can only do what I can to support what's needed.

 

[Achilles1515]

Keep up the good work!

 

[Tcll]

thanks

been taking a short needed break, with the constant urge for finishing this.

btw, forget the transform button idea, I'm working on better methods that don't require a temporary button.
meaning the UT fuctions will work as expected, even w/o a dual-buffer.

 

[Tcll]

the break was worth it =)

I have a legit method to support UT data w/o much work to the interface :D
all I need is a variable to mark UT data sections in FORNAT.Libs, and then transform those sections after data verification.

all I need to do to the UT functions is call the PT functions while supplying the data, and then send a mark to the UT variable.
the transformer (just after data verification) will catch these marks and update FORMAT.Libs (transforming the data) just before "updating viewr..."

note: if you supply UT data to PT functions, your model will look like this:


so what's the purpose of the UT functions?
no more script-sided conversion (30-40% less code in your scripts)