Plan for Phil Carlisle
by Phil Carlisle · 11/24/2005 (10:45 am) · 8 comments
Yayy!
Now that 1.4 is finally "out", I can finally get on with some of the projects Ive been saving for the next stable release.
Its always better to work against a non-moving target, so it should help us speed things out quickly. Of course there is the AI Pack which we can get working with the 1.4 build much faster and cleaner than with moving CVS support.
But also, there is this stupid little thing I did before IGC which allows you to animate your GUI using 3dsmax/maya/milkshape or whatever.
The only problem is, how to package a bunch of code changes that are relatively simple but there are a lot of them? Changes that potentially make the whole GUI unusable if some of the changes are missed (and there are LOTS).
See, the thing is, to get the code working, I had to make mBounds a private member variable and then have accessor functions access it. Which means that there are loads of calls to gui.mbounds.x etc which need fixing up in various GUI controls.
The actual functionality is *really* simple. Imagine that when you change a gui, instead of instantly switching, you tell the current GUI to "go away" and wait till thats complete, then you tell the next gui "come in" and it does that. Of course, that would be kinda boring, but if you add the ability to animate all controls by using animation data from within a dts file? Including visibility?
So imagine being able to attach a button to an animation path, with all the 3ds control over ease in, ease out, splines etc.. It works REALLY well surprisingly, first time and all.
Anyway, I'll update my old test code and figure out how to make some kind of subversion patch or something. Then post it as a resource.
At least GUI's might be a bit more alive than they usually are. I just wish I had some time to look at Clark's scaling GUI code to integrate the two, but right now its just translation/visibility capabilities. Enough to make GUI's a bit more console style.. So you can wibble the current active buttons, or make them flash a little or something.
Anyhoo, its damn cold around here, so I'll be playing with various mechanics this weekend as there aint much else to do :)
Now that 1.4 is finally "out", I can finally get on with some of the projects Ive been saving for the next stable release.
Its always better to work against a non-moving target, so it should help us speed things out quickly. Of course there is the AI Pack which we can get working with the 1.4 build much faster and cleaner than with moving CVS support.
But also, there is this stupid little thing I did before IGC which allows you to animate your GUI using 3dsmax/maya/milkshape or whatever.
The only problem is, how to package a bunch of code changes that are relatively simple but there are a lot of them? Changes that potentially make the whole GUI unusable if some of the changes are missed (and there are LOTS).
See, the thing is, to get the code working, I had to make mBounds a private member variable and then have accessor functions access it. Which means that there are loads of calls to gui.mbounds.x etc which need fixing up in various GUI controls.
The actual functionality is *really* simple. Imagine that when you change a gui, instead of instantly switching, you tell the current GUI to "go away" and wait till thats complete, then you tell the next gui "come in" and it does that. Of course, that would be kinda boring, but if you add the ability to animate all controls by using animation data from within a dts file? Including visibility?
So imagine being able to attach a button to an animation path, with all the 3ds control over ease in, ease out, splines etc.. It works REALLY well surprisingly, first time and all.
Anyway, I'll update my old test code and figure out how to make some kind of subversion patch or something. Then post it as a resource.
At least GUI's might be a bit more alive than they usually are. I just wish I had some time to look at Clark's scaling GUI code to integrate the two, but right now its just translation/visibility capabilities. Enough to make GUI's a bit more console style.. So you can wibble the current active buttons, or make them flash a little or something.
Anyhoo, its damn cold around here, so I'll be playing with various mechanics this weekend as there aint much else to do :)
About the author
#2
11/24/2005 (10:53 am)
I like the idea of what you have planned for the GUIs. i look forward to it.
#3
I have a good solution - work with me to get the core code changes into trunk, then sell the fancy max integration bits. Everyone gets a better GUI system and you can sell your pack. ;)
Of course, that assumes they're awesome changes, but I imagine that they're tolerable. :)
11/24/2005 (11:53 am)
Phil,I have a good solution - work with me to get the core code changes into trunk, then sell the fancy max integration bits. Everyone gets a better GUI system and you can sell your pack. ;)
Of course, that assumes they're awesome changes, but I imagine that they're tolerable. :)
#4
The GUI changes I didnt really think were that big that theyre worth money... But actually, helping clean up the access to the bounds and other GUI variables can only be a good thing really. So yeah, I'll pack those changes up for you.
Whats the best way to get you those cleanups? (its literally just making the mBounds member etc all private members of GUIControl then fixing any problems with the compile where those members are accessed directly in other classes.
I'd rather just put it out there for people to mess with (the max stuff) cos its kinda silly fun :)
11/24/2005 (2:45 pm)
@Ben.The GUI changes I didnt really think were that big that theyre worth money... But actually, helping clean up the access to the bounds and other GUI variables can only be a good thing really. So yeah, I'll pack those changes up for you.
Whats the best way to get you those cleanups? (its literally just making the mBounds member etc all private members of GUIControl then fixing any problems with the compile where those members are accessed directly in other classes.
I'd rather just put it out there for people to mess with (the max stuff) cos its kinda silly fun :)
#6
11/24/2005 (5:50 pm)
mmmmm AI Pack... :D
#7
after integrating the lighting pack I find myself wishing we could package these packs more like addon components separate from the mainline similar to mods on some engines.
The core idea being that when you launch the clean source application you can specify additional components to be loaded as well including code enhancements. Whatever code or content in the addon then overrides the source if it exists.
The addons become light w/ only specific changes and can be enabled/disabled.
11/24/2005 (10:16 pm)
psp posting again...after integrating the lighting pack I find myself wishing we could package these packs more like addon components separate from the mainline similar to mods on some engines.
The core idea being that when you launch the clean source application you can specify additional components to be loaded as well including code enhancements. Whatever code or content in the addon then overrides the source if it exists.
The addons become light w/ only specific changes and can be enabled/disabled.
#8
Wot no mention of AirAce, hows it coming along?
11/25/2005 (2:35 am)
Sounds like a cool resource!Wot no mention of AirAce, hows it coming along?
Torque Owner Dracola