Hello guys, this is Joey Andres, I've been a modder since last year, and now that I"m making very very big projects, too much pressure and stress is being encounter. I spend all day modding, and very little is being accomplish because of the projects magnitude. So thinking of solutions, I came up with an idea for Brendon Pywell's future release for his amazing software Bob's Track Builder, the idea is a BTB software in a server, and there's many computers attached to it. If a project is being edited, by one computer, the other computers can also see the results, while they can also edit. Maybe a some sort of warning when two person is editing the same spot. This would be very great in big projects, when it will take months to year to make it, while if it can be divided by 2 or even 20 or more modders, then the productivity level will increase really high. Maybe you guys can divide the section you will be working, so there would be no warning. Anyway I'm looking forward for this feature, since I need to increase my modding speed, and I hope other people will also like this idea.
Modding to the Next Level,
- Thread starter JoeyAndres
- Start date
Alternatively there could be a feature that allows the save on individual parts of the track , and the import of pieces and allow point welding , then you could make a big track, split it into pieces save the idividual piece then share , then you could import the same files back in all completed with all addons
well that's a good one too, but I just need a realtime of everything so I can monitor all of the changes. I have a question though, how do you merge files though, cause I thought that's not possible in BTB, and only in 3ds max.
Partial solution that does not mandate Piddy's involvement...
Hey JoeyAndres,
I'm still working on my 1st track. I started about a year and a half ago.... it's 30 miles long. Your idea would also be handy for solo modders, enabling tracks to be split up into manageable sections (load quicker too!!)
In the case that Piddy does not have the time or desire to jump on your (I think) great suggestion, here is a possible partial solution:
I've been poking around in the big xml file that BTB generates, and it seems as though a little program could be written that would parse it in such a way to separate things into track sections (which are itemized in there from what it looks like). Then, another function (in the same above mentioned code) could reassemble the sections.
I have not looked at that xml file yet since looking at your post, but I'm guessing that perhaps terrain areas are also each in some contiguious section of the xml..(?)... If object "groups" (and walls) are as well, then as long as you know what the xml header for each section is, and your area/group names, you could code the program to also separate those into the track section parse of your choice. [That is, the program would allow you to assign specific terrain areas and object groups to a specific track section.]
Anything in the xml file that is shared by track sections could be duplicated.... the end result(s) would be a number of xml files, each representing a track section that could each be worked on independantly by members of your modding group.
Prior to you monitoring of the project's progress, you would need to run each of your modding group members 'track section' xml file back through the program to reassemble the project into a single track (made up of all the track sections).
A possible limitation could be that 'mating edges' of a track section or terrain area may have to be manually adjusted once the entire track is back in BTB.... your modding group members may have moved those anchors.
These two functions would not necessarally provide all of the functionality that you wished for in your post, but it would still be a handy start. It would also be handy for any large project for solo modders or worgroups.
Next time I'm in that xml file (soon) I'll look at it from the above perspective (that is with your idea in mind), and assess what kind of coding task (or nightmare) it might be.
Any other ideas on this tact would be appreciated......
s
Hey JoeyAndres,
I'm still working on my 1st track. I started about a year and a half ago.... it's 30 miles long. Your idea would also be handy for solo modders, enabling tracks to be split up into manageable sections (load quicker too!!)
In the case that Piddy does not have the time or desire to jump on your (I think) great suggestion, here is a possible partial solution:
I've been poking around in the big xml file that BTB generates, and it seems as though a little program could be written that would parse it in such a way to separate things into track sections (which are itemized in there from what it looks like). Then, another function (in the same above mentioned code) could reassemble the sections.
I have not looked at that xml file yet since looking at your post, but I'm guessing that perhaps terrain areas are also each in some contiguious section of the xml..(?)... If object "groups" (and walls) are as well, then as long as you know what the xml header for each section is, and your area/group names, you could code the program to also separate those into the track section parse of your choice. [That is, the program would allow you to assign specific terrain areas and object groups to a specific track section.]
Anything in the xml file that is shared by track sections could be duplicated.... the end result(s) would be a number of xml files, each representing a track section that could each be worked on independantly by members of your modding group.
Prior to you monitoring of the project's progress, you would need to run each of your modding group members 'track section' xml file back through the program to reassemble the project into a single track (made up of all the track sections).
A possible limitation could be that 'mating edges' of a track section or terrain area may have to be manually adjusted once the entire track is back in BTB.... your modding group members may have moved those anchors.
These two functions would not necessarally provide all of the functionality that you wished for in your post, but it would still be a handy start. It would also be handy for any large project for solo modders or worgroups.
Next time I'm in that xml file (soon) I'll look at it from the above perspective (that is with your idea in mind), and assess what kind of coding task (or nightmare) it might be.
Any other ideas on this tact would be appreciated......
s
Partial solution that does not mandate Piddy's involvement...
Hey JoeyAndres,
I'm still working on my 1st track. I started about a year and a half ago.... it's 30 miles long. Your idea would also be handy for solo modders, enabling tracks to be split up into manageable sections (load quicker too!!)
In the case that Piddy does not have the time or desire to jump on your (I think) great suggestion, here is a possible partial solution:
I've been poking around in the big xml file that BTB generates, and it seems as though a little program could be written that would parse it in such a way to separate things into track sections (which are itemized in there from what it looks like). Then, another function (in the same above mentioned code) could reassemble the sections.
I have not looked at that xml file yet since looking at your post, but I'm guessing that perhaps terrain areas are also each in some contiguious section of the xml..(?)... If object "groups" (and walls) are as well, then as long as you know what the xml header for each section is, and your area/group names, you could code the program to also separate those into the track section parse of your choice. [That is, the program would allow you to assign specific terrain areas and object groups to a specific track section.]
Anything in the xml file that is shared by track sections could be duplicated.... the end result(s) would be a number of xml files, each representing a track section that could each be worked on independantly by members of your modding group.
Prior to you monitoring of the project's progress, you would need to run each of your modding group members 'track section' xml file back through the program to reassemble the project into a single track (made up of all the track sections).
A possible limitation could be that 'mating edges' of a track section or terrain area may have to be manually adjusted once the entire track is back in BTB.... your modding group members may have moved those anchors.
These two functions would not necessarally provide all of the functionality that you wished for in your post, but it would still be a handy start. It would also be handy for any large project for solo modders or worgroups.
Next time I'm in that xml file (soon) I'll look at it from the above perspective (that is with your idea in mind), and assess what kind of coding task (or nightmare) it might be.
Any other ideas on this tact would be appreciated......
s
Hey JoeyAndres,
I'm still working on my 1st track. I started about a year and a half ago.... it's 30 miles long. Your idea would also be handy for solo modders, enabling tracks to be split up into manageable sections (load quicker too!!)
In the case that Piddy does not have the time or desire to jump on your (I think) great suggestion, here is a possible partial solution:
I've been poking around in the big xml file that BTB generates, and it seems as though a little program could be written that would parse it in such a way to separate things into track sections (which are itemized in there from what it looks like). Then, another function (in the same above mentioned code) could reassemble the sections.
I have not looked at that xml file yet since looking at your post, but I'm guessing that perhaps terrain areas are also each in some contiguious section of the xml..(?)... If object "groups" (and walls) are as well, then as long as you know what the xml header for each section is, and your area/group names, you could code the program to also separate those into the track section parse of your choice. [That is, the program would allow you to assign specific terrain areas and object groups to a specific track section.]
Anything in the xml file that is shared by track sections could be duplicated.... the end result(s) would be a number of xml files, each representing a track section that could each be worked on independantly by members of your modding group.
Prior to you monitoring of the project's progress, you would need to run each of your modding group members 'track section' xml file back through the program to reassemble the project into a single track (made up of all the track sections).
A possible limitation could be that 'mating edges' of a track section or terrain area may have to be manually adjusted once the entire track is back in BTB.... your modding group members may have moved those anchors.
These two functions would not necessarally provide all of the functionality that you wished for in your post, but it would still be a handy start. It would also be handy for any large project for solo modders or worgroups.
Next time I'm in that xml file (soon) I'll look at it from the above perspective (that is with your idea in mind), and assess what kind of coding task (or nightmare) it might be.
Any other ideas on this tact would be appreciated......
s
BTB stopped saving in XML format quite some time ago.
I think collaboration would work well if people specialised. E.g. have tasks like making textures, objects AIW, tdf etc split between several people. At any one time one person would have the latest version of the project, and they could implement their latest things before uploading it for someone else to work on. And Someone would have to check for consistency. E.g to make sure one section of the track didn't have much higher resolution textures than other parts.
I suppose it is really difficult to change BTB to allow cooperative work, otherwise Piddy would have already done it. May be an idea could be that BTB could save a log of operations done by one user on a specficic project: i.e. insert surface at node x, change material of surface 4 of track 6 to Default\Materials\road001, set track profile on surface 0 of track 3 to ....,move terrain anchor 456 to position (a,b,c), etc. If BTB could also read a log made from another user and apply the changes to current project it could be a way to merge the work of several users on the same project. If they work on different areas of the project, like different track segments and terrain zones may be conflicts could be avoided.
xml file manipulation...
AAAH.... I see... Since I have only ever worked on a single (albeit huge) project, BTB just passes the previous version's xml file to the new project folder (even when you do 'save as' to new revisions / name for your track). That is why that huge venue.xml file in my recently saved project folder has a 'last modified' date of last July... when I upgraded to BTB 8.0.0....
In that case, Piddy would have to be willing to make available all of the variable names and their data types in order to use the BinaryReader (class) to stream the data out of the .bin file. You would then have to hope that he used lots of //comments so you would know what the data is for.
If he changed to writing to .bin files for proprietary reasons (rather than 'save' time, and file size), then we are SOL. Perhaps he would make it available in exchange for a signed non-disclosure agreement (as the good folks at ISI require for gmotor material formats).....
It does not seem as though some sort of rudimentary (as described in this thread) 'track section' (and attendant objects) save would be too difficult of a thing to code.
My guess he has not done it yet because tons of people send him bloads of "great ideas" for his program, and it's just a matter of how many people scream the loudest for certain functions, and what he thinks will be an interestng thing to code next.
Let's face it, he hasn't continued to slave over BTB 'cause the money made from it is compelling him to continue to do so.... By this point, new code is probably bug fixes & whatever seem like a cool thing to write next.
At least for some of us 'code weasels', that's the way it works.....
s
AAAH.... I see... Since I have only ever worked on a single (albeit huge) project, BTB just passes the previous version's xml file to the new project folder (even when you do 'save as' to new revisions / name for your track). That is why that huge venue.xml file in my recently saved project folder has a 'last modified' date of last July... when I upgraded to BTB 8.0.0....
In that case, Piddy would have to be willing to make available all of the variable names and their data types in order to use the BinaryReader (class) to stream the data out of the .bin file. You would then have to hope that he used lots of //comments so you would know what the data is for.
If he changed to writing to .bin files for proprietary reasons (rather than 'save' time, and file size), then we are SOL. Perhaps he would make it available in exchange for a signed non-disclosure agreement (as the good folks at ISI require for gmotor material formats).....
It does not seem as though some sort of rudimentary (as described in this thread) 'track section' (and attendant objects) save would be too difficult of a thing to code.
My guess he has not done it yet because tons of people send him bloads of "great ideas" for his program, and it's just a matter of how many people scream the loudest for certain functions, and what he thinks will be an interestng thing to code next.
Let's face it, he hasn't continued to slave over BTB 'cause the money made from it is compelling him to continue to do so.... By this point, new code is probably bug fixes & whatever seem like a cool thing to write next.
At least for some of us 'code weasels', that's the way it works.....
s
This same type of concept is used with newer Autodesk programs; Vault I believe is what it is referred to as.
Well, for now what i do is I have 3 projects and cycle those 3 projects in the day. I organized my workflow by putting a time schedule, an hour each project, or depend on your priority level of a project. Then of course, to kill the boredom, I play games, take a break, eat, jog, or whatever. Cycling through 3 projects all the time will definetly increase production level, cause if you think about the currnet workflow, you might not be able to stand 1hr of an project, so cycling the projects will keep the fire and exitement on. Also collect information in different working situations because of different map.
Other than that, still looking forward for the server or the collaboration thing.
Other than that, still looking forward for the server or the collaboration thing.
Hi,
already the soft routinely refuses to run because it does not turn as the aging XP it requires a hardware ID specific to each machine, and even without changing the licensing system bug, I think Do not dream to share a license for multiple machines and have them work on the same software.
The idea is very good, but it is more urgent to stabilize the system license for a single machine before trying to run 15 on the same software.
@+
already the soft routinely refuses to run because it does not turn as the aging XP it requires a hardware ID specific to each machine, and even without changing the licensing system bug, I think Do not dream to share a license for multiple machines and have them work on the same software.
The idea is very good, but it is more urgent to stabilize the system license for a single machine before trying to run 15 on the same software.
@+
Latest News
-
F1 24’s Updated Driver Career Mode DetailedThe new aim of F1 24's driver career is to increase your recognition levels, and ultimately...- Thomas Harrison-Lord
- Updated:
- 3 min read
-
Assetto Corsa Competizione’s Nordschleife Hits Consoles 2nd MayThe Nürburgring 24hr Pack DLC for Assetto Corsa Competizione arrives this time next week for...
- Thomas Harrison-Lord
- Updated:
- 2 min read
-
BeamNG Hotfix Adds Vehicle Detail Viewer And A Slew Of FixesBeamNG.drive's 0.32 update has been a huge hit with fans, the obligatory patch to partner the...- Connor Minniss
- Updated:
- 3 min read
-
Gran Turismo 7’s Update 1.46 Includes Škoda’s Vision GTAn electric concept marks Škoda’s debut within Gran Turismo, and it will be joined by Honda’s...
- Thomas Harrison-Lord
- Updated:
- 4 min read
-
F1 Manager 2024’s New Mentality System, Pitbox Order DetailedAlongside being able to create a custom team, drivers can now be poached, races can be simulated...
- Thomas Harrison-Lord
- Updated:
- 2 min read
-
How The BTCC and Motorsport Games ReunitedIn a surprise move last week, official BTCC content will once again be present within rFactor 2...
- Thomas Harrison-Lord
- Updated:
- 5 min read
-
Sponsored MOZA Racing & Lamborghini Redefine Racing Boundaries with The Real Race Super Trofeo 2024MOZA Racing proudly announces its collaboration with Lamborghini for the launch of The Real Race...- OverTake.gg
- Updated:
- 6 min read