Request: CVS integration of useful engine extensions
by Stefan Beffy Moises · in Torque Game Engine · 05/31/2002 (2:56 pm) · 24 replies
Hi all!
Wouldn't it be a good idea to have a thread where everybody could make statements about what should be integrated into the official CVS?
After hours of trying to merge my code with the latest GG head without much success, I'm not really sure what to do... start all over again with a new clean HEAD and integrate all the changes I need again, step by step??
I've got some cool things in it, e.g. Kurtis Seebaldts Ogg Vorbis support, which took me hours to get it to run, etc., and the HEAD also constantly evolves, and there is always major pain involved in getting CVS to merge these different code bases properly, it seems..
I'm talking about enhancements like Melv's water stuff, Kurtis' ogg vorbis code, Melv's lights once they are tested and approved, or Bryan Turners terrain enhancements, etc. ... so if it's an approved and tested extension to the engine which everybody needs / wants and would appreciate, why not put it into the CVS?
If enough people post their wishes, some GG guy could check out the code, see if it fits GG's standards and is rock-solid, test it, evaluate it, debug it, whatever, and then put it into the CVS so that everybody gets it ...
And this is not about: "Please could anybody do all the work for me, I'm a lazy noob" or something, it's about extending the engine with useful code that is all around here so that everybody profits!
What do you think?
Wouldn't it be a good idea to have a thread where everybody could make statements about what should be integrated into the official CVS?
After hours of trying to merge my code with the latest GG head without much success, I'm not really sure what to do... start all over again with a new clean HEAD and integrate all the changes I need again, step by step??
I've got some cool things in it, e.g. Kurtis Seebaldts Ogg Vorbis support, which took me hours to get it to run, etc., and the HEAD also constantly evolves, and there is always major pain involved in getting CVS to merge these different code bases properly, it seems..
I'm talking about enhancements like Melv's water stuff, Kurtis' ogg vorbis code, Melv's lights once they are tested and approved, or Bryan Turners terrain enhancements, etc. ... so if it's an approved and tested extension to the engine which everybody needs / wants and would appreciate, why not put it into the CVS?
If enough people post their wishes, some GG guy could check out the code, see if it fits GG's standards and is rock-solid, test it, evaluate it, debug it, whatever, and then put it into the CVS so that everybody gets it ...
And this is not about: "Please could anybody do all the work for me, I'm a lazy noob" or something, it's about extending the engine with useful code that is all around here so that everybody profits!
What do you think?
About the author
#2
But the problem is, all these changes/patches have to be compatible with each other, so if you install the "ogg vorbis" patch, you must be able to install the "liquid audio" patch or whatever, too... that will be a major problem, I think...
Whereas if one/some persons approve this code and then put it into the official release, you don't have this problem... so I would still prefer the official CVS version for really useful and "core" extensions... heck, who DOESN'T need Ogg Vorbis support if the only alternative is WAV?? ;-))
05/31/2002 (3:11 pm)
Yes, good idea! GG could setup some standard how to submit these extensions, e.g. how to do the patches, how the file structure should be, etc.But the problem is, all these changes/patches have to be compatible with each other, so if you install the "ogg vorbis" patch, you must be able to install the "liquid audio" patch or whatever, too... that will be a major problem, I think...
Whereas if one/some persons approve this code and then put it into the official release, you don't have this problem... so I would still prefer the official CVS version for really useful and "core" extensions... heck, who DOESN'T need Ogg Vorbis support if the only alternative is WAV?? ;-))
#3
05/31/2002 (3:23 pm)
I thought the GG staff was incorporating new code, It would be a nightmare if everyone was adding their unapproved snippets to the CVS, with no control?
#4
I've got the process largely automated, including verifying nightly against the current HEAD. With proper coaxing, I could be convinced to do this for some of the core enhancements and make those patch files available on a continual basis.
05/31/2002 (3:25 pm)
It's pretty easy to take the code that's released and build patch files that can easily be applied against a HEAD version. I did it for Bryan's stuff, and I maintain them for my internal project.I've got the process largely automated, including verifying nightly against the current HEAD. With proper coaxing, I could be convinced to do this for some of the core enhancements and make those patch files available on a continual basis.
#5
Here are a couple of things I have found over time to help when working with Other Peoples Code and/or a code base that is evolving outside your control.
Inherit from the base implementions in the CORE code instead of hacking at the CORE code as much as possible.
Want to add the ability for projectiles to leave marks on things like that neat tutorial on how to do it, but don't want merging madness, create a DecaledProjectile class that inheirts for projectile. Override where you need to implement the changes that the tutorial lists.
When this is not possible . ..
Just copy it and rename it if nothing else. Then no problems with merging, it is a different file.
Copy the ENTIRE projectile.h and projectile.cc and rename them and rename the classes and structs, don't even worry about inheiritence, just create a completely new implementation of the interface.
Inherit where available and when it makes sense and you can just get a fresh copy of the base class without any worries about merging, now changed behavior might be a different story :)
I am using both of these approaches in my project, in some cases I sub-class a core object, other cases I am creating a new implemention of the same interface.
Vehicle is a good example when to sub-class, Player is also, but I am probably going to change that sub-class to a completely new object implementing ShapeBase and scrap alot of the confusing T2 specific code in Player just to make things easier and cleaner for me in the future.
You are going to have a Flying Vehicle for instance, you could just hack at the flying_vehicle code or you could sub-class it and call it MyFlyingVehicle and only implement the changes where you need them, removing any need to merge anything.
Now when FlyingVehicle gets some cool new functionality from the community, you just update it, and don't have to worry about merging.
There are implementation issues if some methods are removed or they are drastly changed in what they actually do or return but that is much easier to deal with than 3000 conflicts.
05/31/2002 (3:31 pm)
the one major thing preventing easy "extensions" is the way the code is being created or edited.Here are a couple of things I have found over time to help when working with Other Peoples Code and/or a code base that is evolving outside your control.
Inherit from the base implementions in the CORE code instead of hacking at the CORE code as much as possible.
Want to add the ability for projectiles to leave marks on things like that neat tutorial on how to do it, but don't want merging madness, create a DecaledProjectile class that inheirts for projectile. Override where you need to implement the changes that the tutorial lists.
When this is not possible . ..
Just copy it and rename it if nothing else. Then no problems with merging, it is a different file.
Copy the ENTIRE projectile.h and projectile.cc and rename them and rename the classes and structs, don't even worry about inheiritence, just create a completely new implementation of the interface.
Inherit where available and when it makes sense and you can just get a fresh copy of the base class without any worries about merging, now changed behavior might be a different story :)
I am using both of these approaches in my project, in some cases I sub-class a core object, other cases I am creating a new implemention of the same interface.
Vehicle is a good example when to sub-class, Player is also, but I am probably going to change that sub-class to a completely new object implementing ShapeBase and scrap alot of the confusing T2 specific code in Player just to make things easier and cleaner for me in the future.
You are going to have a Flying Vehicle for instance, you could just hack at the flying_vehicle code or you could sub-class it and call it MyFlyingVehicle and only implement the changes where you need them, removing any need to merge anything.
Now when FlyingVehicle gets some cool new functionality from the community, you just update it, and don't have to worry about merging.
There are implementation issues if some methods are removed or they are drastly changed in what they actually do or return but that is much easier to deal with than 3000 conflicts.
#6
Enough coaxing? ;-)) Seriously, that would be a BIG help for hundreds of people here I think...
@Shawn: yes, some GG guy would have to do these integrations, it would be insane to let everybody put some code into the CVS that comes their way... ;-)
05/31/2002 (3:32 pm)
Jeremy, it would be awesome to have some CVS/patch expert like you do this regularly for extensions the community thinks of as a must-have! I'm sure you've already done a brilliant job with Brian's code!!Enough coaxing? ;-)) Seriously, that would be a BIG help for hundreds of people here I think...
@Shawn: yes, some GG guy would have to do these integrations, it would be insane to let everybody put some code into the CVS that comes their way... ;-)
#7
That said, feel free to email me requests for patches ... When I get them, I'll start adding them to the automatic process, and will post a link somewhere ;)
05/31/2002 (4:18 pm)
Jarrod hit it spot on. Think about how to manage project specific changes with a third party engine, and your life becomes much easier.That said, feel free to email me requests for patches ... When I get them, I'll start adding them to the automatic process, and will post a link somewhere ;)
#8
But as for the patches, one for the ogg vorbis code would be a killer... :-)
But anybody supporting the "CVS wishlist" idea here?
05/31/2002 (4:32 pm)
Yes, I will definitely do my changes in separate files if possible... it's really a major pain to manuallly merge hundreds of files and get hundreds of errors then... :-(But as for the patches, one for the ogg vorbis code would be a killer... :-)
But anybody supporting the "CVS wishlist" idea here?
#10
05/31/2002 (9:20 pm)
Nope I certainly didn't.
#11
05/31/2002 (9:31 pm)
I think this pretty much is how things are going on - the GG guys see some extension that someone has done, and if they think it should be merged in, they ask the person to create a patch. That's what they did with me, anyway.
#12
as far as I'm concerned, I'm wondering why Ogg Vorbis and Melv's water enhancements don't make it into the CVS - everybody will profit, it works, it's stable, so what's the problem?
So I think the community should be able to at least post their wishes what should be integrated...
06/01/2002 (1:02 am)
I've noticed that page, but this thread is not really about *how* to get the changes in, it is about *which* changes/extensions/... get into the engine...as far as I'm concerned, I'm wondering why Ogg Vorbis and Melv's water enhancements don't make it into the CVS - everybody will profit, it works, it's stable, so what's the problem?
So I think the community should be able to at least post their wishes what should be integrated...
#13
I just finished integrated two patchs... one was Robert Blanchet's zip file patch, the other a fix for Milkshape animation interpolation from Paul Dana. Those were submitted to me unsolicited. The patch I integrated earlier from Simon was one he submitted as a resource. Since I usually approve resources, I saw that one and asked him to submit it as a patch :)
I have one more patch in the pipeline: the ogg vorbis streaming audio patch. The main issue we need to resolve with that one before we merge is portability... making sure it builds on Mac & Linux, etc.
06/01/2002 (8:59 am)
A discussion of of which extensions should go in is a good idea... Sometimes we spot changes we think should go in, but sometimes we miss them. Sometimes it's not always clear what should get intergrated.I just finished integrated two patchs... one was Robert Blanchet's zip file patch, the other a fix for Milkshape animation interpolation from Paul Dana. Those were submitted to me unsolicited. The patch I integrated earlier from Simon was one he submitted as a resource. Since I usually approve resources, I saw that one and asked him to submit it as a patch :)
I have one more patch in the pipeline: the ogg vorbis streaming audio patch. The main issue we need to resolve with that one before we merge is portability... making sure it builds on Mac & Linux, etc.
#14
So okay, let's start the discussion here... or would it be better to add a custom thread / page to the GG website for these suggestions/votings/whatever?
Anyhow, I would say that besides the Ogg Vorbis code,
- Melv May's water enhancements would be worth adding officially (and once his lights are ultimately working, these also!)
Oh, and not to forget
- Melv's fxShapeReplicator (can't live without it!).
- And I think Tim Newell's Inventory Manager is way better than the "normal" one... how about adding this one, too?
- Oh, and Bryan Turners multi-terrain enhancements of course, once they are finished (seems he has to fix only minor issues and then he's done)!
- Another minor one would be the bullet holes resource...
Any other suggestions anyone?
06/01/2002 (1:51 pm)
Tim, great to hear you like the idea - and even better to hear that Ogg Vorbis will make it's way into the CVS :-)So okay, let's start the discussion here... or would it be better to add a custom thread / page to the GG website for these suggestions/votings/whatever?
Anyhow, I would say that besides the Ogg Vorbis code,
- Melv May's water enhancements would be worth adding officially (and once his lights are ultimately working, these also!)
Oh, and not to forget
- Melv's fxShapeReplicator (can't live without it!).
- And I think Tim Newell's Inventory Manager is way better than the "normal" one... how about adding this one, too?
- Oh, and Bryan Turners multi-terrain enhancements of course, once they are finished (seems he has to fix only minor issues and then he's done)!
- Another minor one would be the bullet holes resource...
Any other suggestions anyone?
#15
Garagegames posts:
Patches to be applied next:
- this
- that
Now, everyone who bought the SDK (we cannot let people vote who might not even work with the Torque Demo) is now allowed to vote.
This sounds really fair to me, and it regards the need of the community.
greetings
Daniel
06/01/2002 (6:23 pm)
What do you (all) think about a rating??Garagegames posts:
Patches to be applied next:
- this
- that
Now, everyone who bought the SDK (we cannot let people vote who might not even work with the Torque Demo) is now allowed to vote.
This sounds really fair to me, and it regards the need of the community.
greetings
Daniel
#16
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2697
and it didn't compile. When I got it to compile (by reading the posts below), it crashed. The problem I had was that the instructions would say add these lines to line such and such in file such and such. But when I went to do this, the line number given didn't seem to take into account the fact that earlier instructions had added code and hence the line number is now incorrect. Hope that makes sense!
So I like the idea of patches. This probably isn't appropriate for the current topic of the thread, but that's my opinion.
06/01/2002 (8:30 pm)
I like the idea of patching, especially as I just tried to implement this resource:http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2697
and it didn't compile. When I got it to compile (by reading the posts below), it crashed. The problem I had was that the instructions would say add these lines to line such and such in file such and such. But when I went to do this, the line number given didn't seem to take into account the fact that earlier instructions had added code and hence the line number is now incorrect. Hope that makes sense!
So I like the idea of patches. This probably isn't appropriate for the current topic of the thread, but that's my opinion.
#17
06/02/2002 (9:46 am)
Mike, I never got that to work as is either, but I did find it useful in explaining you the movement was calculated.
#18
What happens now?
06/07/2002 (4:08 pm)
I noticed that the original question was about a discussion of which patches should go in. Then I noticed a few people agree and list a few patches they think should go in. And a few people suggested alternatives to patches alltogether.What happens now?
#19
- Melv's water enhancements
- Turner's multi-terrain enhancements
I don't know anything about:
- Newell's inventory
- The bullet holes resource
I believe Melv's fxReplicator is a standalone object, so it may not be really be necessary to integrate that one. I think the changes we want to integrate are those that directly affect or modify the core library (such as the water and terrain changes), enhancements that are standalone objects seem like they would better be left outside in a "library" of contributions.
06/07/2002 (5:43 pm)
The ones that sound interesting to me:- Melv's water enhancements
- Turner's multi-terrain enhancements
I don't know anything about:
- Newell's inventory
- The bullet holes resource
I believe Melv's fxReplicator is a standalone object, so it may not be really be necessary to integrate that one. I think the changes we want to integrate are those that directly affect or modify the core library (such as the water and terrain changes), enhancements that are standalone objects seem like they would better be left outside in a "library" of contributions.
#20
maybe we could have a subdirectory in CVS with all the standalone changes, along with a readme for each one? That way, people would easily be able to grab the latest version of the files, and we would make sure things don't get lost as time goes on and links die and whatnot.
Perhaps a seperate CVS module so people who want torque aren't forced to grab the addons?
I guess that is what the resources are for, so maybe a seperate set of them would be the way to go.
Josh
06/07/2002 (8:40 pm)
Tim,maybe we could have a subdirectory in CVS with all the standalone changes, along with a readme for each one? That way, people would easily be able to grab the latest version of the files, and we would make sure things don't get lost as time goes on and links die and whatnot.
Perhaps a seperate CVS module so people who want torque aren't forced to grab the addons?
I guess that is what the resources are for, so maybe a seperate set of them would be the way to go.
Josh
Torque Owner Mike Stoddart
This certainly would make it easier to apply these changes, especially if you're like me and tend to restart things from time to time anyway. It would save time.
Thoughts?