Over the past few days over 6000 lines of code have been rewritten to allow binedit to run more efficiently and stable... one of the changes being made is doing away with the .info file, whereas now all the info will be stored in just one file opposed to one for every model.
I don't think this will be a problem since i've never had a reason to manualy edit that, and to me it/they just clutter up the models folder, but thought I'd ask just to be sure.
Info question
re: Separate files
Pros. You can zip them with the original bin in case you want to do something on it later. They are, after all, useful files. Easy to delete if you don't want them.
Cons. HDD clutter.
re: Single file
Pros. Saves clutter. Easier to manage, especially if you can specify where it gets saved. I see this a lot like a txp file.
Cons. Might grow unruly large. Unable to tell what's in it and what's not. How would it deal with name conflicts.
Questions. Would there be an option whether or not to save infos, and how can we be sure we don't accidentally close a model without saving, and how to avoid the nag when we don't want it? Will there be a way to edit them, purging old or unwanted infos? Could there be a choice of which method is used?
Pros. You can zip them with the original bin in case you want to do something on it later. They are, after all, useful files. Easy to delete if you don't want them.
Cons. HDD clutter.
re: Single file
Pros. Saves clutter. Easier to manage, especially if you can specify where it gets saved. I see this a lot like a txp file.
Cons. Might grow unruly large. Unable to tell what's in it and what's not. How would it deal with name conflicts.
Questions. Would there be an option whether or not to save infos, and how can we be sure we don't accidentally close a model without saving, and how to avoid the nag when we don't want it? Will there be a way to edit them, purging old or unwanted infos? Could there be a choice of which method is used?
>> You can zip them with the original bin in case you want to do something on it later....
>> Would there be an option whether or not to save infos....
>> Could there be a choice of which method is used?
there will be an option to save as an .info file
>> Might grow unruly large. Unable to tell what's in it and what's not.
the data base will update itself.
>> How would it deal with name conflicts.
probably the same way infos do now... [1], [2], [3]....
>> how can we be sure we don't accidentally close a model without saving
never close a model or shut down BinEdit... or we could implement a failsafe :o)
>> and how to avoid the nag when we don't want it
I suppose something could be set up in preferences easily enough
>> Will there be a way to edit them
not with notepad if that's what you mean...
>> purging old or unwanted infos?
ctrl/x
this may turn out to be more trouble than it's worth... nothings been done in this area yet cept for the thoughts
>> Would there be an option whether or not to save infos....
>> Could there be a choice of which method is used?
there will be an option to save as an .info file
>> Might grow unruly large. Unable to tell what's in it and what's not.
the data base will update itself.
>> How would it deal with name conflicts.
probably the same way infos do now... [1], [2], [3]....
>> how can we be sure we don't accidentally close a model without saving
never close a model or shut down BinEdit... or we could implement a failsafe :o)
>> and how to avoid the nag when we don't want it
I suppose something could be set up in preferences easily enough
>> Will there be a way to edit them
not with notepad if that's what you mean...
>> purging old or unwanted infos?
ctrl/x
this may turn out to be more trouble than it's worth... nothings been done in this area yet cept for the thoughts
> never close a model or shut down BinEdit...
lol, that'll work.
> this may turn out to be more trouble than it's worth...
don't let me scare you. I'm just thinking out loud.
> nothings been done in this area yet cept for the thoughts
I misread your first post. I thought those 6000 lines were for infos. Anyway, the thoughts are good ones. Can't make progress if we're afraid to think. And there's still a half dozen others in the peanut gallery we haven't heard from yet.
lol, that'll work.
> this may turn out to be more trouble than it's worth...
don't let me scare you. I'm just thinking out loud.
> nothings been done in this area yet cept for the thoughts
I misread your first post. I thought those 6000 lines were for infos. Anyway, the thoughts are good ones. Can't make progress if we're afraid to think. And there's still a half dozen others in the peanut gallery we haven't heard from yet.
>> this may turn out to be more trouble than it's worth...
> don't let me scare you. I'm just thinking out loud.
thinking scares me, then there's Fila...
<font size=+2 face=Wingdings>J</font>
Rich was running by me some of his future plans and ideas this morning, and whenever one of those ideas involves removing anything we already have then I'm gonna run it by here first.
>> 6000 lines
although BE looks relatively the same on the outside, what makes it go on the inside has changed drastically since v09, the 6m lines were just minor tune ups here and there.
> don't let me scare you. I'm just thinking out loud.
thinking scares me, then there's Fila...
<font size=+2 face=Wingdings>J</font>
Rich was running by me some of his future plans and ideas this morning, and whenever one of those ideas involves removing anything we already have then I'm gonna run it by here first.
>> 6000 lines
although BE looks relatively the same on the outside, what makes it go on the inside has changed drastically since v09, the 6m lines were just minor tune ups here and there.
-
Drive2Survive
- Member
- Posts: 495
- Joined: Fri May 04, 2001 2:01 pm
- Location: Bathurst, NSW, Australia
- Contact:
At first I was little perturbed when I read this, but done right it could be advantageous.
I can really only repeat what Phineus has said. I like the way it works presently (writing an individual file for each model) because it keeps every model's face/vertex groups seperate from every other model, and it's easy to get back to a clean slate for said model by just deleting the info file (though not so easy as if BinEdit itself would do it). After a few generations of editing, my truck models do tend to accrue a long list of face and vertex groups, and oft times many of them eventually cease to be applicable when I'm chopping and changing my models.
If you are going to have them centralised into one file, it will be vital that BinEdit provides us with good management for said file. That is, context loading the face/vert groups that are applicable only for the current model (I don't want to wade through the entire list of face/vertex groups I've stored during my lifetime of truck building), and allowing the user to delete stored groups from the list (either select to delete one-by-one, or rest to wipe them all, or both). The thought that all the face and vertex groups I make while working on models may end up as one big list together, and potentially cannot be removed without losing ALL groups for ALL models, is so disturbing I will lose sleep tonight thinking about it. But if you can keep face and vert groups transparent to the user (only loading those that apply for a particular model, allowing modification of saved groups and possibly even automatic checking for groups that go out of scope) it will be something to applaud.
------------------
Why organise this thing, and take all the fun out of it?
I can really only repeat what Phineus has said. I like the way it works presently (writing an individual file for each model) because it keeps every model's face/vertex groups seperate from every other model, and it's easy to get back to a clean slate for said model by just deleting the info file (though not so easy as if BinEdit itself would do it). After a few generations of editing, my truck models do tend to accrue a long list of face and vertex groups, and oft times many of them eventually cease to be applicable when I'm chopping and changing my models.
If you are going to have them centralised into one file, it will be vital that BinEdit provides us with good management for said file. That is, context loading the face/vert groups that are applicable only for the current model (I don't want to wade through the entire list of face/vertex groups I've stored during my lifetime of truck building), and allowing the user to delete stored groups from the list (either select to delete one-by-one, or rest to wipe them all, or both). The thought that all the face and vertex groups I make while working on models may end up as one big list together, and potentially cannot be removed without losing ALL groups for ALL models, is so disturbing I will lose sleep tonight thinking about it. But if you can keep face and vert groups transparent to the user (only loading those that apply for a particular model, allowing modification of saved groups and possibly even automatic checking for groups that go out of scope) it will be something to applaud.
------------------
Why organise this thing, and take all the fun out of it?
D2S,
Allow me to put in a good word for the good work Malibu349 has been doing. As of this moment, groups can be renamed and they can be deleted from a model entirely. The feature seems to work well. Also, it was my understanding that of all the groups stored in the single file, only those that pertain to the current model would be loaded with that file. You may go to sleep now with an easy mind ;-)
Fila,
Stop provoking people
Allow me to put in a good word for the good work Malibu349 has been doing. As of this moment, groups can be renamed and they can be deleted from a model entirely. The feature seems to work well. Also, it was my understanding that of all the groups stored in the single file, only those that pertain to the current model would be loaded with that file. You may go to sleep now with an easy mind ;-)
Fila,
Stop provoking people